linux-kernel - Re: [PATCH 4/8] x86: remove dupilcated #include

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] [day] [month] [year] [list]

Message-ID: <20090409043053.GG20692@elte.hu>
Date:	Thu, 9 Apr 2009 06:30:53 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Sam Ravnborg <sam@...nborg.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Huang Weiyi <weiyi.huang@...il.com>, mingo@...hat.com,
	hpa@...or.com, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/8] x86: remove dupilcated #include


* Sam Ravnborg <sam@...nborg.org> wrote:

> > > 
> > > I assume you are aware that when you minimize the # of include 
> > > file in the various .c files, then you implicitly add dependency 
> > > on the includes the individual .h files have.
> > 
> > Yes. Look at the commit -tip that does the above change (also 
> > attached below):
> > 
> >   a2bcd47: x86/mm: further cleanups of fault.c's include file section
> > 
> > that commit uncovered a masked-until-then dependency bug in one of 
> > the x86 include files.
> 
> We have plenty of header files that needs other header files to be
> included in order to build.
> 
> I tried to do a simple build check with a i386 defconfig.
> It revealed that the appended list of header files did not build.
> 
> What I did was to create a simple:
> 
> module.h.c file containing:
> #include <linux/module.h>
> 
> And then I used kbuild to build the file,
> adding "obj-y += module.h.o" to Kbuild.
> 
> I did so for all header files in include/linux/
> and result was that 172 header files failed to build.
> 
> Some of these was expected since they are not supposed to be
> included direct. But the rest should build have
> build with no errors?
> 
> I can automate the above included some way to say which header files
> we should NOT build.
> But eliminating the includes that are not needed is a bigger challenge
> and also the biggest win :-(
> Is it worthwhile to make the header files buildable alone?

I think it is definitely worthwile, for a couple of reasons:

 - a data type definition that does not even build if included in a 
   .c file is broken, almost by definition. If it happens to build 
   in its current include file environment that's just a hidden bug, 
   nothing more.

 - having such a check would simplify header dependency hell removal 
   efforts _immensely_. I could remove a suspect looking #include 
   line from a header and build with your check - that would be a
   pretty good mechanism to drive header file simplification
   efforts. (Human review goes only so far and it has failed to
   reach its goal in the past 15 years, as it only addressed the
   most obvious excesses.)

If we are too broken right now then maybe make it only available to 
someone explicitly interested in it, via make 
CONFIG_DEBUG_HEADER_DEPENDENCIES=y or so?

	Ingo
--
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/