[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <31195.1221772167@turing-police.cc.vt.edu>
Date: Thu, 18 Sep 2008 17:09:27 -0400
From: Valdis.Kletnieks@...edu
To: Takashi Iwai <tiwai@...e.de>
Cc: Mauro Carvalho Chehab <mchehab@...radead.org>,
linux-kernel@...r.kernel.org
Subject: Re: diet-kconfig: a script to trim unneeded kconfigs
On Thu, 18 Sep 2008 22:17:22 +0200, Takashi Iwai said:
> There are different perspectives for this. My goal to reduce the
> build time with the existing kernel config for a specific hardware.
> That is, it makes eaiser to create another set of kernel with test
> patches or bisect.
One has to be careful here - I've more than once hit kernel bugs that I ended
up bisecting, which were dependent on the exact .config used. The most recent
was a deadlock during early boot if CONFIG_HID_COMPAT=y, which would have
been turned off by any sane kconfig trimmer. On the flip side, running a
trimmer wouldn't minimize my .config very much, because I've already set most
stuff I *never* use to 'n'.
And more than once, I've had a bisect go horribly awry and need to be re-started
because the bisect crossed back and forth over a commit that added a config
option, so doing a 'make oldconfig' at each iteration would re-prompt, and
I wasn't consistent in the reply I gave. Usually doesn't matter, except when
the broken code is in the support for the feature...
I *do* keep around a *very* minimal "only what I need to get to single-user"
config if build time is an issue...
Might be different if you're starting off with a distro config that's basically
an 'allmodconfig' - lotta fat to trim off *that*....
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists