by ================== T U N A F I S H P R O P O S A L =====================
0. Introduction
The start for this proposal was given by an article in c.o.l.d by the hand
of Jeff Uphoff in reaction to somebody remarking that the number of locks
in Linux was not a limit but a configurable parameter. He stated that he
was pondering a mechanism to somehow extract, document and change these
'tuneable parameters' using Perl scripts.
There were a couple of other threads with similar content, so Jeff (and
others obviously) realized that the time was here for this sort of
thing - especially since Linux is becoming a multiple-architecture OS -
so configuration-tailoring is going to turn into a real issue. Who ever
thought that would happen? As an aside, a quick excerpt from Linus' early
e-mail and posts on Linux in August 1991, which somebody has archived:
LT> I'm doing a (free) operating system (just a hobby, won't be
LT> big and professional like gnu) for 386(486) AT clones.
[...]
LT> PS. Yes - it's free of any minix code, and it has a multi-
LT> threaded fs. It is NOT portable (uses 386 task switching etc),
LT> and it probably never will support anything other than AT-
LT> harddisks, as that's all I have :-(.
Kind of funny, looking back now.
As far as tuneable parameters are concerned, besides the above mentioned
number of locks, the Linux kernel has several more of those, sometimes well
hidden, parameters with which you may influence the inner workings and
possibly the performance of a Linux system. However, given the state of
Linux, the kernel is still a moving target sourcewise, making it difficult
to accurately pinpoint the location of these parameters. Furthermore, there
are several tables that represent hardware in a machine, for example
rs_table[] in .../drivers/char/serial.c
1. Basic ideas until now
Up to this moment, Jeff and I have been toying with some ideas. They all
share the idea that it somehow must be possible to retreive and use the
name of the parameter, its default value, a list of alternate values and
an explanation of how the parameters value interacts with system persona,
performance and possibly other parameters. Besides that, the general idea
is that it is possible that a few people start documenting these parame-
ters, possibly using an e-mail address to send their documentation to,
but in the end it is best that the developer or maintainer of the
(kernel)code provides the necessary information.
- Somehow extract the tuneable parameters from the sources and storing
them in a list, using a script to supply alternate values.
- Using headers with a particular suffix (for example *.tune.h) for
storing tuneable parameters.
- A #define scheme to be able to locate the parameters and related info.
2. What we want from you
We want to accomplish is a flexible way of dealing with the problem at
hand, but in such a fashion that the majority of (kernel)code developers
is willing to adopt the scheme. Therefore, we would like you to:
- Provide different and/or better ideas
- Commentary on the ideas as sketched in 1.
- Flames, insights, encouragement, <fill_in_the_blank>, ...
3. Where we are
==========================================================================
--
PLEASE remember Keywords: and a short description of the software.