Subject: Re: architecture specific kernels for sun4, sun4c, sun4m
To: Gandhi woulda smacked you <greywolf@starwolf.com>
From: Erik E. Fair <fair@clock.org>
List: port-sparc
Date: 05/07/1999 01:36:57
Personally, I *detest* LKM's. They are at least as dangerous and
destabilizing as INITs in MacOS and TSR modules in DOS. I doubt that we can
ever sufficiently specify an API for LKMs that would be safe enough, or
stable enough. Below the system call interface, we rototill the kernel code
with wild abandon, which is why I believe it has to remain an integrated
unit, uniformly compiled, not a "modular" system.

The only other viable course is to go to the opposite extreme, and do
everything up like MACH OS servers were supposed to be done with explicit
protocols and primitives between the modules, with no peeking or poking
outside the lines drawn by those protocols. Fiddling in the middle of that
range between the monolithic kernel and the microkernel world as we do
simply leaves the LKMs to break each time when we change their execution
environment out from under them (i.e. bit rot).

However, if you want to work on LKMs, don't let my opinion stop you. You
may yet prove me wrong.

However, LKMs are an orthogonal issue because they won't solve the problem
I'm asking after: architecture specific kernels that eliminate the need for
indirection through function pointers in critical (i.e. very often used)
code paths in the kernel, and thereby perform better than GENERIC. We have
a model of use which presumes that GENERIC is to get you bootstrapped and
the system installed, and then you compile up a kernel that more closely
matches your needs.

What this really comes down to is: do typical users
configure/compile/install an arch-specific kernel after install, or do they
just run GENERIC in production? If the former, then my suggestion is
useless. If the latter, then I think it would be helpful if we could give
the users a step-up in the right direction.

This is the point at which we should collect data to answer the question.

	Erik <fair@clock.org>