WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

On Tue, 2006-06-13 at 16:42 +0100, Keir Fraser wrote:
> On 13 Jun 2006, at 16:17, Hollis Blanchard wrote:
> 
> > 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.
> 
> I agree, but there's also a question of scope. Macros that are used 
> only be elf-parsing code and that concern the details of 
> elf-header-specific field enumerations arguably do not belong in a 
> repository-global header file.

"config.h" seems to be a well-accepted idea in most projects that I've
seen, but I don't care too much in this case.

> For libxc we probably need per-arch subdirectories for arch-specific 
> source files. There's all sorts of intermingled arch-specific code in 
> tools/libxc right now. We could then have arch-specific implementations 
> of xc_elf_check_header() or somesuch in tools/libxc/<arch>, like we do 
> for Xen's domain0 elf-parsing code. That would be cleaner and give more 
> per-arch flexibility.

Absolutely! I also have a (not quite complete) xc_ppc_linux_build.c that
belongs in a directory like that. As PPC implements more libxc
functionality, the number of files like that will increase.

Anyways, I'm OK with whatever you commit. We could hack xc_elf.h for
now, with per-arch directories being the stated direction for the
future.

-- 
Hollis Blanchard
IBM Linux Technology Center


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel