On 29/8/06 9:49 am, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
> One more point here: The addition of this type and XEN_GUEST_HANDLE_64(),
> as it turns out, makes things more complicated/unreliable in the compatibility
> stuff rather then helping the situation: Since we need to force 4-byte
> alignment on uint64_t (and possible derived types) fields, we have to use
> #pragma pack() framing the entire (generated) compatibility headers.
> However, #pragma pack() takes precendence over attribute((aligned())), and
> hence there is no easy way to force 8-byte alignment on uint64_aligned_t
> fields.
Depending how smart the script is, if it tracks required offset of fields in
the structure definitions it is creating, it could insert explicit padding
to force the required alignment.
As for ensuring sysctl/domctl alignments are same for 32- and 64-bit builds,
we'd anyway like a script that would generate a C program that would print
field offsets/sizes for all public structures anyway (so that we can be sure
that none change and break the ABI). If we had that, we could compile the C
program -m32 and -m64 for sysctl.h and domctl.h and ensure the outputs are
identical. I think this would be an ideal solution -- but it does assume
existence of a tool that doesn't exist. :-)
Alternative is to say 'screw it' and just treat the sysctl/domctl headers
like any other, and remove the explicit alignment stuff before we fork
3.0.3. Domctl in particular is a *big* interface though, so it'd be nice to
avoid needing to generate (much) compat code for it.
-- Keir
> (a) exclude sysctl.h and domctl.h from the processing (which is probably
> intended, but opens the possibility of unintentionally introducing fields of
> types that need translation, which would go undetected at build time), and
> (b) assume that no other header uses this type, or depends on the 8-byte
> alignment forced on __guest_handle_64_XXX.
> Both are maintenance-wise bad in my opinion. Ideas?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home