![]() | |||||||||||
Messages in this thread |
> 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/ | ||||||||||
| Last update: 2005-03-22 14:08 [from the cache] ©2003-2008 | |||||||||||