[Xen-devel] Should we revert "mm: New XENMEM space, XENMAPSPACE_gmfn_range"?

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 16 Nov 2011, Jean Guyader wrote:
> 
> XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
> a range of pages. The size of the range is defined in a new field.
> 
> This new field .size is located in the 16 bits padding between .domid
> and .space in struct xen_add_to_physmap to stay compatible with older
> versions.
> 
> Signed-off-by: Jean Guyader <jean.guyader@xxxxxxxxxxxxx>

Hi all,
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.
Also, considering that the memory.h interface is supposed to be ANSI C,
isn't it wrong to assume compiler specific artifacts anyway?
Considering that we haven't made any releases yet with the change in
memory.h, shouldn't we revert the commit before it is too late?

- Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel