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

["Chris Li" <lkml@chrisli.org>]

On Tue, Sep 23, 2008 at 4:31 AM, Takashi Iwai <tiwai@suse.de> wrote:
> That is true.  Enabling arbitrary kernel config item is hard to
> achieve right now.  I think this feature should be implemented in
> kbuild parser itself.  The current reverse-select is way limited and
> known to be problematic in many kernel configs.

I was looking at the kbuild system. BTW, I really like the Makefile
in kbuild.  For the reverse select, here is what I have in mind.

The reverse select needs to maintain the define-user chain for
each kernel option. And each kernel option has a list of the kernel
option and value pare to enable an option. Once we produce such
an list for "all config". We can know exactly what kernel option
needs to set in order to get to so module. It is kind of doing
the data flow analyze on the config options.

It is not trivial, but it shouldn't be too hard either.

> Anyway, I think the white list isn't that hard for certain use-cases.
> My assumption is that users base on the distro kernel that have
> already all modules.  Then, for likely scenarios such as USB-storage
> hotplug, we can simply provide possible modules such as usb-storage
> and nls_* as the additional modules.  The script would just need to
> add them to the existing module list.  If necessary, the module
> dependency can be solved easily from modules.dep, too.

If you just want a white list without resolving the dependency, that
should be very easy to do in my current minmod.py.

In terms of implement in C. The currently kconf symbol has most
of the bits ready already. We can add a symbol type "module".
It points to a list of config symbols. That should be good enough.
Then we can use 1 bit of flag in config symbol to mark it is blacklisted
or not.

We can use some thing like minmod.py to provide a prototype
for some kernel user to try it out. If it covers most of the feature
the we want. We can go ahead to the C version.

> But not about this case.  It wants to be compiled-in, too.

I think my script can catch those already. Maybe I will beat it
up to generate a list of similar configs using "obj-m" directly.
We can example them one by one.

Chris