lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 28 Jan 2009 22:06:33 +0100
From:	Sam Ravnborg <sam@...nborg.org>
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>,
	Jaswinder Singh Rajput <jaswinderrajput@...il.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [mingo@...e.hu: [git pull] headers_check fixes]

On Tue, Jan 27, 2009 at 02:57:23PM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 27 Jan 2009, Ingo Molnar wrote:
> > 
> > Should i perhaps not bother with the stuff below? Cannot turn off 
> > CONFIG_HEADERS_CHECK in my builds because it can cause build failures.
> 
> I really hate the patch. I think it's fundamentally flawed. I hate scripts 
> that test for things that are readable, and encourage people to then write 
> crap instead.
> 
> The thing is, the headers_check stuff is just wrong if it causes these 
> things, and I'd rather just turn it off.
> 
> If those 
> 
> 	#ifdef CONFIG_XYZ
> 
> things result in problems, then we should just make the rule be that we 
> turn that kind of string into
> 
> 	#if 0
> 
> automatically when exporting the kernel headers. IOW, just about 
> _anything_ that headers_check complains about automatically is something 
> that should just be _fixed_ automatically at header install time rather 
> than make the code harder to read.

Almost every single patch that makes code harder to read while removing
CONFIG_ references from the exported headers just take the wrong approach.

I read later in this thread that Ingo is planning to filter out these patches
so we can get the other ones in - good.

What we should try to do is to look at the bigger picture.
Sometimes the right answer is that this whole file should not
be exported or maybe only half should be exported.
But due to the fact that we have no established way to seperate
what is internal and what is exported *on the file level* people
keep sprinkling #ifdef __KERNEL__ all over the header files.

I checked include/linux - we have 494 places where we reference __KERNEL__
And that is in 237 files.
We export 354 files from this dir - so we already have > 100 files that is
exported to userspace without modifications.

So rather than start sprinkling the exported headers with "if 0" then
we should encourage to clean them and when accetable move them to
a dedicated abi directory.

This may need some cooperation with external parties such as glibc
and other libc variants. And we could improve here.

	Sam
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ