Alignment of LinuxBIOS table structures

[Ronald G. Minnich]

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