linux-kernel - Re: Tool support for Kconfig

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 for Android: free password hash cracker in your pocket

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

Message-ID: <49F0602C.1060605@cateee.net>
Date:	Thu, 23 Apr 2009 14:33:48 +0200
From:	"Giacomo A. Catenazzi" <cate@...eee.net>
To:	Rafael Lotufo <rlotufo@...n.uwaterloo.ca>
CC:	linux-kernel@...r.kernel.org, Kbuild <linux-kbuild@...r.kernel.org>
Subject: Re: Tool support for Kconfig

[CC also to kbuild list]

Rafael Lotufo wrote:
> We currently see the Linux kernel configuration options as a very rich 
> real-world feature model,

But also broken and it lack a lot of useful features.

> and it has been our subject
> of investigation since last January. Our current efforts have been to 
> create a reasoning tool for the Kconfig options, something that
> could help in finding recursive dependencies, configuration options that 
> cannot be selected, and even tools that would facilitate
> configuring the Linux kernel, like resolving dependencies for a wanted 
> configuration option that cannot be currently selected
> due to its dependencies. Furthermore, the reasoning tool can compute 
> semantic diffs, intersections, unions, and slices of Kconfig
> specifications.
> 
> We would be interested to receive input from interested Linux kernel 
> developers regarding their experience
> with modifying Kconfig files. Would a tool for analyzing and comparing 
> Kconfig files be useful?
> What questions one typically has to answer when evolving Kconfig files? 
> Are there any frequent problems
> or mistakes?

the Kconfig has a big real problem: linear order of dependencies,
i.e. dependencies should be defined before use point.  This is not
a requirement of language, but with current interfaces would be very
impractical to find new options in past branches. But on the other hand,
in some cases is very annoying. (Lately I configured a new machine, starting
from distribution config. In this case I needed to go from bottom to
top of tree, in order to remove almost every (unneded) feature.

So a check that warn about such cases would be nice. This would resolve
also the recursion problem.
But also a better way to handle dependencies (in user interface)
would be nice, like our package managers:
- removing a CONFIG (showing all dependencies before confirmation)
   [which is not yet possible]
- adding a know CONFIG, which could be hidden.
   Actually we can ask for dependencies with search '/' command, but
   also allowing to select the dependencies (like in our package manager)
   would be nice.

Note: such features could make "SELECT" obsolete.

Know problems?
I don't know. Usually new driver use copy paste, so without
big problems. The syntax is pretty simple.

There was some confusion about dependency handling (logical
operators with ternary values n/m/y)

SELECT is sometime used incorrectly (style/design, not in
semantic layer)

config menu can be defined several time. This is a nice feature,
but also a source of possible problems. I think normally it is
OK on same file and on incompatible area (e.g. on different
architectures). I think all other cases should be errors.

Hidden (always invalid dependencies) CONFIG item are interesting.

ciao
	cate

> 
> We would very much appreciate any input on this subject.
> 
> Thank you very much for you attention,
> 

--
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/