Alignment of LinuxBIOS table structures
Eric W. Biederman
ebiederman at lnxi.com
Mon Nov 29 09:09:00 CET 2004
"Ronald G. Minnich" <rminnich at lanl.gov> writes:
> On Fri, 26 Nov 2004, Stefan Reinauer wrote:
> I think the big problem is the use of binary data structures. It shows how
> smart the Open Boot guys were to use strings, and they figured this out 16
> years ago!
open boot provides a single function you can call. And as I recall
everything is done in terms of forth words. 32 bit or 64bit.
My memory may be faulty but that does not sound like a string based
> I think we should look at having linuxbios create strings of data for
> tables, not binary tables. Long term, the binary tables are going to cause
> us trouble, as they have already: having to use non-portable compiler
> options/attributes is a recipe for disaster. You only parse them once to
> turn them into internal binary data structures in the OS; performance is
> not an issue here.
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.
> In Plan 9, the parameters are passed in as keyword-value pairs, viz:
Which is not bad. But the implementation is totally naive.
> This is easy to generate, and both Linux and Plan 9 and other OSes have
> more than enough functions in the kernel already to parse these. This
> removes special needs for alignment, packing, and so on.
What of etherboot, what of mkelfImage, and other simple utilities.
> If you want you can generate Forth tables, which are also simple, but in
> the end, I think we need to avoid the problems of binary tables.
> My real preference is for S-expressions, as they are totally
> character-oriented tables that can still provide structure such as trees
> and tables, but I am not sure people will like S-expressions.
If we really want to avoid problems what we need is a table definition
checker that looks at the definitions of table entries and checks to
see if they are portable and safe. I don't care if they are binary
or string based, you can get into problems either way.
If someone wants to do a proof of concept of a string based implementation
I am willing to consider ideas.
Be warned though that strings scare me because everyone thinks they
are safe, and easy. When in fact they have the same essential
complexity as binary data structures with simply a different set of
limitations, and fewer tools provided in the compiler to make certain
you don't mess up.
In addition there are cases that string based tables handle very
poorly such as passing fonts.
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.
The next big step is to export the device tree via the linuxbios
table to the outside world. In most cases the this decomposes nicely
into a hierarchical set of devices. But with interrupts and a few
of their kin it starts getting hard to describe hardware as a tree,
making a graph necessary to handle the general case.
Fundamentally changing things is just something to think about for
The current problem while very bad is still mild enough the current
table definitions can be patched. It is unfortunate that this
happened with the most widely used table entry.
More information about the coreboot