lkml.org 
[lkml]   [2000]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RLIM_INFINITY inconsistency between archs


    On Thu, 27 Jul 2000, Theodore Y. Ts'o wrote:
    >
    > 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.

    No.

    It still means that the kernel header files would have to be source-level
    backwards compatible forever. Something which hasn't been true in the
    past, and I don't want to be true in the future either. It's been damn
    painful to not be able to clean stuff up because some user-level setup is
    wrong.

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

    Yes. By hand. By the maintainer. And _independently_ of what random user
    Joe Blow has on his particular installation.

    Because it's not unreasonable AT ALL to have those packages be compiled
    with newer header files than the user even has access to. Imagine a ext2
    library that wants to support new features of the filesystem, compiled on
    a box that only has 2.2.13 installed. Neve rever had anything newer.

    Should that newer source package dumb itself down to 2.2.13 level, so that
    the e2fsck doesn't know how to handle new filesystems? Sure, the user
    obviously isn't using them _now_, but wouldn't it be a lot nicer if you
    just had a source tree that ended up generating the same binary that you
    as the maintainer has? With all the new features, just suppressed by the
    fact that it ends up running on a old-style filesystem image..

    Trust me, it's STUPID to have user-level binaries that end up different
    depending on what machine they were compiled on. We've had exactly that
    happen, and it's a BUG. It's nasty to debug.

    Think about it. You have machine X and machine Y, and they both have the
    ext2-programs compiled with the same compiler from the same sources with
    the same libraries. Would you _really_ consider it acceptable if they act
    differently?

    I don't. And that is why I will continue to maintain that it is WRONG to
    have that symlink. No ifs, buts of other crap. Just face reality.

    Linus


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

    \
     
     \ /
      Last update: 2005-03-22 13:57    [W:4.692 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site