On Tue, Apr 03, 2007 at 10:27:55AM -0300, Otavio Salvador wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > On Tue, Apr 03, 2007 at 08:58:45AM -0300, Otavio Salvador wrote: > >> [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
