[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <497F9740.4000505@zytor.com>
Date: Tue, 27 Jan 2009 15:22:40 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: Ingo Molnar <mingo@...e.hu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Sam Ravnborg <sam@...nborg.org>,
Jaswinder Singh Rajput <jaswinderrajput@...il.com>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [mingo@...e.hu: [git pull] headers_check fixes]
Linus Torvalds wrote:
>
> So I think it makes our headers worse. Code like
>
> > +#ifdef __KERNEL__
> > +# ifdef CONFIG_X86_BSWAP
> > +# define __X86_BSWAP
> > +# endif /* CONFIG_X86_BSWAP */
> > +#endif /* __KERNEL__ */
>
> just doesn't make sense. It doesn't make sense _inside_ the kernel, and it
> doesn't make sense _outside_ it either.
>
> As far as I can tell, the header install script could literally just do
> something like run 'sed' over the headers as it installs them, and do
> something like
>
> sed 's/\<CONFIG_[A-Z0-9_]*\>/__kernel_only__/g'
>
> which I realize is not really the complete/correct solution (ie you could
> write a nicer thing that does a better job), but my point here is that
> rather than have scripts that _whine_ about these kinds of trivial things
> and cause people to write less readable header files, we should just make
> sure that if we can recognize them so easily, we can just fix them
> instead.
>
We already run the headers through unifdef, so this should be trivial to
add.
The intent of headers_check is to try to catch people who put things
that depend on CONFIG_* stuff in exported headers (which, as we have
seen, have been too sadly common.) If we declare that the export
process will treat all CONFIG_* as undefined, we do lose some coverage
but potentially end up with cleaner code. Not sure which is worse...
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists