On 04/30/17 02:48, Jordan Justen wrote: > Today, we give 128k to non-volatile storage, which due to various > reasons results in 56k of variable storage. Personally I already > consider this generous, especially when I look at the 128k size of the > seabios bios.bin. :)
I'd like to comment on the seabios analogy; I just needed a bit more time to gather data for this (BZs and build logs, mainly). In RHEL-6, we shipped (and have been shipping) 128KB SeaBIOS binaries. Preparing for RHEL-7.0, we increased the SeaBIOS binary size to 256KB, anticipating future features that would no longer fit into 128KB. This is the BZ for it: https://bugzilla.redhat.com/show_bug.cgi?id=1038604 The exact "seabios-1.7.2.2-5.el7" build, dated 2013-Dec-10, in which the BZ was addressed, is no longer available in our build archives (it was not a released version, just a development build, so that's OK), but "seabios-1.7.2.2-6.el7", i.e. the build right after, is available. At that time, we were still under 128KB: > Total size: 117472 Fixed: 58792 Free: 144672 > (used 44.8% of 256KiB rom) Today, looking at the build log of "seabios-1.10.2-2.el7" (built 2017-Mar-30), I find: > Total size: 149664 Fixed: 75392 Free: 112480 > (used 57.1% of 256KiB rom) Had we not increased the size in advance (via CONFIG_ROM_SIZE), we'd have run out of it over the past ~3.5 years. In OVMF, the address range of the non-volatile area depends on SECFV's size, FVMAIN_COMPACT's size, and on the NV area's size; they come in this order downwards from 4GB. SECFV is safe as-is; it has seen negligible growth in years, and is currently at about 14% in a DEBUG build. I'd like to future-proof the other two (FVMAIN_COMPACT and NV) sizes now, with a large -- approx. seven year -- margin. Thanks Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
