Re: diet-kconfig: a script to trim unneeded kconfigs

[Takashi Iwai <tiwai@suse.de>]

At Fri, 19 Sep 2008 11:12:34 +0200,
Giacomo A. Catenazzi wrote:
> 
> Instead of replying all other emails, it is simpler to explain my
> approach.
> 
> The purpose of my program is to find all CONFIG_s, which are needed to 
> support all the hardware (and some more), and to show them in 
> menuconfig. This is the main difference with Takashi purpose:
> he wants to build a bootable (without initramfs) kernel, starting
> to an high modular kernel (usually found in distribution),
> so no usable on an already optimized machine.

Yes.  Your stuff would be actually helpful for people who want
a really slim kernel config.

> Anyway there are a lot of overlapping tasks, which we could
> exchange.

Right, for example, kconfig parser can be shared.
Mine is pretty simplistic, and very likely incomplete.

> My design (files and sample output are in 
> http://cateee.net/sources/autokernconf/autokernconf-2008-08-29/ ):
> 
> kdetect.sh: detects hardwares, in a redundant manner, in order
> to have data if there are missing one ore more between: /proc,
> /sys, lspci, ...
> 
> autokernconf.sh: a shell script which read the driver database
> (lkddb.list) and kdetect output; it generates the desired CONFIG_s.
> 
> So far, so simple, and similar to Takashi method. I only split
> the task in two programs (detection and configuration).
> 
> The big difference is in the additional program, which generated the
> driver database: it reads all sources, it checks 25 subsystems
> (see http://cateee.net/lkddb/statistics.html ), taking in account
> to preprocessors (#ifdef CONFIG_...), #defines, static strings, masks, 
> all architectures, etc.
> Additionally it parse Makefile and Kconfig to find the dependencies
> of every source file.
> 
> It misses some generic detection (CPU, memory), which Takashi is
> doing, and the kconfig integration.
> 
> So I think most part could be integrated with the Takashi proposal, and 
> doing optionally the parsing of full driver database.

Agreed.

I think a good start would be to integrate a simple version of parser
and trim-down mechanism into the upstream kbuild system, so that you
can call such as "make diet", as Mauro mentioned.

BTW, Steve Rostedt told in the last night that he uses also his own
stuff for the same diet kconfig. 
Steve, can we share your script, too? 


thanks,

Takashi