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

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

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