C would be great, maybe C++ or Objective-C.
>> Help is stored in a separate file. Each define gets a paragraph.
>> The DOS 5 help file format is simple to use
> Um, shouldn't we use something flexible that meets our needs rather
> than somebody else's?
I despise DOS at least as much as the average linux-kernel reader but
I don't hesitate to steal a good idea. The format is _really_ easy to
write and parse: Each item gets one line and is followed by indented
help text. An unindented line starts a new topic.
>> This needs to be done in 1.3.x really soon.
>
> Maybe. I'm not convinced the configuration is that badly broken.
> Proper documentation of the sources is more important, in my opinion. ;-)
You must never need to change just _one_ option and be forced to go through
the whole config script. (Anyone who mentions a text editor here admits
that the current system is broken!) This must be done soon so that it
will work well when 1.4.0 is released.
> 2. To my feeling there are far too little comments about what all the
> settings are about. Sometimes even I run into trouble, 'cause I
> didn't know what's meant. And what will a newbie think?
"I need it all!"
> So I would very much appreciate a file describing every setting you
> can make in the configure script. In this file I would like to have
> a description that even a newbie understands and at some places a
> more technical view, with pointers to the source where some things
> can also get tuned.
>
> Maybe the Configure script can also be extended to support a help
> function which displays a little (10 lines or so) description about
> the current define.
>
> 3. There are many kernel settings which are not carried with the
> configure script. I would appriciate introducing another script (or
> perhaps a complex program so you don't have to recompile the
> kernel) to adjust the kernel. I mean, set max number of processes
> (at all and per user), set number of ttys, set kernel output (to a
> serial line?) and such things. Just finetuning the kernel.
>| All the adjustable defines are kept in a database. Each define is
>| classified with cross-references, dependencies, and options. This
>
> Hmm, that may be quite good to track down the time needed for
> compiling the kernel. But the problem that I see is that Linus has to
> keep this database (at least the dependencies section) up to date,
> which will be a stupid job. But nevertheless I think this would be a
> good idea.
We can send patches. Anyone who adds a file to the kernel will notice
that it is quite useless with out a database entry.
>| is so that different config programs can have different menu systems,
>| yet be (mostly) independent of the kernel version.
>
> What do you mean?
It should be possible to write an html form, X program, curses program,
or CLI based perl script that can configure most kernels. Although it
would be nice to distribute some sort of config program with the kernel
source, the important part is the database. As long as the database
format doesn't change it should be usable by any kernel config program.
I could have a config program to suit my personal preference, and it
would seldom be broken by new kernel releases.
> a) A document describing all the different switches, their
> advantages and disadvantages, their dependencies and
> side-effects.
Start here: is it true that limiting memory to 16MB (on systems with
4 to 16MB) will make the system faster by eliminating a check for
double buffering?