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, [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] > http://www.clustermatic.org/mailman/listinfo/linuxbios _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios