Re: Automatic .config generation

[Valdis.Kletnieks@vt.edu]

[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]

On Sun, 15 May 2005 11:52:51 +0200, Jesper Juhl said:
> What's the big gain? Where's the harm in just building all the sound
> modules - you only load one in the end anyway, and the space taken by the
> other modules is negligible with the disk sizes of today I'd say (ok,
> there's some extra build time involved, but that shouldn't be a big deal

If you're doing building and testing on an older/slower box, the build
time and disk size matters - there's 481 'y' or 'm' in my current .config, versus
1701 in the Fedora -1287 kernel.  Being able to do 3 build/reboot loops in
an hour versus one every 90 mins makes a big difference.  Being able to do a
build in 400M instead of 2G means that a 7G /usr/src/ partition can hold 8 or 9
trees, rather than 3 (useful for those "when did this start" regressions, especially
in combo with that 20 min versus 90 build time. ;)

> you want. Besides, it's not as if you have to redo your kernel config from
> scratch every time you want a new kernel. Make your favorite config once, 
> build and install that kernel and then when you want a newer kernel simply 
> either cd linux-<version>; zcat /proc/config.gz > .config ; make oldconfig 
> and then build the new kernel using your previous config.

Yes, that's easy if you're working on *the same hardware*, so new device drivers
aren't of interest, and the only thing 'make oldconfig' will prompt you for is
new non-driver functionality. However, that's not everybody...

The function is for building streamlined configs for new systems - you get
in a Frobozz2005 laptop, and although you probably have your own favorite set
of values for things like which netfilter modules to build, you probably have
*no* idea right off what device drivers you need. So you end up either going
the RedHat route and building it *all* anyhow, or spending a lot of time
figuring out which drivers you need for *this* box.  And you can't even trust
the vendor sometimes - the Dell laptop I'm typing on was part of a larger order.
A co-worker got another C840, and we had both ordered the same CD/RW-DVD drive.
Machines had consecutive Dell service/serial numbers - and different vendor
drives (mine had a Toshiba, his had something else).

I won't even *start* on the number of subtly different AC'97-ish sound chips
Dell has gone through.. ;)

If you have a better solution to the "minimize *total* time to build optimized
kernels for 12 different machines that just got dropped on your workbench
this morning" feel free to share.. ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]