From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keir Fraser <keir.xen@gmail.com>
Subject: Re: memop struct packing, 32/64 bits
Date: Thu, 19 Jan 2012 21:56:14 +0000
Message-ID: <CB3E41FE.2925E%keir.xen@gmail.com>
References: <f46a8328cddbf3a18195159cbd0a0955.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <f46a8328cddbf3a18195159cbd0a0955.squirrel@webmail.lagarcavilla.org>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>, Ian Campbell <Ian.Campbell@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir (Xen.org)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

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