lkml.org 
[lkml]   [2002]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectalternative linux configurator prototype
Hi,

At http://www.xs4all.nl/~zippel/lc.tar.gz you can find a prototype for a
new linux configurator (see the included README for build/use
information). It has reached a point, where it's becoming usable and I
need some feedback on how/if to continue.

In the first place I wanted to address the problems which came up in
discussion about cml2. So how does it compare to cml2?
1. It's written in C (except the X interface that is in C++ because it
uses qt), so it's really fast.
2. As I convert the current cml1 configuration, it represents pretty
much the same information (and I don't have to maintain lots of new
rules).
3. It's less complex, but IMO sufficient for basic kernel configuration
and all information for a single configuration symbol is at a single
place.

The last point is the most important one and needs some more
explanation, I could have lived with the other problems, but this this
one motivated me to write this tool. I think Eric tries to solve too
many problems at once and this also caused the opposition in previous
discussions. There are basically two problems:
1. Which information is required to compile a driver into the kernel?
2. Which information is needed from/by the user to compile a kernel?
I only try to solve the first problem, Eric also tries to solve the
second problem, but the mistake he made here is to mix up these two
problems. Autoconfiguration is an important problem, but it must be kept
optional, whereas the first problem must be solved, otherwise the kernel
won't even compile. Keeping the problems separate simplifies also the
needed solutions.

Anyway, everyone can now check himself, which solution he prefers. What
I need to know now is, if and how we join both efforts. It's possible
everyone prefers now Eric's cml2 and thinks that my approach is too
simple.

BTW my configurator has a nice new feature: tristate choices. It solves
some problems IMO more elegant than cml1 or cml2. Save the following as
config.new and try yourself. :)

config MODULES
boolean "module support"

config SYS
tristate "SYS"
help
some subsystem

choice
prompt "ABC"
default A
depends SYS
#try also to disable this
optional
help
abc

config A
tristate "A"
help
a

config A1
boolean "A1"
depends A
help
a1

config B
tristate "B"
help
b

config B1
boolean "B1"
depends B
help
b1

config C
boolean "C"
help
c

config C1
boolean "C1"
depends C
help
c1

endchoice

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.074 / U:2.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site