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:
    >
    > (c) do a simple "generation" script. This is what I'd do in the case of
    > O_NOFOLLOW. In your makefile, just have
    >
    > nofollow.h:
    > grep define.*O_NOFOLLOW $(KERNELDIR)/include/asm-$(ARCH)/fcntl.h > nofollow.h
    >
    > The only problem with this sort of thing is that you need to somehow
    > find KERNELDIR. Some kind of convention to make it easy to set
    > KERNELDIR, even if it isn't /usr/src/linux because you don't like the
    > history and because stuff you don't like is depending on /usr/src/linux,
    > would be really useful. Say, for example, /boot/kernel-headers being a
    > symlink to the kernel headers corresponding to the default kernel to be
    > booted?

    No. You really miss the point. That _still_ makes the program depend
    differently on which kernel happens to be on which machine. Which is so
    obviously wrong that I don't understand how anybody can accept it.

    I know people who _routinely_ compile stuff over NFS on another machine
    simply because that other machine is a lot faster, and the network is
    fast. They expect the binary to be the same. And I agree 100% percent. It
    should NOT depend on your particular kernel configuration (and yes, some
    kernel header files actually _change_: they depend on whether the kernel
    was compiled for a PII or a i386 etc).

    Say you have a build-server that runs an older kernel because it doesn't
    really matter, and it's not running gnome etc. Say your desktop uses USB
    and you've upgraded. Or the reverse may be true, where the build-server is
    a SMP machine that uses a newer kernel because it handles the load better.

    With your approach, that build-server would be unable to generate programs
    that take advantage of the new features that somebody wanted to have in
    the program. They would generate programs that are doing things that the
    locally generated programs wouldn't be doing.

    What I mean is that the above generation-script should be generated
    _once_. The source gets distributed with the generated file, so that
    whatever happens you at least get reliable results in a reasonably
    heterogenous environment.

    A "normal user" would never generate nofollow.h at all. The generation
    script would be used by the _maintainer_ or by people who add new features
    (And yes, in the above example it's rather simplistic. A real example
    would generate the proper architecture ifdef's etc).

    I expect that library versions and compiler versions should matter to
    compiling programs. But I do _not_ want kernel versions to do that. It's
    already painful for people that you have to have the right library
    version. I'd _hate_ to see source code that says "requires kernel 2.3.99
    or higher sources in /usr/src/linux" in addition to saying "needs
    glibc-2.1.2 or newer for threading reasons".

    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.277 / U:0.276 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site