On Thu, 18 Sep 2008 22:17:22 +0200, Takashi Iwai said:

quoted text
> 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*....