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.
ron