Alignment of LinuxBIOS table structures

[Greg Watson]

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