On Mon, 29 Nov 2004, Eric W. Biederman wrote:
Performance is not an issue code size can be. Check out ACPI for the nasty version of needing too much parsing to get the data you need.
no argument, we don't want to recreate ACPI
totalmem=0x100000
Which is not bad. But the implementation is totally naive.
??
What of etherboot, what of mkelfImage, and other simple utilities.
again, the x=y stuff is dead simple to parse. Keep in mind, there is the possibility as time goes on of matching old linuxbios to new payloads, or even in the worse case for testing old payloads to new linuxbios.
You're either going to need to: 1- fix the table for all time (not practical) 2- version number the table (which can detect version mismatch but can't fix it) 3- go to a string-based organization
now the fact is that etherboot parses all kinds of strings in packets, so I don't see parsing linuxbios strings a big deal; same with the others. They all deal with strings of one sort or another.
In addition there are cases that string based tables handle very poorly such as passing fonts.
You lost me on this one. Are we planning to pass fonts in the tables in whatever form they take?
With the current structure is there is information that is best passed in a string form we can define one or more table entries that allows us to implement that.
That won't fix the fundamental problem with binary tables.
I think what Stepan's problem has shown, as my problems with Xen have shown, that planning to pass structs through and assume it will always work is going to get us in trouble.
We don't have to do keyword-value pairs, but the binary table approach is not the clear win it first appeared to be.
ron