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.
We're not on unix. Not everything is a file for coreboot (neither for unix, but that's a different discussions).
Patrick