From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933793AbWK3J7i (ORCPT ); Thu, 30 Nov 2006 04:59:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933753AbWK3J7i (ORCPT ); Thu, 30 Nov 2006 04:59:38 -0500 Received: from nic.NetDirect.CA ([216.16.235.2]:25559 "EHLO rubicon.netdirect.ca") by vger.kernel.org with ESMTP id S933793AbWK3J7h (ORCPT ); Thu, 30 Nov 2006 04:59:37 -0500 X-Originating-Ip: 74.102.209.62 Date: Thu, 30 Nov 2006 04:55:59 -0500 (EST) From: "Robert P. J. Day" X-X-Sender: rpjday@localhost.localdomain To: Alexey Dobriyan cc: linux-kernel@vger.kernel.org Subject: Re: just how "sanitized" are the sanitized headers? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Net-Direct-Inc-MailScanner-Information: Please contact the ISP for more information X-Net-Direct-Inc-MailScanner: Found to be clean X-Net-Direct-Inc-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-16.8, required 5, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -15.00) X-Net-Direct-Inc-MailScanner-From: rpjday@mindspring.com Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 30 Nov 2006, Alexey Dobriyan wrote: > On 11/30/06, Robert P. J. Day wrote: > > i noticed that, when i generate the sanitized headers with "make > > headers_install", there are still a number of headers files that are > > installed with variations on "#ifdef __KERNEL__". > > > > i always thought the fundamental property of sanitized headers was > > to be compatible with glibc > > You were wrong. ok, my fault, i worded that badly. i have a *general* idea of the purpose of sanitized headers -- i've been using a pre-built set for crosstool for quite some time, and i'm assuming that (theoretically) i should be able to replace that pre-built set with what's generated by "make headers_install", is that right? (BTW, what is the proper description for the sanitized headers? there's *nothing* in the kernel source tree documentation that explains their creation.) > > and have no traces of "KERNEL" content > > left. > > That's correct. good. at least *that* part i got right. :-) > > so what's the purpose of leaving some header files with that > > preprocessor content? > > When you see __KERNEL__ in sanitized headers, it's either due to > a) unifdef bug, or > b) header being listed in header-y when it should be listed in unifdef-y a couple things going on here, actually. in the simple case, there are three header files: linux/if_fddi.h linux/personality.h linux/wireless.h that can be fixed simply by adding "unifdef-y" entries for them to the Kbuild file (i can submit a patch shortly). but there are a few other cases which still contain compound preprocessor directives such as: #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) having never worked with unifdef before, i guess i was being overly optimistic in thinking that it, if i "unifdef"ed __KERNEL__, it might at least simplify the expression. oh, well ... live and learn. rday