[coreboot] [PATCH] cbfs, smaller api, more types
kevin at koconnor.net
Sun Feb 28 16:21:46 CET 2010
On Sat, Feb 27, 2010 at 03:48:57PM +0100, Patrick Georgi wrote:
> I intend to add a header for option roms "real soon now", which contains
> compression type and vendor/device ids.
> That way, the filename can be the official filename (with version number
> and other information, etc) by the vendor, if available.
I fear this would be a step backwards. Yes, one would be able to
store the vendor's filename, but then users would lose the ability to
easily know which devices that rom ran on.
> The remaining question is how we handle multiple boot paths
> (fallback/normal, for example) then. Still look for prefixes?
I'd prefer to use prefixes. Using "directories" is a well understood
concept by users.
On Sun, Feb 28, 2010 at 08:33:02AM +0100, Patrick Georgi wrote:
> Am 28.02.2010 03:04, schrieb Carl-Daniel Hailfinger:
> > compatible. Your patch might be backwards compatible, but some of the
> > proposed extensions (option ROM naming and separate PCI ID storage) are not.
> The only other user of option roms (SeaBIOS) uses a different type
> number to prevent issues once the optionrom subheader appears (which is
> more or less announced in the source).
> It's also doing its _own_ thing to handle compression (namely, more
> filename magic).
The filename magic for compression in SeaBIOS is 9 lines of code - 3
lines in cbfs_finddatafile and the 6 line function cbfs_iscomp:
I think adding a ".lzma" externsion to an lzma compressed file is
intuitive to users.
> So there's no risk in changing the format used with the "official" type
> number, and there's the chance that SeaBIOS picks up the change, so
> we're able to work with the same set of images.
More information about the coreboot