lkml.org 
[lkml]   [2005]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: asm-offsets.h is generated in the source tree

> 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/

\
 
 \ /
  Last update: 2005-09-12 00:05    [W:0.068 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site