[lkml]   [1996]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
sorry about the formatting but my mail is through a bbs, and the upload 
feature is broken and had to upload via ascii and it got screwed up

Warning the following may be considered blasphemous to kernel programmers
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
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
kernels as soon as it is released, So any improvement in speed, adds to
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.
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
While the gawk wizards will complain that sanity checks can be done in
but at a cost of speed. There are also more C wizards in linux land than
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
each patch level. I have seen many developers code broken by interface
these are the main reason that the majority of the drivers get changed
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
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
what is broken or needs further enhancement. Just think about it.
it be nice when someone writes "2.0.8 broke ppp", you could just say,
UN-patch the network code to 2.0.7, knowing that the network code to
networking code will work with latest version because we have an
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
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
to see that at least all the patch levels are in sync, and contain the

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
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
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
stuff, just the parts that can make life easier for the developer, and
the kernel run faster and more stable. Use default arguments, to
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
to be changed, and everyone is happier, No speed lost, the compiler did
the work. And for the real radical changes like different variable types
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
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
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.


-- (james diekens)
The Tech BBS +1 408 279 7199 San Jose, CA

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