Messages in this thread | | | From | David Howells <> | Subject | Re: [RFC] Splitting kernel headers and deprecating __KERNEL__ | Date | Tue, 30 Nov 2004 16:33:51 +0000 |
| |
> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |