public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Sam Ravnborg <sam@ravnborg.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Huang Weiyi <weiyi.huang@gmail.com>,
	mingo@redhat.com, hpa@zytor.com, x86@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/8] x86: remove dupilcated #include
Date: Thu, 9 Apr 2009 06:30:53 +0200	[thread overview]
Message-ID: <20090409043053.GG20692@elte.hu> (raw)
In-Reply-To: <20090408184305.GA332@uranus.ravnborg.org>


* Sam Ravnborg <sam@ravnborg.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

      reply	other threads:[~2009-04-09  4:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-06  9:20 [PATCH 4/8] x86: remove dupilcated #include Huang Weiyi
2009-04-08 12:21 ` Ingo Molnar
2009-04-08 13:58   ` Sam Ravnborg
2009-04-08 14:12     ` Ingo Molnar
2009-04-08 18:43       ` Sam Ravnborg
2009-04-09  4:30         ` Ingo Molnar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090409043053.GG20692@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=sam@ravnborg.org \
    --cc=weiyi.huang@gmail.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox