Warning the following may be considered blasphemous to kernel programmers
but
i only air them in public, in hope that they can improve linux.
1. Change make dep script into a C program
Well linux has been around long enough, isn't it time to convert gawk
script
to C code, their are several reasons for this.
Speed, while the people with state of the art machines complain this is
not necessary, but these same people are the ones who upgrade to the
latest
kernels as soon as it is released, So any improvement in speed, adds to
the
uptime of each version of the kernel. As we are currently getting a new
version of the kernel every other day or so. The savings can add up to
several extra hours of uptime per month, even on the fastest machines.
The
more uptime on each version, the more bugs caught, etc.
With the increase speed, we could also implement kernel specific, checks,
i.e. We could make sure that each module, cleans up after it self when it
unloads, I am sure other kernel wizards, can think of other sanity
checks.
While the gawk wizards will complain that sanity checks can be done in
gawk,
but at a cost of speed. There are also more C wizards in linux land than
GAWK
wizards. More people working on something, the faster it gets done, or
the better it is, at least this is true of linux.
Interface lock for each version.
Now that linux is almost completely modular, how about an interface lock
for
each patch level. I have seen many developers code broken by interface
changes,
these are the main reason that the majority of the drivers get changed
these
days. The interface, would include all global function calls, global
variables, and initialization procedures.
This interface lock becomes even more important as linux becomes larger
and
will most likely be divided into smaller pieces. if we modularized people
could keep the pieces of kernel that are working for them and only
upgrade
what is broken or needs further enhancement. Just think about it.
Wouldn't
it be nice when someone writes "2.0.8 broke ppp", you could just say,
okay
UN-patch the network code to 2.0.7, knowing that the network code to
2.0.7
networking code will work with latest version because we have an
interface
lock, all the other developers are happy, because all the other patches
remain and are actively being tested. Also no one has to fix XT driver or
all the network cards, be cause of an interface change. This interface
lock
also leads to the day when whole parts of linux will be unchanged from
patch-level to patch-level.
To cut down on problems, with mix-n-match kernels, each sub-part of the
kernel source would have its own version codes, so the compiler could
check
to see that at least all the patch levels are in sync, and contain the
same
interface.
To better implement this scheme it would be nice to make the include
directory more modular like include/drivers, include/net, include/fs thus
each sub directory could have a version file with the proper version
info.
Basicly I think the kernel should be broken into one main part and 4 sub
parts. Each sub part, would contain all include files that are needed to
compile, except for the CORE include files.
+------- arch
/
+---------- drivers
/
CORE -----+------------ net
\
+ ---------- fs
CORE would contain : kernel, lib, mm, scripts, init, include
With a patch script even the newbies who just wanted a new toy could
manage
the UN-patching process.
3. Use the features in C++ that will allow a more stable kernel
Okay here is where i am going to get the developers mad at me. How about
converting parts of linux to use C++, no not classes or the object
oriented
stuff, just the parts that can make life easier for the developer, and
make
the kernel run faster and more stable. Use default arguments, to
implement
interface changes, for example when we add another variable to a inturupt
setup call, how about provide a default value so all the drivers don't
have
to be changed, and everyone is happier, No speed lost, the compiler did
all
the work. And for the real radical changes like different variable types
or
changes in the order of arguments we could use function overloading. All
calls that are not overloaded would be defined using C type so that
name mangling would not show up in most oops reports.
Also we could use C++ streams type functions to implement printk calls. I
wonder how many drivers have been broken by stack corruption, by
incorrect
params in printk calls. Variable argument function calls are inherently
slower then fixed argument calls.
A less radical method is that we could implement several overloaded
printk
functions that would contain the most common printk commands. If this is
done then a lot of the work being done inline in the kernel could be
processed by the compiler.
jamesd
-- mack@wile.thetech.org (james diekens) The Tech BBS +1 408 279 7199 San Jose, CA