John van Vlaanderen
john-at-thinman at nyc.rr.com
Wed Jun 11 21:31:00 CEST 2003
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
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,
On Wed, 2003-05-21 at 11:03, prl-linuxbios at 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 at clustermatic.org
More information about the coreboot