[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 11.04.16 at 17:50, <konrad.wilk@xxxxxxxxxx> wrote:
> 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.

The two have very little - if anything - in common imo.

> 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.

None of this seems overly hard to retain even when the structure
size wasn't consistent - just that you couldn't use a literal 64 anymore,
for example.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.