Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262118AbUK3PwT (ORCPT ); Tue, 30 Nov 2004 10:52:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262120AbUK3PwT (ORCPT ); Tue, 30 Nov 2004 10:52:19 -0500 Received: from fw.osdl.org ([65.172.181.6]:52352 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S262118AbUK3PwI (ORCPT ); Tue, 30 Nov 2004 10:52:08 -0500 Date: Tue, 30 Nov 2004 07:51:37 -0800 (PST) From: Linus Torvalds To: David Howells cc: Alexandre Oliva , Paul Mackerras , Greg KH , David Woodhouse , Matthew Wilcox , hch@infradead.org, linux-kernel@vger.kernel.org, libc-hacker@sources.redhat.com Subject: Re: [RFC] Splitting kernel headers and deprecating __KERNEL__ In-Reply-To: <8219.1101828816@redhat.com> Message-ID: 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> <8219.1101828816@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2334 Lines: 57 On Tue, 30 Nov 2004, David Howells wrote: > > > But in general, I do kind of like the explicit marking. The same way we > > explicitly mark the functions inside the kernel that we expose to modules, > > we could try to mark the data structures and values that we expose to user > > space. That tends to "work". > > That gets trickier when it comes to #defines, I think. > > Do you really object that much to splitting the header files as I proposed? I object sternuously to your "the header files". If you can't even say _which_ header file, I'm not interested. If you can say "these X header files have this specific problem Y, and if we move part Z into a common area A, we'd solve it because B", that's a different matter. See what I'm saying? Whole-sale "move things around because we want to" I'm not interested in. Specific problems, yes. > Personally, I'd prefer us to move to using standard C99 types in lieu of u32 > and co at least for the interface to userspace because they are just that: > standard. No. I told you why it cannot and MUST NOT be done. Repeat after me: WE MUST NOT POLLUTE THE NAMESPACE! There are many cases where including a header file means you want the structure, but it does _not_ mean that you can expose totally unrelated types, even if those types happen to be used as part of the structure. See what I'm saying? In contrast, __u8/__u16/__xxx are explicitly defined by the relevant standards to be "system name space", and that is _exactly_ why we don't use the standard namespaces. And the fact is, the rules for _when_ you export _which_ standard types are just too damn hard, and more importantly, they are not something that the kernel headers should even be deciding. They depend on glibc internal things like __USE_BSD etc, and they depend on which standard you compile for, and sometimes even on which _version_ of the standard you compile for. I will not have that mess in the kernel. Which means that we do _not_ export any of the standard names. Which means that we can't _use_ any of them. End of story. Linus - 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/