On Sun, Aug 09, 2009 at 11:16:49AM -0700, ron minnich wrote:
Definitely don't use NULL for anything -- it's a free space marker as patrick points out.
The type is actually unsigned int type;
I would make the following proposal: we reserve the range 0-255 for cbfs "system" (i.e. coreboot) use and open up the rest of the range for any other use. Then we allow people to register types on the wiki in some way.
I can't believe coreboot will ever need more than 256 types, and I can't believe the community will ever need more than 16M.
I believe the community doesn't need any types. I fear we're creating work that doesn't need to be done. (Why maintain a wiki and/or build a standard around a feature that isn't needed?)
Of the four types defined:
null - can be implemented by setting the first character of the filename to 0 on deleted files. This is actually easier for file finding code because then it can just do a filename search and not have to worry about matching deleted files.
stage - instead of having a type in the cbfs header, a signature can be added to cbfs_stage. The same validity check can then be done there.
payload - same as 'stage' - add signature to cbfs_payload.
optionrom - isn't actually in use. Both SeaBIOS and coreboot expect to find option roms without any special header.
-Kevin