Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Linus Torvalds <torvalds@osdl.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