[lkml]   [2000]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RLIM_INFINITY inconsistency between archs
    "Theodore Y. Ts'o" <tytso@MIT.EDU>:
    > From: (Linus Torvalds)
    > Date: 27 Jul 2000 00:39:51 -0700
    > I would suggest that people who compile new kernels should:
    > - NOT do so in /usr/src. Leave whatever kernel (probably only the
    > header files) that the distribution came with there, but don't touch
    > it.
    > - compile the kernel in their own home directory, as their very own
    > selves. No need to be root to compile the kernel. You need to be root
    > to _install_ the kernel, but that's different.
    > - not have a single symbolic link in sight (except the one that the
    > kernel build itself sets up, namely the "linux/include/asm" symlink
    > that is only used for the internal kernel compile itself)
    > May I suggest one slight change to this list? /usr/src/linux should be
    > a symlink to the header files of whatever kernel is being booted by
    > default. So you can compile your own kernel in your own home directory,
    > but when you install your own kernel as the default boot kernel,
    > /usr/src/linux should point to the header files of that kernel. As you
    > say, it requres root to _install_ your own kernel, and that point, you
    > can point /usr/src/linux at the appropriate place.
    > This allows source packages which generate kernel modules which have to
    > link against the current kernel ---- such as the external pcmcia driver,
    > hich you've recommended that distro's use since 2.4's pcmcia support
    > isn't quite up to snuff yet ---- be able to reliably find (or at least
    > present the user with a sensible default) the header files of the kernel
    > which is being installed as the default boot kernel.
    > And this is actually what has been the suggested environment for at
    > least the last five years. I don't know why the symlink business keeps
    > on living on, like a bad zombie. Pretty much every distribution still
    > has that broken symlink, and people still remember that the linux
    > sources should go into "/usr/src/linux" even though that hasn't been
    > true in a _loong_ time.
    > The problem is that unless you are trying to say that you want to outlaw
    > external source packages which generate kernel modules, there needs to
    > be some way for such packages to be able to find the kernel header
    > files.
    > Other solutions include having a standard mechanism for dropping
    > external packages into the kernel source tree, which will then compile
    > those modules as their own. (Apache supports a model like this).
    > Or, we could make some other symlink point at the sources of the kernel
    > which is booting by default.

    Might I suggest creating a "/lib/include" that works something like
    the /lib/modules where the kernel name is used to generate the directory
    for the kernel include files?

    That way the "uname -r" command could be used to set a symbolic link
    to point to the correct include files at boot time (or install time).

    Since /lib/include could contain
    2.4.0/(kernel includes)
    2.4.0-SMP/(kernel includes)
    2.4.0-RSBAC.SMP/(kernel includes)

    Then at boot time (before SV init or init really takes over)
    the commands:
    ( cd /lib/include
    rm linux
    ln -s `uname -r` linux )

    This way the kernel that is active would be selecting the correct includes.

    The build makefile could have an additional target - includes, that
    would create the directory and copy the include files.

    Jesse I Pollard, II

    Any opinions expressed are solely my own.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.023 / U:12.384 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site