> ...you can load lkms in multi-user mode if you disable securelevel.
> 
> BTW, requiring use of an lkm is broken, so let's not even start going
> down the road of using lkms to solve these problems :-)

Actually, Chris was right about the code needing a redesign for ELF;
there's no reason why requiring an LKM for non-boot-critical device
functionality would be "broken" if the kernel were capable of
demand-loading the things.

As far as this goes, if you allow kernel paging of non-paging critical
kernel code (which you would identify by ELF section coloring asserted
via #pragma), then there is little difference between paging in from a
kernel image, or paging in from an LKM image.

Personally, I'd like a minimal boot kernel that used "generic" drivers
(using the ROM code on HP's, PPCBug on Motolla PPC's, etc., and VM86()
based ROM BIOS calling drivers on x86).  Then when you probe the hardware,
you load the hardware specific drivers -- and only the hardware specific
drivers.

For instance, you might have a"dumb" console which you replace by a
better console (and throw away the section(s) which contained the
"dumb" version once it's loaded).


For the keyboard driver, you might use the ROM routines, and then
load the right keyboard driver, instead of having an HIL and a non-HIL
driver both there.

You could also reconfigure the kernel using an ELF section-archiver,
without relinking or building new objects to come up with a kernel
with specific drivers for all the hardware you do have, and none at
all for hardware you don't have.  You could even make it automatic,
with a "kitchen sink" kernel, and boot "-i" (or whatever option) for
"installation check -- discard all unused drivers and replace 'generic'
drivers with their 'non-generic' counterparts for this specific hardware".

It lends itself to all sorts of nice things...


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.