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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 18 Sep 2008 12:27:29 -0400 (EDT)
From:	Mauro Carvalho Chehab <mchehab@...radead.org>
To:	"Giacomo A. Catenazzi" <cate@...eee.net>
cc:	Takashi Iwai <tiwai@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: 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@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/