[coreboot] [PATCH] cbfs, smaller api, more types

[Kevin O'Connor]

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:

http://git.linuxtogo.org/?p=kevin/seabios.git;a=blob;f=src/coreboot.c;h=988775267923fc0aa495787969240ec42406fde6;hb=0360e8e69bb3a773ceb9d2b091b62c027bca862b#l461

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.

-Kevin