From: Adrian Bunk <bunk@stusta.de>
To: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
Cc: "Randy.Dunlap" <rdunlap@xenotime.net>,
Sam Ravnborg <sam@ravnborg.org>,
hch@infradead.org, dwmw2@infradead.org,
linux-kernel@vger.kernel.org, torvalds@osdl.org, akpm@osdl.org
Subject: Re: RFC: cleaning up the in-kernel headers
Date: Wed, 12 Jul 2006 00:40:06 +0200 [thread overview]
Message-ID: <20060711224006.GG13938@stusta.de> (raw)
In-Reply-To: <20060711213733.GB21448@wohnheim.fh-wedel.de>
On Tue, Jul 11, 2006 at 11:37:33PM +0200, Jörn Engel wrote:
> On Tue, 11 July 2006 13:41:06 -0700, Randy.Dunlap wrote:
> > On Tue, 11 Jul 2006 21:41:07 +0200 Sam Ravnborg wrote:
> >
> > > > JÃrn Engel IIRC created a perl scrip that did this a year or two ago.
> > > > Try googling a bit.
> > > http://lkml.org/lkml/2003/10/1/74
> >
> > That is version 2 of the script. There are also versions 3 & 4.
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&w=2&r=1&s=check+headers+for+complete+includes&q=t
>
> Boy, it took me a while to remember what I did back then. In
> principle, the script just compiles trivial c files with a single
> #include <linux/foo.h>
> inside.
Sure, but it seems quite useful for this task.
> Not too bad in principle, but there were two problems I couldn't
> solve:
> 1. One of the goals should be to make a compile faster, not slower.
> Adding further includes hardly helps.
For me, this is not a goal.
It might perhaps be a side effect, but I care about correctness, not
about compile time.
> 2. It is practically impossible to test every possible combination of
> #ifdefs in the various headers pulled in.
It's not perfect, but it finds a subset of the problems.
There also other possible problems like stuff only used in a #define.
The perfect is the enemy of the good.
> Problem 1 would be fairly simple, as the script could be changed
> slightly to prune single #include lines from headers and see if they
> still compile. But then there is problem 2.
>
> One possibility to tackly problem 2 would be to create a set of config
> files to use for automatic testing. Instead of compiling once, a
> header must get compiled with every config in the set. Hopefully this
> set would not grow too big.
>
> And in the end, there is just so much you can automate. Humans have
> to think about the changes before sending patches.
i don't think the header cleanup could be completely automated.
But if automated tools help that's a good thing.
> Jörn
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
next prev parent reply other threads:[~2006-07-11 22:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-11 16:06 RFC: cleaning up the in-kernel headers Adrian Bunk
2006-07-11 16:28 ` David Woodhouse
2006-07-11 17:33 ` Christoph Hellwig
2006-07-11 19:34 ` Sam Ravnborg
2006-07-11 19:41 ` Sam Ravnborg
2006-07-11 20:41 ` Randy.Dunlap
2006-07-11 21:37 ` Jörn Engel
2006-07-11 22:01 ` H. Peter Anvin
2006-07-11 22:20 ` Jörn Engel
2006-07-11 22:39 ` Linus Torvalds
2006-07-11 22:40 ` Adrian Bunk [this message]
2006-07-11 21:04 ` David Woodhouse
2006-07-11 22:24 ` Adrian Bunk
2006-07-11 17:07 ` Dave Jones
2006-07-11 17:15 ` Joshua Hudson
2006-07-11 18:19 ` Dave Jones
2006-07-11 22:27 ` Adrian Bunk
2006-07-11 19:05 ` Russell King
2006-07-11 22:19 ` Adrian Bunk
2006-07-11 20:26 ` [PATCH] Fix broken kernel headers preventing ARM build Russell King
2006-07-13 19:05 ` RFC: cleaning up the in-kernel headers Christoph Lameter
2006-07-15 4:18 ` Steven Rostedt
2006-07-15 4:59 ` Christoph Lameter
2006-07-17 0:53 ` Steven Rostedt
2006-07-20 10:56 ` Adrian Bunk
2006-07-14 0:11 ` David Woodhouse
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=20060711224006.GG13938@stusta.de \
--to=bunk@stusta.de \
--cc=akpm@osdl.org \
--cc=dwmw2@infradead.org \
--cc=hch@infradead.org \
--cc=joern@wohnheim.fh-wedel.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
--cc=sam@ravnborg.org \
--cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.