Hi, Years before XML, In perl, I developed a kind of complex structure to store user state information at the NY Stock Exchange for if/when the systems went down all the users could be restored to what they were doing beforehand.
Later I wrote a dataserver which accepts something like a URL string with a serialized data structure on the end of it, freezes it to disk and the returns an sub or super set of that structure in serialized form. I think created a way to put code in it as text, and now I have promised myself that I will actually embed code in them someday.
XML came along and showed how inefficiently this could be done. I think the parsing complexity is becasue it is a markup language and has attributes and stuff that are comical by normal language standards.
I went to a lisp meeting last night, and suddenly realized I had been using lisp to teach perl to kids... now I wish there was a C-Lisp-AN.
I think perl structures are about as readable as a config can get, though there is a slight learning curve. I am also wondering how Perl6's Parrot VM can be integrated into LinuxBIOS.
Here is a quick tutorial for perl with structures that I wrote, http://thinman.com/perl_primer/
John
On Wed, 2003-05-21 at 11:03, prl-linuxbios@sychron.com wrote:
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.
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios