[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Is: ARM maintainers advice ..Was:Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
On Mon, Apr 11, 2016 at 09:44:55AM -0600, Jan Beulich wrote: > >>> On 10.04.16 at 21:47, <konrad.wilk@xxxxxxxxxx> wrote: > > That allows the size and offsets to be the same. I checked under ARM32 > > builds: > > > > > > struct xsplice_patch_func_internal { > > const char * name; /* 0 4 */ > > uint32_t _pad0; /* 4 4 */ > > void * new_addr; /* 8 4 */ > > uint32_t _pad1; /* 12 4 */ > > void * old_addr; /* 16 4 */ > > uint32_t _pad2; /* 20 4 */ > > uint32_t new_size; /* 24 4 */ > > uint32_t old_size; /* 28 4 */ > > uint8_t version; /* 32 1 */ > > union { > > uint8_t pad[31]; /* 31 */ > > } u; /* 33 31 */ > > /* --- cacheline 1 boundary (64 bytes) --- */ > > > > /* size: 64, cachelines: 1, members: 10 */ > > }; > > > > So it all looks correct. (and I can cast the old_addr to uint8_t). > > Naturally we can expand the pad[] to hold whatever is needed > > when implementing xSplice under ARM > > I still don't get: Why is it so important for this structure to have > the same size and layout across architectures? I have a very bad taste from the blkif.h struct request where the structure size is 112 or 108 depending on the 32 vs 64. Having the same offsets for variables should make it easier for the tools to generate the payload much simpler without having to worry about the sizes or offset. Also it means that the common code BUILT_IN_BUG can be generic across ARM and x86. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |