The Mach LPC call by name slow down can be partially fixed by doing what
Apple did in ASLM (and probably everyone else does, but I'm not a ld.so
expert and wouldn't know better :-). You do the named lookups once and stuff
them into the equivalent of a C++ vtable. From then on, named calls are as
fast as dynamically linked calls.

From what I read and plus my own experiences, it's not likely anyone is
desirous of turning the NetBSD monolithic kernel into a microkernel anytime
soon, so there's no risk of slowdowns due to different userland kernel bits.

As long as I can have lkmfoo-1.o and lmkfoo-2.o loaded and working side by
side, I don't think there's going to be compatibility issues. Some times
it's handy to have this:

* imagine a new file system, reiserfs-3.5 and reiserfs-3.6. The file formats
are incompatible (3.6 upgrades them if you so desire), but is a little bit
buggy on the 3.6 implementation of the 3.5 downlevel code due to bugs in 3.5
that are fixed in 3.6. This is a good enough reason to run both side by
side. Another reason would be two tulip look alike cards. If there are two
drivers that do sort of the same job, it'd be nice to have them both loaded.

I'd like to have a fully LKMable kernel. I'm used to it in WinNT/Win2K, and
it's nice. When I was working on reiserfs on my Alpha I spent part of my
time making it work even on i386 as a module as fs development cycles can be
painful if you have to reboot every time you need to try yet another debug
cycle. Particularly with the lack of integrated kernel debugging available
in Linux.

From a user's perspective, LKMs are a win as well. No more reboots and
insertions of new and interesting devices such as cameras or funky force
feedback joysticks shouldn't cause a newbie to create their own custom
kernel image.

As long as there is a way to build a static kernel && || make it load only
certain modules, this security dude will be happy.

thanks,

Andrew van der Stock, ajv@greebo.net http://www.greebo.net
SAGE-AU President	                   http://www.sage-au.org.au

-----Original Message-----
From: tech-kern-owner@netbsd.org [mailto:tech-kern-owner@netbsd.org]On
Behalf Of Erik E. Fair
Sent: Monday, 27 November 2000 12:46 PM
To: NetBSD Kernel Jiggery Pokery Discussion
Subject: Re: LKMs


LKMs remind me too much of INITs from the MacOS world (or TSRs from
the Windows world), with all attendant unhappiness. Compounding that
is that we don't have nearly the stable or documented APIs inside the
kernel that those two commercial systems have. To make this work,
we'd need to mark the kernel with something akin to a shared library
version number, and make sure never to load any LKM that didn't
exactly match the version number, to ensure no API mismatch.

In the long run, this evolution leads to MACH 3.0 microkernel land,
with little memory protected modules adding to a global symbol table
with services they offer, and RPC or IPC to glue it all together.
That system has considerable conceptual appeal, but the practical
realities have not turned out as nice as the concept.

If you really want to go down that road, OK, but I'll be with kre,
commenting out "options LKM" for my kernels.

	Erik <fair@clock.org>