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>