On Thu, Apr 30, 2009 at 8:23 AM, Patrick Georgi patrick.georgi@coresystems.de wrote:
Am 30.04.2009 16:03, schrieb Myles Watson:
On Thu, Apr 30, 2009 at 8:01 AM, Stefan Reinauerstepan@coresystems.de wrote:
With all the infrastructure in the CBFS format, I think encoding duplicate information in the file names is not an appropriate approach. Instead the existing infrastructure should be used.
Care to elaborate? I don't see ordering information or whether the ROM returns in CBFS.
Option Rom support is, for now, incomplete (eg. no subheader). The subheader will contain at least a compression flag and vid/did fields (for faster lookup, and to free the name field for more useful purposes, eg. keeping the vendor filename which includes a version number). We could add an order field there, or pick an invalid vendor ID (0x0000 and 0xffff seem to be free, and esp. the latter likely won't be used at all, as it looks like a read in empty I/O space) and order them by device ID. coreboot or the payload would iterate PCI, then run through the device ids (with did=0 being executed first).
CBFS has rich metadata for its objects. If we don't use it, and stuff everything in the filename, we could as well use ar(1) and the system's tools (with all the trouble that brings, eg. with slightly incompatible lzma implementations and the like), and spare us the trouble of maintaining our own tool.
I think this is overkill. I think file names are intuitive and obvious. Just because there are problems with using system tools doesn't mean we should create new problems.
Adding special support to the Option ROM header for extra drivers that are not option ROMs is ugly.
Thanks, Myles