Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 12/01/04

  • Next message: Greg KH: "Re: [PATCH] I2C fixes for 2.6.10-rc2" 
    Date:	Tue, 30 Nov 2004 16:10:45 -0800 (PST)
To: David Woodhouse <dwmw2@infradead.org>

    On Tue, 30 Nov 2004, David Woodhouse wrote:
    >
    > Linus, you're arguing that it's better to let users use something which
    > is non-portable and silently does the wrong thing, as long as it
    > actually compiles. That this is preferable to making sure it doesn't
    > compile.

    I'm saying that if it worked before, it should work after. And my
    suggestion gives a nice warning.

    > But atomic.h isn't an example of that.

    Even atomic.h. I could well imagine that somebody includes atomic.h just
    to get the thread-safe updates for some architectures. For example,
    asm-alpha/atomic.h does it right, and I woul dnot be at all surprised if
    somebody had noticed.

    And your suggestion has the problem that the people who get bitten by a
    non-compiling thing are not necessarily the same people who can fix it.

    > software'? Of course not; you have to draw the line somewhere. And I
    > would draw it somewhere between atomic.h and byteorder.h -- where would
    > _you_ draw it?

    I'll draw it at "somebody might validly use it", because the fact is, I
    can't test it.

    Which is why I want patches to this to be OBVIOUSLY CORRECT, dammit! How
    hard is that to understand?

    The fact is, the less benefit there is from a change, the more obviously
    correct it has to be in all forms. Moving stuff around in header files
    basically fixes zero bugs in the kernel, so the benefit for the kernel is
    basically zero. Which means that the obviousness factor of the change had
    better be pretty close to infinite.

    Comprende?

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

  • Next message: Greg KH: "Re: [PATCH] I2C fixes for 2.6.10-rc2"

    Relevant Pages

    • Re: kernel BUG at raid5.c:337!
      ... > a Linux example in Slashdot's public BSOD sightings... ... local-patched kernel since 2.2.something, even if you found one with a ... machine wanted a suggestion, is "Upgrade to a current kernel". ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 1/3] 2.6.8-rc4-mm1 - Fix UML build
      ... can access them all, and initialized data all before uninitialized, so ... SYMLINKS:= $,$/$f) ... semaphore.c-dir = kernel ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Discourage Uniform Driver Model
      ... > Modules must be compiled for each specific kernel release. ... > create an abstract interface between the two. ... This technique is used in everything ... This "suggestion" is sufficiently uninteresting to everyone that your ...
      (Linux-Kernel)
    • Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
      ... > rebooted to a kernel that doesn't have the RT-preempt patch but ... getting a very verbose running trail, almost like an strace output, ... Copyright 2005 by Maurice Eugene Heskett, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • RE: Error mounting root fs on 72:01 using Promise FastTrak TX2000 (PDC20271)
      ... > Now I'm sucessfully booting my system with the 2.4.23 kernel using ... I think it's when the ATARAID driver is about to fire up. ... > the hard drives since this is the only thing that has changed. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)