Re: Should we revert "mm: New XENMEM space, XENMAPSPACE_gmfn_range"?

[Tim Deegan <tim@xen.org>]

At 18:55 +0100 on 01 Aug (1343847341), Stefano Stabellini wrote:
> I was reading more about this commit because this patch breaks the ABI
> on ARM, when I realized that on x86 there is no standard that specifies
> the alignment of fields in a struct.
> As a consequence I don't think we can really be sure that between .domid
> and .space we always have 16 bits of padding.
> I am afraid that if a user compiles Linux or another guest kernel with a
> compiler other than gcc, this hypercall might break. In fact it already
> happened just switching from x86 to ARM.

AIUI, reverting this patch won't solve that problem - either a compiler adds
16 bytes of padding (as GCC and clang do), in which case we can use that
area of the new argument, or it doesn't, in which case it's already not
compatible with a GCC-built xen.

> Also, considering that the memory.h interface is supposed to be ANSI C,
> isn't it wrong to assume compiler specific artifacts anyway?

Yes - people writing Windows drivers have this sort of alignment/padding
issue already in a number of places.  But since, as you say, there's no
standard describing this, the best we can do is keep any _new_ interfaces
size-aligned and explicitly sized.

Tim.