Re: Tool support for Kconfig

Re: Tool support for Kconfig

[Giacomo A. Catenazzi]

[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,
>