On Nov 28, 2004, at 9:34 PM, Ronald G. Minnich wrote:
On Fri, 26 Nov 2004, Stefan Reinauer wrote:The problem is that different compilers handle structure alignment differently, ie 2.95.x and 3.x have fundamental differences here:
stepan, from the point of view of Plan 9, these are the same compiler.
Adding __attribute__ ((packed)) to the structures helps:
Sadly, Plan 9 compilers do not support this attribute for very good
technical reasons. The problem then is that these tables will be hard for
Plan 9 to deal with.
struct lb_memory_range { uint64_t start; uint64_t size; uint32_t type; #define LB_MEM_RAM 1 /* Memory anyone can use */ #define LB_MEM_RESERVED 2 /* Don't use this memory region */ #define LB_MEM_TABLE 16 /* Ram configuration tables are kept in */ } __attribute__ ((packed));
There are two problems here.
The first problem is the use of binary structures, followed by the use of
gcc attributes to make the structures have a certain "shape". I've just
had a big tussle with this in Xen and Plan 9. Xen kind of assumes a gcc
world and things fall apart badly when your compiler is not gcc. This is
going to happen with these binary structures when our payloads are not
built with gcc compatible compilers -- which is already the case with Plan
9 payloads.
Second problem is, what happens if this or other LinuxBIOS tables need to
change at some future point? We're going to have different versions.
Intel and Microsoft solve this versioning problem by putting a version
number in binary tables. Hence in the _MP_ table there is a version flag.
This versioning of binary tables is a headache; what if you have to boot a
very old OS that realizes it can't parse table version 2, only table
version 1? Oops. Trouble, that's what.
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!
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.
In Plan 9, the parameters are passed in as keyword-value pairs, viz: totalmem=0x100000
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.
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.
I agree, we need to get away from binary structures. Much as I like S-expressions, strings containing key/value pairs is probably the most common and easily understandable way to do it.
Greg
_______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
