This is functionality we need in the LinuxBIOS table especially for devices that cannot be detected by the OS. Like temperature sensors. This should be easy to add in the 1.1 development tree.
This is information we cannot transmit via DHCP. A DHCP packet is to small. In DHCP we just need enough information to bootstrap.
I was not suggesting that the tables must of necessity all be munged into a DHCP packet, though I observe that with a reasonable encoding, most descriptions probably *would* fit in a single DHCP options field of 312 bytes. In practise I agree that one would use only those parts which were relevant to (network) booting in a real DHCP packet.
But... reading through the recent discussions about XML, it took me some time to release that people were talking about parsing IN LinuxBIOS, as opposed using XML as an input file to a build or config process. XML or similar in LinuxBIOS itself seems like overkill to me.
Please consider using DHCP encapsulated option format as an internal format for LinuxBIOS in the first instance, even if DHCP (the protocol) is not used. I see several reasons...
- Compatibility with the DHCP protocol
OK, I understand that not everything wants to use DHCP for network configuration, but even the most ardent boot-from-the-bare-metal embedded fan must appreciate that many do use DHCP, even if only for testing code via DHCP / TFTP before a final product is burned in.
Or, put another way, why would you make a *point* of being different?
- Code exists
DHCP option parsing code exists in Etherboot (so Etherboot-on-LinuxBIOS users have it anyway). As I say, a hardware description has been discussed (and I *think* implemented) in Etherboot in the particular case of PCI nics.
- Compact parser and encoding
DHCP hardware descriptions (i.e. individual chipsets) should be encoded numerically. There are reasons why existing DHCP options and SNMP MIBs do it this way - 32 bits encodes a HELL of a lot of possible hardware types in only 4 bytes. Doubtless someone will tell me that DHCP isn't the most efficient method or that they have a *really* neat parser for their favourite format. Big deal - refer to "Code exists".
- Do the hard stuff outside LinuxBIOS
Register the encodings centrally held table (like other DHCP options or an SNMP MIB), so that when building, tables can be built as appropriate from XML definitions. A DHCP server or a small amount of perl in the build process can translate raw numbers to and from human readable form using boilerplate derived from the central table. Where possible (e.g. PCI IDs), use an existing registry anyway.