Is there a utility that creates a .config based on analysis of the
target system?
Scott Robert Ladd wrote:
Now that's a great idea ..... :-)
Jeff
>Is there a utility that creates a .config based on analysis of the
>target system?
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
jmerkey wrote:
> Scott Robert Ladd wrote:
>
> Now that's a great idea ..... :-)
> Jeff
>
>> Is there a utility that creates a .config based on analysis of the
>> target system?
>> -
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>>
>>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I think Netbsd has something like this, maybe this is a good example.
Matthias-Christian Ott
On Thu, May 12, 2005 at 11:07:24AM -0600, jmerkey wrote:
> Scott Robert Ladd wrote:
> >Is there a utility that creates a .config based on analysis of the
> >target system?
>
> Now that's a great idea ..... :-)
And how would it guess if you want iptables support enabled or not?
Which device drivers to include is not the only thing that goes in
.config after all.
A simpler solution is turn on everything as modules, and let
hotplug/discover figure it out at boot time. :)
Len Sorensen
On Thu, 2005-05-12 at 20:21 +0200, Matthias-Christian Ott wrote:
> jmerkey wrote:
> > Scott Robert Ladd wrote:
> >
> > Now that's a great idea ..... :-)
> > Jeff
> >
> >> Is there a utility that creates a .config based on analysis of the
> >> target system?
> >> -
This probably isn't what you are looking for, but I posted this a while
back, and have found this useful for myself.
I wrote a simple perl script (attached) to turn off all the modules that
are not being used on the current system. Obviously if you have a USB
device that's not attached, it would get turned off too. But this was
nice to see what modules I actually needed to get a system running.
You first compile the kernel with the default distribution .config.
Then run this script in the directory of the kernel that's running, and
has that .config available. The output of a .config with all non
necessary modules turned off is sent to standard output.
-- Steve
jmerkey wrote:
>
> Scott Robert Ladd wrote:
> >
> >Is there a utility that creates a .config based on analysis of the
> >target system?
>
> Now that's a great idea ..... :-)
Not really new though :-)
http://sourceforge.net/projects/kautoconfigure/
Ciao, ET.
On Thursday 12 May 2005 23:17, Edgar Toernig wrote:
> jmerkey wrote:
> > Scott Robert Ladd wrote:
> > >Is there a utility that creates a .config based on analysis of the
> > >target system?
> >
> > Now that's a great idea ..... :-)
>
> Not really new though :-)
>
> http://sourceforge.net/projects/kautoconfigure/
>
> Ciao, ET.
how about /proc/config.gz.. although this was pretty recent IIRC.
Regards,
Boris.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Sun, 15 May 2005 09:03:42 +0200, Borislav Petkov said:
> On Thursday 12 May 2005 23:17, Edgar Toernig wrote:
> > jmerkey wrote:
> > > Scott Robert Ladd wrote:
> > > >Is there a utility that creates a .config based on analysis of the
> > > >target system?
> how about /proc/config.gz.. although this was pretty recent IIRC.
That describes the currently running kernel *as built* - so for instance
booting a RedHat kernel on almost anything will show 3 zillion things
built as modules - including 2.5 zillion things that aren't needed in the
current config (for instance, every single sound card driver may be included).
What is desired is a utility that will do an lspci/lsusb/etc and build up
a .config that matches *the current hardware* (for instance, only including
a module for the one sound card that's actually installed).
On Sun, 15 May 2005 [email protected] wrote:
> On Sun, 15 May 2005 09:03:42 +0200, Borislav Petkov said:
> > On Thursday 12 May 2005 23:17, Edgar Toernig wrote:
> > > jmerkey wrote:
> > > > Scott Robert Ladd wrote:
> > > > >Is there a utility that creates a .config based on analysis of
> the
> > > > >target system?
> > how about /proc/config.gz.. although this was pretty recent IIRC.
> That describes the currently running kernel *as built* - so for instance
> booting a RedHat kernel on almost anything will show 3 zillion things
> built as modules - including 2.5 zillion things that aren't needed in
> the
> current config (for instance, every single sound card driver may be
> included).
> What is desired is a utility that will do an lspci/lsusb/etc and build
> up
> a .config that matches *the current hardware* (for instance, only
> including
> a module for the one sound card that's actually installed).
>
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
either). Or just use good old "make menuconfig" to only enable the module
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.
--
Jesper Juhl
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.. ;)
On 5/13/05, Edgar Toernig <[email protected]> wrote:
> jmerkey wrote:
> >
> > Scott Robert Ladd wrote:
> > >
> > >Is there a utility that creates a .config based on analysis of the
> > >target system?
> >
> > Now that's a great idea ..... :-)
>
> Not really new though :-)
>
> http://sourceforge.net/projects/kautoconfigure/
>
is this project basically dead?
this idea is not new, but still top of my wish-list for kernel
compiling. just wonder when such a great tool come up?
regards,
aq
Jesper Juhl wrote:
> 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
> either).
A desktop computer with a large hard drive may be the norm for kernel
developers, but it isn't (by far) the only environment where the kernel
is built. Embedded devices, small systems, older hardware, and
heterogenous networks all require a bit more finesse than a simple
"build it all and throw the mess at the hardware" approach.
The complexity of the kernel is growing, making it more difficult for
people to understand what they need and how to get it. It seems to me
that a computer can analyze itself to determine the "best" build
options. That's part of the reasoning behind my Acovea technology --
reducing complexity through smarter software.
http://www.coyotegulch.com/products/acovea
Acovea isn't directly applicable to the kernel, but the idea of the
computer performing self-discovery is certainly valid. Once I get
another project finished, I'm going to take a more formal look at kernel
configuration, and see what might be done.
..Scott
Once again, check out
http://www.kihontech.com/code/streamline_config.pl :-)
On Sun, 2005-05-15 at 07:13 -0400, [email protected] wrote:
> 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. ;)
>
I have to do a bit of traveling, and one time I didn't want to bring my
main laptop, and instead brought along my 75MHz IBM Thinkpad 755CX. (a
professor laughed at me and jokingly offered me his palm pilot as an
upgrade!). I actually used this to do kernel compiles. So this can take
quite some time on this type of hardware.
> > 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).
>
With this simple script, you only need to use what the distribution
installed (hopefully it also installs the .config that is used). And the
script will remove all the modules but the ones that are loaded.
-- Steve
Hi
For my endthesis I wrote a Framework that
automatically generates a Kernel-Configuration .
A Kernel-Patch, the sources and a readme are attached
to this mail. For more details please read the readme.
Comments and suggestion are welcome.
Regards
Ahmad Reze Cheraghi
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
(update)
Hi everybody
For my endthesis I wrote a Framework that
automatically generates a Kernel-Configuration .
A Kernel-Patch, the sources and a readme are attached
to this mail. For more details please read the readme.
Comments and suggestion are welcome.
Regards
Ahmad Reze Cheraghi
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com