WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] 32/64-bit hypercall interface

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel