Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261991AbUK3PeE (ORCPT ); Tue, 30 Nov 2004 10:34:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262017AbUK3PeE (ORCPT ); Tue, 30 Nov 2004 10:34:04 -0500 Received: from mx1.redhat.com ([66.187.233.31]:44735 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S261991AbUK3Pdz (ORCPT ); Tue, 30 Nov 2004 10:33:55 -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> To: Linus Torvalds 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__ 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 15:33:36 +0000 Message-ID: <8219.1101828816@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1978 Lines: 42 > 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? This should obviate the requirement for such marking (because it's implicit in the location). Getting rid of the #ifdefs would also make the "Thou shalt not use #ifdef" camp happier. Doing this really shouldn't break the syscall API/ABI at all; barring of course the potential change of location within /usr/include/ of the installed headers, but that is simple to address. All this does is to separate out the userspace available structures and constants. I can grant that you might not want to use stdint types because not all the toolchains that might be used on the kernel support them, but that's not a reason to throw out the whole proposal. 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. However, I can see that there may be objections due to the fact that types may become different logical sizes, and thus cause warnings in printf-format string checking and pointer casting. Also, the comparison you made to modules isn't exactly valid. We annotate variables and functions that modules are allowed to access, but we never export these to userspace directly; and we don't annotate structures, inline functions, constants and macros into which categories the user-visible stuff falls for use by modules. 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/