Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

Linus Torvalds
2004-11-30T15:58:28Z

On Tue, 30 Nov 2004, David Woodhouse wrote:
>
> On Mon, 2004-11-29 at 09:41 -0800, Linus Torvalds wrote:
> > In fact, in many ways I'd prefer to have source-level annotations like
> > "this is exported to user space" over trying to gather things in one
> > place.
>
> I don't think you would; not once you really tried it.
>
> That's what the littering of ifdef __KERNEL__ attempts to do, and
> there's not really any better way of doing it than that.

The fact is, despite this stupid and way-too-long thread, #ifdef
__KERNEL__ has worked for over a decade, and works damn well, everything
considered.

Remember the second-system-syndrome? It comes from people wanting to fix
problems in the current implementation, without thinking about all the
things that it does _well_ (because the things that work are not on their
radar - they just work). And no, __KERNEL__ may not be pretty, but it's
damn simple to fix up, and one thing it does really well is allow
flexibility in a way that forcing structure does not.

I know people like "structure". But it's _waayyy_ overrated. The reason we
use C instead of some other programming environment is not that C is the
most highly structured language around, but it's the most _flexible_ one,
largely because it says "let's give people rope". It allows structure, but
if you want to cast things around and use gotos, it says "sure, master,
you're the boss".

Same thing here. The __KERNEL__ approach says "whatever you want, boss".
It doesn't get in the way. Maybe it doesn't actively _help_ you either,
but you never have to fight any structure it imposes on you.

Also, there _are_ better ways of annotating it than __KERNEL__. In
particular, if we had a "user annotation", I could make sparse sit up and
take notice, and _complain_ when you use a non-specific-sized type. That's
not just theory - Al Viro was talking about that at some point.

Linus