"Ronald G. Minnich" rminnich@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 interface.
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: totalmem=0x100000
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 now.
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.
Eric