Tool support for Kconfig

Tool support for Kconfig

[Rafael Lotufo]

Hello,

My name is Rafael Lotufo, I'm a MASc student at University of Waterloo  
in the Generative Software Lab (http://gsd.uwaterloo.ca).
Our research group is currently working on tool-supported ways of  
creating feature configurations and evolving large models
of such configurations, which we refer to as feature models.

We currently see the Linux kernel configuration options as a very rich  
real-world feature model, 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?

We would very much appreciate any input on this subject.

Thank you very much for you attention,

-- 
Rafael Lotufo
MASc Candidate
---------------------------------------------
Generative Software Lab
Department of Electrical & Computer Engineering
University of Waterloo
http://sites.google.com/site/rlotufouw

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