On Fri, 7 May 1999, Erik E. Fair wrote:

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

Okay, that is something of which I was not previously aware.
Which is, of course, why I asked the question in the first place... :-)

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

Can you say "Increased context switching"?  Can you say "Performance
hit"?  Can you say "NT"? :-)

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

Then we haven't done lkms right.  Or maybe the idea of modules loaded
at boot time a la Solaris (only better) is just too much of an un-BSD
solution, which I can respect in a way.

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

Heh.  I'd do more damage than good, I'm afraid -- a kernel wizard I ain't.

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

Maybe what we need is something which will autodetect everything
that a system has, gen a config for it in /sys/arch/$arch/conf/$HOSTNAME
[HOSTNAME=`hostname -s | tr '[:lower:]' '[:upper:]'`].  Check, of course,
for the compiler and the existence of /sys/arch/$arch/conf/GENERIC.

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


				--*greywolf;
--
NetBSD: Someday, we won't burn your toast.