Re: asm-offsets.h is generated in the source tree

[Sam Ravnborg <sam@ravnborg.org>]

> OK...  Once that goes in, I'm doing s/prepare1/archprepare/ in there.
> Note that kern-offsets.c expects to find user_constants.h and symlinks
> already in place - it assumes that all kernel headers are usable.
> kern_constants.h is used only by userland glue, task.h and thread.h and
> these, in turn, are used only by userland glue.

Sent to Linus, assume it will be merged soon.

> 
> So ordering constraints are
> 	symlinks and user_constants.h are needed to get kernel headers usable
> 	kern_constants.h needs kernel headers
> 	kernel code needs kernel headers
> 	parts of userland glue need kern_constants.h
> 
> FWIW, we could rename user-offsets.c to asm-offsets.c and let the regular
> mechanism take care of them (renaming user_constants.h at the same time,
> obviously).  Critical part here is "kernel-offsets.c expects kernel headers
> usable", everything else could be trivially dealt with...

No. For once the flags to gcc differs for userland and kernelland.
Of the two candidates only kern_constants.h could be dealt with by
the generic support.

> Note that kern_constants.h must *NOT* go into include/asm-um - we need it
> in userland glue which doesn't get include/ in its search path.
And this killed the idea of using the generic support - not a big deal
anyway.


> So reducing
> the number of symlinks won't be trivial.  We could, in principle, move
> kern_constants.h to e.g. include/asm-um/user/, include that in userland
> glue search path and try to fight the rest, but that won't be fun.
> 
> One particulary nasty bit: we have both per-subarch headers in asm-um _and_
> headers in there that do something and proceed to include corresponding
> header from asm-<subarch>.  Currently we do that with
> 	include/asm-um/arch ----> include/asm-<subarch>
This just shows how horribly broken the symlink scheme is in the first
place.

If the kernel had used a scheme like the following everything could be
solved by a few -I statements:

include/i386/asm/<what we have in include/asm-i386 today>
include/ia64/asm/<what we have in include/asm-ia64 today>
etc.

Then to use ia64 we would just use:
-Iinclude/ia64

And in um land we could do exactly the same with no ugly symlinks.

> 	include/asm-um/foo.h ---> include/asm-um/foo-<subarch>.h for
> the first kind and
> 	#include <asm/arch/foo.h> in foo.h for the second one.
> 
> We also have arch/um/include/sysdep -> sysdep-<subarch>, but that's easier
> to deal with...
Here we should do like this:
arch/um/include/<subarch>/sysdep/<files from sysdep-<subarch>>
Again no ugly symlinks needed.

Another benefir that is often overlooked.
With kbuild checking the compileflags everything 'just works' when we
change sub-arch. No need to make clean etc.


I know this is a lot of renaming and I have not seen a really good
argument to convince Linus to rename include/asm-<arch>.
But for um I see no big dela doing the renaming, especially since most
of currect code should work out-of-the-box even with the changes
introduced.

	Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/