Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[David Woodhouse <dwmw2@infradead.org>]

On Tue, 2004-11-30 at 16:37 -0800, Linus Torvalds wrote:
> 
> On Wed, 1 Dec 2004, David Woodhouse wrote:
> > 
> > The concept isn't at all hard to understand. But no patch is 'obviously
> > correct' if you want to protect against the _slightest_ possibility that
> > people might be abusing something you're taking away. 
> 
> I really disagree. That's kind of my point. We _can_ make sure that there 
> is abzolutely zero semantic content change.

We've _never_ made sure that there's absolutely zero semantic content
change in our private headers.

> People both inside and outside the kernel who use the old <linux/xxx.h>
> headers will get exactly what they got before if we do it right.

They'll get that if we change nothing at all.

> > Some people might define __KERNEL__ on purpose when compiling something
> > in userspace, to get something that would otherwise be hidden from them.
> > Would you consider that sacrosanct too?
> 
> Why _do_ you want to break things? Do the cleanup. Don't do the breakage.

I'm trying to understand precisely where _you_ want to draw the line
between 'cleanup' and 'breakage'. 

You obviously don't agree that including atomic.h was an entirely stupid
thing for userspace to be doing in the first place, and that it's
reasonable for that not to compile in future; you believe that it should
continue to compile and silently do the wrong thing. We've covered that
much.

So where _do_ you draw the line? Trying to use spinlock.h? Defining
__KERNEL__ before including kernel headers?

I can try to apply common sense here, having discussed it with a bunch
of other people. But you don't seem to agree with that; hence further
guidance would be appreciated. But we can just submit patches to do the
cleanups and see what you take and what you don't, if you really want to
make us jump through hoops for the sake of it without indicating what
you'd accept and what you'd not beforehand.

-- 
dwmw2