From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: memop struct packing, 32/64 bits Date: Thu, 19 Jan 2012 22:04:59 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andres Lagar-Cavilla , Ian Campbell Cc: Konrad Rzeszutek Wilk , "xen-devel@lists.xensource.com" , "Keir (Xen.org)" , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 19/01/2012 22:00, "Keir Fraser" wrote: >> 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. > > As an alternative, you could declare a tools-only section for > public/memory.h. See public/hvm/hvm_op.h for example, which therefore gets > to use uint64_aligned_t in those sections. Also, if you are adding toolstack commands to an existing general-purpose hypercall, wrapping it in defined(__XEN_TOOLS__) is useful documentation. -- Keir > If your struct is for general consumption by any guest then you're SOL and > have to do it the hard way.