Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

Linus Torvalds
2004-12-01T00:11:23Z

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