This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [patch] architecture-specific ELF header checking

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [patch] architecture-specific ELF header checking
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Tue, 13 Jun 2006 10:17:23 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 13 Jun 2006 08:17:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <dd1d662ccc18e4dd6a98a71a8cb7a7f3@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Linux Technology Center
References: <1150143142.9179.36.camel@xxxxxxxxxxxxxxxxxxxxx> <dd1d662ccc18e4dd6a98a71a8cb7a7f3@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2006-06-13 at 10:15 +0100, Keir Fraser wrote:
> On 12 Jun 2006, at 21:12, Hollis Blanchard wrote:
> > This patch has only been compile-tested on x86, but it should be pretty
> > straightforward. It could break IA64 since it adds checks they weren't
> > doing before, but I would expect their ELF binaries are labeled
> > properly.
> I am not keen on adding loads of -D CFLAGS options for very 
> localised/specific macros.

I agree; a per-arch header file would be ideal.

> They could go in a per-arch header file, but 
> I think in this case just having ifdef's in xc_elf.h is clean enough.

I would like to minimize the amount of code modified by new
architectures. I think this is a worthy goal because it would avoid
patch conflicts and minimize the chances of accidentally breaking other
architectures. (I guess this is true of all modular code actually; it
would be nice if one could add a new scheduler just by adding a new
source file, without needing to modify other code.)

In general we can use the build system to give us indirection, instead
of using conditionals in the code. For example, consider
xen/include/public/arch-*.h: just like the "asm" symlink, the build
system could create a symlink to the appropriate architecture's header
for us.

If we had a per-arch header file, I could place PPC ELF definitions in
that. If we keep everything in e.g. xc_elf.h, that means I need to
modify it.

> Nothing outside the ELF-parsing code should be looking at these values 
> so keeping them private is sensible. Apart from that, the general idea 
> is fine so I'll modify and apply.

Thanks; I will add ifdefs to xc_elf.h when I see your commit.

Hollis Blanchard
IBM Linux Technology Center

Xen-devel mailing list