From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [patch 01/10] Generate headers with arch-specific structs. Date: Mon, 04 Dec 2006 18:04:44 +0100 Message-ID: <4574552C.6090801@suse.de> References: <20061204105824.942096000@suse.de> <20061204105847.355561000@suse.de> <1165249737.30343.7.camel@basalt> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1165249737.30343.7.camel@basalt> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Hollis Blanchard Cc: xen-devel@lists.xensource.com, xen-ppc-devel List-Id: xen-devel@lists.xenproject.org Hollis Blanchard wrote: > On Mon, 2006-12-04 at 11:58 +0100, Gerd Hoffmann wrote: >> plain text document attachment (xen-generate-foreign-headers.diff) >> This patch adds a script to generate headers with arch-specific >> structs which can be included on any architecture. Can be used >> to deal with structs of "foreign" architectures, needed for >> 32-on-64 support for example. > > This omits PowerPC; is that because we've made sure not to use > variable-sized types? No. It's because (a) I don't have a working cross compiler and (b) because it's the only bigendian architecture, so just generating those headers isn't enough to have any other (xen-supported) architectures access powerpc structs correctly. So I decided to just leave it as-is for now. It certaily can be added, feel free to send patches ;) > Even if that's the case, shouldn't we still have headers in > xen/include/public/foreign, since otherwise external tools #including > those headers will break? Tools don't need them as long as the code is compiled native only. The (very incomplete) xc_dom_powerpc.c file of the new domain builder simply includes xen.h and arch-ppc.h. The rewritten domain builder uses the foreign headers for xc_dom_{x86,ia64}.c, because these source files are compiled on all three little endian architectures. A real practical use this has for x86 only, for upcoming 32-on-64 support. Compiling ia64 is handy sometimes as you'll easily notice at least some kinds of build failures even without a ia64 box. There is no real use (yet?), although I can think of some (poking informations out of ia64 suspend/core images on x86 boxes for example). [ see http://www.suse.de/~kraxel/patches/unstable-hg12663-20061201-quilt/tools-domain-builder-core.diff ] HTH, Gerd -- Gerd Hoffmann http://www.suse.de/~kraxel/julika-dora.jpeg