On Sünnavend 27 November 2004 22:49, Andreas Steinmetz wrote:
> Ok, this is not in the kernel, but think of the following: an 
> application needs and include/asm header. The application may be 
> compiled as 32 bit and as 64 bit. Then you could use a real asm 
> directory instead of a symlink and use, e.g. for asm/byteorder.h:
> 
> #ifdef __x86_64__
> #include <asm-x86_64/byteorder.h>
> #else
> #include <asm-i386/byteorder.h>
> #endif
> 

I think we can get rid of this hack when we move to split kernel headers.
parisc, s390 and mips already have combined headers, and it should not be
too hard to combine the user ABI headers for sparc, ppc and x86_64 as well,
without having to merge the complete architecture and kernel header trees
for them.

Building for ppc64 would then use something like 'gcc -Iinclude
-Iinclude/ppc64 -Iinclude/user -Iinclude/user/ppc/' for a layout
that has files in

include/linux/foo.h
include/$arch/asm/foo.h
include/generic/asm/foo.h
include/user/linux/foo.h           (installed as <linux/foo.h>)
include/user/$arch32/asm/foo.h     (installed as <asm/foo.h>
include/user/asm-generic/foo.h     (installed as <asm-generic/foo.h>

[Note how the first three become optional in this scheme. For files
 that need an internal version an a user version, ppc64/asm/foo.h
 can use #include_next <asm/foo.h> to get to generic/asm/foo.h and
 user/ppc/asm/foo.h.]

For ia64, the headers should probably stay separate because I would expect
them to differ more from i386/x86_64 than the other dual 32/64 architectures.
I don't think that is a problem because you need separate tool chains for
ia64 and i386 anyway, while the others can share the libc headers and the
compiler backend already.

	Arnd <><