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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
