Messages in this thread | ![/](/images/icornerl.gif) | | Subject | ideas | From | (james diekens) | Date | Fri, 03 May 96 10:56:33 PDT |
| |
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 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
| ![\](/images/icornerr.gif) |