Re: 32/64-bit hypercall interface

[Ronald G Minnich <rminnich@lanl.gov>]

Jimi Xenidis wrote:

>  KF> When we previously had this, by defining packed structs, there were 
>  KF> plenty of screams that it wasn't ANSI compliant, and that performance 
>  KF> sucks on some architectures.
> 
> Tou use a research term, "thats just ka-ka" :)
> Packed in no way solves the problem of selecting the appropriate types.

no, it's not ka ka at all. I had huge troubles with plan 9 c and the way 
that the linux structs were packed via the use of gcc struct packing. I 
am really glad packed went away.

The fact is, Xen has had trouble for me at times, as it is very 
linux/gcc specific. The one that hit me the hardest was exception 
frames, and second hardest was the packed keyword. I had to write 
marshall/unmarshall functions on Plan 9, just as though I were using 
RPC. It worked out, though, since (see below) I was able to end up with 
structs with better alignment.

I thank the Xen team for removing packed structs. It was a good move.

Also, there was some packing that resulted in very suboptimal structure 
member alignment. In one case, for one struct, a long struct member was 
odd-byte-aligned 1/2 the time, odd-short-aligned 1/4 the time, and 
correctly aligned 1/4 the time. There's no reason to do this.

There was also a lot of research disagreement on the plan 9 list about 
packing, when I brought this issue up; it's not like all the angels sing 
from the gcc hymnal. Comments ranged from the politest,  along the lines 
of "using packed is bad design", to less polite :-)

There are lots of good arguments on both sides. But it really boils down 
to, 'which is most portable, using packed or not'. The answer is, not.

thanks

ron