From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14821 invoked by alias); 30 Nov 2004 21:30:49 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 14805 invoked from network); 30 Nov 2004 21:30:49 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 30 Nov 2004 21:30:49 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iAULUiPO009120 for ; Tue, 30 Nov 2004 16:30:44 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iAULUhr10636; Tue, 30 Nov 2004 16:30:43 -0500 Received: from livre.redhat.lsd.ic.unicamp.br (vpn50-17.rdu.redhat.com [172.16.50.17]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id iAULUgmX008927; Tue, 30 Nov 2004 16:30:42 -0500 Received: from livre.redhat.lsd.ic.unicamp.br (livre.redhat.lsd.ic.unicamp.br [127.0.0.1]) by livre.redhat.lsd.ic.unicamp.br (8.13.1/8.13.1) with ESMTP id iAULUfBn005680; Tue, 30 Nov 2004 19:30:41 -0200 Received: (from aoliva@localhost) by livre.redhat.lsd.ic.unicamp.br (8.13.1/8.13.1/Submit) id iAULUfJ8005674; Tue, 30 Nov 2004 19:30:41 -0200 To: Linus Torvalds Cc: David Howells , 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__ 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> From: Alexandre Oliva Organization: Red Hat Global Engineering Services Compiler Team Date: Tue, 30 Nov 2004 21:30:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-11/txt/msg00091.txt.bz2 On Nov 30, 2004, Linus Torvalds wrote: > On Tue, 30 Nov 2004, Alexandre Oliva wrote: >> >> - move anything that is not protected by #ifdef __KERNEL__ to the >> ukabi header tree, adding an include in the beginning of the original >> header that includes the ukabi header. > No. I want stuff that goes into the ABI tree to be clearly _defined_ to be > user-visible. Not a "let's move it all there and then prune it". Right. Which brings us to my second bullet. I *knew* I should have made it the first :-/ > Also, "ukabi" just isn't going to fly as a name. It's also not as simple > as you seem to think, since a lot of these ABI things are architecture- > dependent, which apparently all you guys have totally ignored. Looks like you missed the post that started this thread. It *did* mention machine-independent and machine-specific user headers. > I've suggested "include/user/" and "include/asm-xxx/user", which handles > architecture-specific parts too. I'm ok with doing it the other way > around, ie "include/user/" and "include/user/arch-xxxx". As I pointed out, `user' is a very bad name. As you said yourself, we're talking about the *kernel* ABI. So what's `user' supposed to mean? Was I so successful in my arguments that you now see it as the userland ABI? :-) > (a) it can't break anything (ie the old location still includes the new > one, exactly the same way) You mean it can't break anything in a kernel build, or it can't break anything except for userland apps that abused kernel headers and used to get away with that? > (b) there are people who will actually take _advantage_ of that > particular file (ie "just because I think so" doesn't fly). People who currently get to maintain duplicates of these header contents will take immediate advantage of these changes, since they will no longer have to maintain the duplicates. This is a major step forward in terms of maintainability for everybody else, at no expense to the kernel, that now gets to explicitly (as opposed to implicitly) document what is the ABI it's willing to comply with. It's a win for both ends. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}