Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[David Howells]

> 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.

It's a pain, which is why people want to do something about it.

> 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.

And allows abuse and doesn't penalise laziness; both of which do happen in the
kernel header files.

> 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".

We use C & ASM for the kernel because you and others won't allow anything
else. Not that I'm necessarily endorsing the use of other languages - I like C
and ASM; I just look at stuff in the kernel occasionally and know that other
languages handle it better and more efficiently. That is, however, besides the
point.

> 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.

It can get in the way accidentally.

> 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.

If you did user annotations you'd have to solve the problem of applying it to
#defines and still allowing the constants to be used in assembly. Obviously
this is not impossible. This is trivial with __KERNEL__ or separation into
other files.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/