Re: Breaking change issue with NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, h]

[Laszlo Ersek <lersek@redhat.com>]

On 08/05/16 18:12, Cohen, Eugene wrote:
> We've been hit by this same kind of issue and it's really painful, especially as it affects shipping systems.
> 
> Long term I think we need an extensible/revisioned data format so we can get forwards and backwards compatibility between NVRAM data and FW.

In OVMF we have a (very rudimentary) implementation for this, see
PlatformConfigLoad() in "OvmfPkg/PlatformDxe/PlatformConfig.c".

The idea is shamelessly stolen from UEFI protocols:
- we store the config structure in some NV variable under some
  namespace GUID,
- new fields can only be added after existing fields to the structure,
- if a new field would change the meaning of a preexistent field, or
  some preexistent fields would have to be dropped / replaced, then the
  change is deemed incompatible, and a new variable name or namespace
  GUID is required.

The number of bytes the config reader function reads from the variable
is the minimum of:
(a) the size of the variable,
(b) the size of largest structure version known to the config reader.

If a==b, then it's a version match. If a>b, then it's a firmware
downgrade (unknown fields are ignored). If a<b, then it's a firmware
upgrade, fields missing from the NV data are initialized to default
values (or some such).

The implementation in OVMF is of course just a "stem" for future
extensions. We've never needed such an extension yet :), but the idea is
the one above, FWIW.

Thanks
Laszlo