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

Mauro Carvalho Chehab
2008-09-18T16:27:44Z

On Thu, 18 Sep 2008, Giacomo A. Catenazzi wrote:

> Mauro Carvalho Chehab wrote:
>> Hi Takashi,
>>
>> On Wed, 17 Sep 2008 01:55:26 +0200
>> Takashi Iwai <tiwai@suse.de> wrote:
>
>>> The script is VERY hackish. I should have begun with perl or whatever
>>> better script language, but I chose bash and co. So, don't expect
>>> much code quality. I'm no script guy after all :)
>>
>> Using just a shellscript and binutils seems to be better than using other
>> tools, since it allows the usage on minimal configured systems where the
>> user
>> might not have perl or other scripting languages.
>
> But very slow,

I don't think that performance is a big issue here. I tested Takashi
scripts on this old 1.5 GHz centrino one core notebook, and it runned in a
few seconds. Kernel compilation with diet config took 30-40 mins. The
additional time for the script didn't significantly increased the total
time.

> complex and not enough powerful:

For sure a scripting language like perl is more appropriate.

> The tools should have extensive knowledge about Kconfig,
> and the CONFIG_ dependencies

Since CONFIG_ and their dependencies are constantly
changing/adding/removing at kernel, the better would be to have a good
Kconfig parsing, avoiding to have lots of "local knowledge" about symbols.
The better model seems to be the one where subsystem maintainers don't
need to take extra care for not breaking the tool when touching at
Kconfig/Makefiles.

Also, it occured me that some drivers have "implicit" Kconfig dependencies
inside that may limit its work. Looking on a random driver, just as an
example, you have things like:

$ grep ifdef cpufreq_stats.c
cpufreq_stats.c:#ifdef CONFIG_CPU_FREQ_STAT_DETAILS
cpufreq_stats.c:#ifdef CONFIG_CPU_FREQ_STAT_DETAILS
cpufreq_stats.c:#ifdef CONFIG_CPU_FREQ_STAT_DETAILS
cpufreq_stats.c:#ifdef CONFIG_CPU_FREQ_STAT_DETAILS
cpufreq_stats.c:#ifdef CONFIG_CPU_FREQ_STAT_DETAILS
cpufreq_stats.c:#ifdef CONFIG_CPU_FREQ_STAT_DETAILS

So, I suspect that the script might also need to parse the selected files
to seek for additional rules.

I'm not sure what to do after discovering such things: Assume the option
that generates smaller code? Assume the option that generates the most
complete code? Maybe the better would be to use the selected config
profile as a hint for such symbols. If not found there, then ask user.

> it should handle a lot of
> structures (text/binary; line/record oriented; etc.), which
> it is not easy in shell (awk, od, sed with extended regexp are
> not core utilities).

True.

> So my suggestion is: do it in a high level language, to find and
> stabilize the design, and then integrate it in kconfig later (using
> C).

Seems a good approach to me.

--
Cheers,
Mauro