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.025 / U:58.972 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site