Alignment of LinuxBIOS table structures

Ronald G. Minnich rminnich at
Mon Nov 29 10:06:00 CET 2004

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.


More information about the coreboot mailing list