Re: memop struct packing, 32/64 bits

[Keir Fraser <keir.xen@gmail.com>]

On 19/01/2012 21:23, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:

>> 
>> I don't think gcc extensions such as this are allowed in
>> xen/include/public. You should explicitly pack the struct instead.
> 
> domctl.h is in a way spared, because __attribute__((aligned(8))) is
> allowed in 32 bits. And the header is spared the ansi test.
> 
> Is there a rationale to allowing this ABI file do 'aligned', but
> preventing that other header file from using it?
> 
> I'm thinking uint64_aligned_t would solve my problem in memory.h.

Would like public headers to not be gcc specific. The toolstack is a more
specific special case, it contains lots of gcc-isms anyway. Hence its
sysctl/domctl hypercalls are allowed more leeway.

Frankly, rather than hauling the mem_event toolstack operations out of
domctl, you might be better just fixing the coarse-grained locking at least
for the particular commands you care about. The big domctl lock is not
needed for a quite a few of those domctl operations.

 -- Keir

> Andres
> 
>> 
>> Ian.
>> 
>>> 
>>> Thanks!
>>> Andres
>>> 
>>>> 
>>>>> Exploring the include/public/memory.h declarations and toolstack
>>> code, I
>>>>> see that no current declare includes __attribute__((aligned)) or
>>>>> __attribute__((packed)), or explicit pads.
>>>>> 
>>>>> So how come things don't break more often for 32 bit toolstacks? pure
>>>>> luck? Am I missing something?
>>>> 
>>>> Where older structs were not 32/64-bit invariant, compat shims were
>>>> implemented. See common/compat/memory.c, for example. Well worth
>>> avoiding
>>>> that!
>>>> 
>>>>  -- Keir
>>>> 
>>>>> Thanks!
>>>>> Andres
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
>