Re: kernel configuration management tool
On Tue, Apr 03, 2007 at 10:27:55AM -0300, Otavio Salvador wrote:
> Sven Luther <luther@debian.org> writes:
>
> > On Tue, Apr 03, 2007 at 08:58:45AM -0300, Otavio Salvador wrote:
> >> guillaume.lopes@etu.univ-paris7.fr writes:
> >>
> >> > What do you think about this project ?
> >>
> >> What would be the main difference between your proposal and the
> >> current kernel configuration tool? Why not just improve the current
> >> tools?
> >
> > Notice that the nearest match are the kconfig.ml tool i wrote (which can do
> > nice diffs between config files and between config files and
> > arch/subarch/flavour config snipplet in the debian kernel infrastructure), or
> > the older tool Andres wrote in ruby.
> >
> > I am not sure if the actual kernel config tool stuff, as maks suggested, can
> > easily grow up to do what we need. My understanding is that it is written in
> > C, and maybe less easily experimentable as the planned ocaml tool, since ocaml
> > is a language very well adapted for parsers and graph manipulators, like what
> > would be needed here.
>
> So the idea is a tool to help the kernel infrastructure of Debian? I
> hadn't catch it from Guillaume previous description but then I like
> the idea.
Yes, the description is not so good, also apparently, i cannot be mentor
anymore, so someone else is needed, at least as frontend.
> What's the planned features for it?
The idea is to parse the Kconfig, and generate a graph, which represents all
the Kconfig dependencies (and conditions), multiplied by each
arch/subarch/flavour we have.
This would lead to a representation of all the Kconfig related info we have
both in the kernel and in debian/arch.
Then we can do various things, like building such a graph for the old and new
version, and produce a diff, like what kconfig.ml -d does for a single
arch/subarch/flavour, or diff different branches of the arch/subarch/flavour
tree.
We can also check for consistency of the debian config tree, check if there
are missed options which are auto-filled by the kernel kconfig tool, and so
on.
Furthermore, this would lead to the writing of an interactive (ncurse based ?)
tool for setting those configuration options, or maybe a pure text
oldconfig-like tool.
The next step of this process would be to parse the Makefiles, in order to
detect the modules which are build from the given config option, so we can
detect new modules or removed modules corresponding to Kconfig options which
changed. Or in general offer as information in the tool about the modules
which are affected by a config option.
Finally, if this idea is taken to the end, this mean we can even provide a way
for at least providing hint of changed modules from one kernel version to the
next, in order to make kernel-wedge / module .udebs management easier.
Friendly,
Sven Luther
Reply to: