lkml.org 
[lkml]   [2008]   [Sep]   [18]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 18 Sep 2008 12:27:29 -0400 (EDT)
FromMauro Carvalho Chehab <>
SubjectRe: diet-kconfig: a script to trim unneeded kconfigs
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


\
 
 \ /
  Last update: 2008-09-18 18:31    [from the cache]
©2003-2008