Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

Andreas Steinmetz
2004-11-27T21:50:09Z

Sam Ravnborg wrote:
> On Sat, Nov 27, 2004 at 10:11:43PM +0100, Andreas Steinmetz wrote:
>
>>>If we go for some resturcturing of include/ then we should get rid of
>>>the annoying asm symlink. Following layout deals with that:
>>>
>>>include/<arch>/asm <= Files from include/asm-<arch>
>>>include/<arch>/mach* <= Files from include/mach-*
>>>
>>>This layout solve the symlink issue in an elegant way.
>>>We need to do trivial changes to compiler options to make it work. Changing
>>>compiler options is much more relaible than using symlinks.
>>>
>>>Then the userspace part would then be located in:
>>>include/<arch>/user-asm
>>>
>>
>>This complicates things for bi-arch architectures like x86_64 where one
>>can use a dispatcher directory instead of a symlink to suit include/asm
>>for 32bit as well as 64bit.
>
> X86_64 does not create any special symlinks todays so I do not see the point?
> And still a symlink is just the wrong way to solve the problem.
> Adjusting options to the compiler is the way to do it.

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

This way both archs are satisfied from a userspace point of view without
having to take care if the source is compiled on 32bit or 64bit. If
you kill the symlink this neat dispatcher can't really be done anymore
that easy.
It is not necessary to do anything in the kernel tree here except to
keep the symlink to allow for this kind of userspace tweaks for certain
architectures.
This is especially important when there's need to use a include/linux
header which itself needs an include/asm header as in this case with the
the little tweak always the right asm header is included.
--
Andreas Steinmetz SPAMmers use robotrap@domdv.de