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
prev parent 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