config language

prl-linuxbios at sychron.com prl-linuxbios at sychron.com
Wed May 21 11:04:00 CEST 2003


> 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.





More information about the coreboot mailing list