"Ronald G. Minnich" <rminnich(a)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
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
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.