Messages in this thread | | | Date | Tue, 23 Sep 2008 11:15:19 -0700 | From | "Chris Li" <> | Subject | Re: diet-kconfig: a script to trim unneeded kconfigs |
| |
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
| |