(this discussion should probably be on tech-kern, and perhaps the data
collection portion should be CC'ed to *all* of the port-* lists, but I
didn't try to make those moves!  ;-)

[ On Friday, May 7, 1999 at 01:36:57 (-0700), Erik E. Fair wrote: ]
> Subject: Re: architecture specific kernels for sun4, sun4c, sun4m
>
> 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).

That was extremely well put and not only deserves qoting, but re-reading
as well!

As far as I can see the only way to make LKMs safe enough for production
use would be to write the kernel in a language that can make such
guarantees and indeed I read something recently about grafting LKM
interfaces defined in Modula-3 onto an existing Unix-like kernel, that
was written in C, with this very purpose as one of the goals.  I've also
observed some resistance to this concept, and even misunderstanding of
it, including in myself, usually from people who's experience is deeply
rooted in lower level languages, such as C, or even assembler.

> 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.

Indeed, though I've not yet understood the full impact of supporting CPU
variants in the same kernel, especially across the various architectures.

I.e. it would seem as though supporting the entire iX86 line in a single
kernel is still a relativley low-cost feature (at least that's what I've
been lead to believe), but you're implying that this isn't the case for
some of the SPARC CPUs (and indeed Sun's own decision not to merge
sun4[c] and sun4m support could tend to indicate this is true).

>    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.

Yes, that's how I've always understood the purpose of a "GENERIC"
configuration, i.e. that it goes far beyond having "generic" CPU support
and includes support for the most common hardware adapters too.

> 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.

I always compile and use very specifically configured kernels on all
architectures, at least for production systems.  I.e. if I have a 486
processor I'll compile my production kernel only with 486 support, and
since all my sparc machines are sun4c, I enable only SUN4C for their
kernels.  If I want to swap the disk around I'll reboot with the generic
kernel, which I generally keep in the root directory of every system,
and then I'll re-build a new and specific kernel before I put the "new"
system back in production.

The only time I run into problems is where I've had to build a custom
kernel in order to even boot the system into a useful mode (eg. I've got
an uncommon ethernet adapter, or on PCs where I've had to fiddle with
IRQs and IO ports to get everything to work together).  In these cases
of course I need a "support" system to even bootstrap such machines, so
even a GENERIC kernel is mostly useless once the "support" system(s) are
themselves self supporting.

Now since I do some of my own kernel and systems development I am also
able to generate different assumptions about what's "generic" in the
groups of systems I support, and as a result the "GENERIC" configs in my
source tree are often somewhat different than those distributed with the
original source code.  Sometimes this allows me to avoid the "problems"
I describe above, but only so long as I continue to maintain those
machines using my own source tree.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>