From: kevin@sccsi.com (Kevin Brown) Subject: Re: Microkernel Date: 14 Mar 1993 11:12:20 GMT
In article <1993Mar10.012429.1036@colorado.edu> drew@hamlet.cs.colorado.edu (Drew Eckhardt) writes:
>In article <1nh5goINN3n0@snoopy.cis.ufl.edu> LIONESS@oak.circa.ufl.edu writes:
>>
>>I'm kind of new to the whole Linux bit, but I've noticed that it seems
>>to use a monolithic kernel architecture
>
>Yes.
>
>>where you must compile capabilities into the kernel.
>
>This is a separate issue.
Welllll....not for the *traditional* monolithic kernel. :-)
>>Has anyone thought about letting some aspects of the kernel be demand loaded,
>>like .DLLs or shared libraries.
>
>Demmand loading means that your executable isn't read into core
>when it is started. Instead, you read in pages as they become
>accessed.
>
>This presents problems in the kernel, since it assumes that
>physical addresses = virtual addresses, and this won't necessarily
>be the case.
>
>People have written code to load device drivers at run time,
>but the genereal consensus among the Linux kernel hackers seems to
>be that loadable kernel parts isn't a good idea.
>
>- If you implement the kernel part in user space as a separate
> process, you have a couple of extra expensive context
> switches.
>
>- Kernel space implementations have no problem being multi-threaded
> (ie, the file system code). In user space, things
> become a little more tricky. You have to fork off
> another process to handle each request or come
> up with some other workaround.
I always figured you could use an array of setjmp/longjmp buffers or
something, with appropriate data structures to tell you what context
gets what jump buffer.
>- There needs to be extra kernel code to add it.
>
>- People don't change their kernel configurations that often, so
> it's not too much to ask to spend a small amount of time
> to run the configure script and rebuild the kernel.
For most people, the kernel tends to remain the same over time, so they
really have no need for loadable device drivers.
On the other hand, loadable device drivers would be indispensable for the
driver hacker, provided that the driver they are hacking on isn't mandatory
for bringing up the system and that there exists a way to unload a device
driver at runtime.
This actually covers quite a bit of ground, and the same is probably also
true of filesystems.
The trick is figuring out how to get these things loaded into *kernel*
space, since (as you point out so well) running such things in user space
is a serious loss.
There exists some minimum kernel configuration which is capable of eventually
coming up in fully-functional form. You'd need:
- One filesystem type
- One disk device type
- Console and keyboard.
It's not clear that you'd even need the console and keyboard, though you'd
be totally in the dark if something went wrong before the console driver
could be loaded. The benefits of having the console and keyboard drivers
built into the kernel are, I think, great enough that making them permanent
parts of the system is warranted.
> On my 386-33 (8M of memory), it takes about 15 minutes to
> rebuild a kernel after a make clean. I can reboot
> with minor changes in the SCSI code in under a minute.
>
>>And why do different mice and what not have #ifdefs in the KERNEL?! I
>>don't understand that. And patches to use a different sound card....
>
>This lets you configure in support for only the devices you want
>when you build the kernel, making the non-pageable kernel as small as
>possible.
Aside from the extra code eaten by the dynamic loader, having filesystems
and device drivers as loadable objects guarantees that the startup kernel
is indeed as small as possible, though the same obviously isn't necessarily
true of the kernel once all the device drivers are loaded. But that depends
on whether or not there's a strong correlation between the drivers that are
loaded and the drivers that are desired. :-)
It does suggest that binary kernel distributions could be made more economical
(though it's not particularly hard to distribute a 150k file containing a
kernel that supports everything) and people would not be required to rebuild
the kernel (with all that implies, like space for the compiler and sources)
with only the features they wanted in order to get a kernel that had those
features (and only those features).
For my own personal use, of course, loadable device drivers would be a
curiosity more than anything else. Loadable filesystems are another
matter, however, inasmuch as I'm at least somewhat interested in porting
the Berkeley FFS to Linux. Ah, but I always have these high aspirations,
and reality doesn't seem to give me the time to live up to them. Sigh...
>Boycott USL/Novell for their absurd anti-BSDI lawsuit. | Drew Eckhardt
>Condemn Colorado for Amendment Two. | drew@cs.Colorado.EDU
>Use Linux, the fast, flexible, and free 386 unix |
--
Kevin Brown kevin@nuchat.sccsi.com
This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end >
This is your .signature virus on drugs: <>
Any questions?