Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262168AbUK3Qeu (ORCPT ); Tue, 30 Nov 2004 11:34:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262173AbUK3Qes (ORCPT ); Tue, 30 Nov 2004 11:34:48 -0500 Received: from mx1.redhat.com ([66.187.233.31]:36328 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S262168AbUK3QeG (ORCPT ); Tue, 30 Nov 2004 11:34:06 -0500 From: David Howells In-Reply-To: References: <19865.1101395592@redhat.com> <20041125165433.GA2849@parcelfarce.linux.theplanet.co.uk> <1101406661.8191.9390.camel@hades.cambridge.redhat.com> <20041127032403.GB10536@kroah.com> <16810.24893.747522.656073@cargo.ozlabs.ibm.com> <1101828924.26071.172.camel@hades.cambridge.redhat.com> To: Linus Torvalds Cc: David Woodhouse , Alexandre Oliva , Paul Mackerras , Greg KH , Matthew Wilcox , hch@infradead.org, linux-kernel@vger.kernel.org, libc-hacker@sources.redhat.com Subject: Re: [RFC] Splitting kernel headers and deprecating __KERNEL__ User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Date: Tue, 30 Nov 2004 16:33:51 +0000 Message-ID: <9122.1101832431@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2378 Lines: 51 > 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/