Roman Zippel recently released version 0.4 of his new configuration system for the 2.5 Linux kernel, a replacement for the aging CML currently in use. He has attempted to make the transition to this new system much simpler than was the case with CML2 [earlier story] in a hope to have it merged into the 2.5 kernel.

Curiosity got the best of me, so I downloaded the latest version as well as the 2.5.33 kernel tree, and gave it a try. I ran into a couple of compilation errors, so initiated an email exchange with Roman. Beyond helping me troubleshoot these problems, he was also kind enough to answer some general questions about his efforts with the new configuration system. Read on for the full details, then try it out yourself and provide Roman with feedback.

When attempting to compile the new configuration system on my RedHat 7.2 server, I first ran into the following errors:

    /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
    /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.
    /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14.

The problem turned out to be an incompatability between my compiler (gcc 3.2) and my binutils (v2.11). I had to use the older compiler included with my distribution (gcc 2.96) to compile the latest version of binutils. That got rid of the "Invalid or unhandled FORM value" errors, but didn't fix numerous "undefined references" when trying to link the QT libraries.

My temporary solution was to modify the Makefile, removing 'qconf' from the 'all:' section. Thus I was able to at least compile 'lkcc' (for converting to the new configuration syntax), 'conf' (feels identical to 'make config') and 'mconfig' (evidently like 'make menuconfig'), skipping for now the graphical interface. Then to install it I used the command 'make install KERNELSRC=<path/to/linux-2.5.33>'

With that done, the next step was to convert the configuration data. On my x86 box this was done by typing (from the top of the 2.5.33 kernel source tree): './lkcc i386'. A little more than a screenful of messages scrolled by, then everything was ready. To test the simple text based version of the configuration tool, I had to type './conf arch/i386/config.new' and I was off and running compiling the 2.5.33 kernel.

At some future date when I get the qconf compilation issues worked out, I'll post some screen shots. Odds are the problems are on my end, as some days I seem to have more in common with Aunt Tillie than I'd like to admit. ;)
I'd be curious to hear how other people trying this make out.

For now, read on to learn a little more about Roman's current efforts and his plans for this new configuration system.

Jeremy Andrews: Is your plan to get your new kernel confinguration tool into the 2.5 kernel?

Roman Zippel: Yes, definitely, but people seem to be careful after all the discussions about CML2. I hope I found a good compromise, which makes the switch as painless as possible. It's still a big change, but with the exception of the X interface everything works as before.

JA: Have you had any complaints about the dependancy on QT?

Roman Zippel: Not really, at least it's not as much of a problem as Python 2.x. The other interfaces continue to work and don't require g++ or QT, so people will be able to configure their kernel without QT.

JA: Will there be any other graphical modes added that are non-QT?

Roman Zippel: I'm not planning to do it myself, but it shouldn't be difficult, if anyone wants to do so and I would be glad to help. The QT front end and the parser back end are completely separated. I'm planning to make the parser back end available as shared library, so it could be loaded by external applications dynamically. This way all the config tools don't have to be maintained with the kernel.

JA: Have you re-used any code from CML2?

Roman Zippel: No. I started with the converter, which converts the old configuration files into the new format. Eric claimed that the current config information is too buggy, and I tried to find out how much could be salvaged. The converter can't handle everything, so I need to fix some things manually, but the majority of config files can be converted. This has the nice side effect that I don't have to maintain my own rule base like Eric had to do.

I ended up with a much simpler config format than used by CML2. It's maybe not as powerful as CML2, but it makes everything a lot simpler. On the other hand the new format is flexible enough to add new information to it as needed.

JA: What are your main goals with this new configuration tool?

Roman Zippel: The short term goals are to unify the three different parsers, which produce slightly different results and to replace the old inflexible configuration format. Later it will be possible to integrate the config system better into the build system. For example it will be possible to add the build information, so all relevant driver information is at a single place and not scattered over multiple files. This will also allow it to more easily configure and build external drivers, which are not integrated into the kernel yet.

JA: How long before you've got something you feel is ready to be merged into 2.5?

Roman Zippel: I think it's already quite usable. Most of the work is already done, now I'm busy with finding bugs and fine tuning. There are only some small features I still want to add. The documentation needs updating too, but I tried to keep everything as simple as possible, so one can work without it. Mostly I need feedback now, so this is very welcome. :-)

From: Roman Zippel
To: linux-kernel
Subject: linux kernel conf 0.4
Date: 	Thu, 05 Sep 2002 02:11:43 +0200

Hi,

At http://www.xs4all.nl/~zippel/lc/lkc-0.4.tar.gz you can find the
latest version of my config system. It slowly is becoming completely
usable, so it's time for a new release.
A lot has changed since the last official release, so here only some
highlights:
- correct dependencies for the config files are now generated, "make
oldconfig" isn't needed anymore in many cases (you should try it before
making any comments about it).
- config rulebase is with some small (known) exceptions the same in the
old and new syntax, even comments are now preserved.
- menuconfig is working again. Except of xconfig the user interface is
almost as before, anything you could do before, you still can do.
- it's much faster in the common case.
- clean separation between frontends and backend.

Installation is very simple with "make install KERNELSRC=", where
KERNELSRC points to a 2.5.33 kernel tree. "make uninstall
KERNELSRC=" will deinstall everything.
I think the new system is ready for wider testing, so any feedback is
very much appreciated. Most important is probably the new syntax, until
it it's integrated I can easily change the converter to generate
whatever syntax. I still have to update the documentation, but the
syntax should be easily understandable even without it. For the lazy
guys out there, here is an (already advanced) example:
choice
  prompt "Adaptec AIC7xxx support"
  optional
  depends SCSI

config SCSI_AIC7XXX
  tristate "New driver"
  help
  ...

config AIC7XXX_CMDS_PER_DEVICE
  int "Maximum number of TCQ commands per device"
  depends SCSI_AIC7XXX
  default "253"
  help
  ...

config AIC7XXX_RESET_DELAY_MS
  int "Initial bus reset delay in milli-seconds"
  depends SCSI_AIC7XXX
  default "15000"
  help
  ...

config AIC7XXX_BUILD_FIRMWARE
  boolean "Build Adapter Firmware with Kernel Build"
  depends SCSI_AIC7XXX

config SCSI_AIC7XXX_OLD
  tristate "Old driver"
  help
  ...

config AIC7XXX_OLD_TCQ_ON_BY_DEFAULT
  boolean "Enable Tagged Command Queueing (TCQ) by default"
  depends SCSI_AIC7XXX_OLD
  help
  ...

config AIC7XXX_OLD_CMDS_PER_DEVICE
  int "Maximum number of TCQ commands per device"
  depends SCSI_AIC7XXX_OLD
  default "8"
  help
  ...

config AIC7XXX_OLD_PROC_STATS
  boolean "Collect statistics to report in /proc"
  depends SCSI_AIC7XXX_OLD
  help
  ...

endchoice
This new syntax basically fixes the recursive dependencies in the old

syntax:
if [ "$CONFIG_SCSI_AIC7XXX_OLD" != "y" ]; then
   dep_tristate 'Adaptec AIC7xxx support' CONFIG_SCSI_AIC7XXX
$CONFIG_SCSI
   if [ "$CONFIG_SCSI_AIC7XXX" != "n" ]; then
      ...
   fi
fi
if [ "$CONFIG_SCSI_AIC7XXX" != "y" ]; then
   dep_tristate 'Old Adaptec AIC7xxx support' CONFIG_SCSI_AIC7XXX_OLD
$CONFIG_SCSI
   if [ "$CONFIG_SCSI_AIC7XXX_OLD" != "n" ]; then
      ...
   fi
fi
The most important thing here is that you now always see that there is a

choice between two drivers. For example in menuconfig you had to know

that you have to disable one option to see the other option or if you

have an old .config, which doesn't contain CONFIG_SCSI_AIC7XXX_OLD, but

has CONFIG_SCSI_AIC7XXX set to 'y', "make oldconfig" won't tell you

about the new option.
Anyway, back to the new syntax. One thing I'm not yet completely sure

about is indention, as it might help to make above more easily readable.

The parser automatically recognizes the suboptions (by analyzing the

dependencies) and the frontends present them accordingly (how exactly

you should try yourself :) ). The problem here are the help texts, they

should be easily editable, but on the other hand the parser has to find

where it ends (and possibly reformat it a bit). Right now the help text

simply ends at the first line that doesn't start with a white-space. So

I'm toying with various ideas to make the suboption more easily

recognizable, e.g. they could also be put within an "if FOO" ... "endif"

block.
Something else above example demonstrates is the default value, first,

bool and tristate symbols can have default values as well and second,

something like this is possible:
config FOO
  bool 'bar' if BAR
  default y
The default value has two meanings here, first it's used as default

value for the prompt and if the prompt isn't visible, FOO is set to it.

This is quite useful for some of the advanced config options.
That's it for now, so have fun and complain _now_, not when it's too

late. :)
bye, Roman

• Google archive of above thread
• screenshots
• lc home
• Slashdot discussion of Roman's new configuration system.
• LinuxToday discussion of Roman's new configuration system.