From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [patch rfc 1/3] xen arch header rework. Date: Thu, 05 Oct 2006 15:08:32 +0200 Message-ID: <452503D0.1030605@suse.de> References: <20061005090543.625074000@suse.de> <20061005090633.493298000@suse.de> <4525165C.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4525165C.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Jan Beulich wrote: > I'm not sure I like the tagging (as it'll likely result in even more overriding > in the 32-on-64 patches), but I understand the motivation. > >> + uint32_t unused; /* alignment */ > > Could you use _pad[0-9]* here as is done elsewhere, so that scripts > can easily recognize the field as not needing copying (and namely not > needing matching source and destination fields) when translating > structures between architectures? Right now I'm looking at your patches posted yesterday, especially the "compatibility_header_generation" one, and see if that works out better. The "just fixing up arch-${name}.h" approach has its limits. In the end I'll need a arch-specific xen.h too. Due to longs being in quite some structs, also due to "struct arch_foo" being element of "struct foo", even the structs outside arch-${name}.h end up being quite different on different archs ... cheers, Gerd -- Gerd Hoffmann http://www.suse.de/~kraxel/julika-dora.jpeg