From: kevin@sccsi.com (Kevin Brown) Subject: Re: Microkernel Date: Sun, 14 Mar 1993 11:30:20 GMT
In article <1nr20gINNrod@snoopy.cis.ufl.edu> LIONESS@oak.circa.ufl.edu writes:
>In article <Efc_wBa00VB3M_Rekh@andrew.cmu.edu>, "Brian E. Gallew" <geek+@CMU.EDU> writes:
>|>I'll be blunt. If you want a microkernel, get Mach. (ftp cs.cmu.edu)
>|>Linux really isn't set up for mircokernel-style stuff. As I recall,
>|>this discussion came up back in the 0.12 days (or shortly thereafter)
>|>and it was pretty much shown then that if you want a microkernel, get mach.
>|>
>|> -Brian
>|>
>|>-------------------------------------------------------------------------
>|>| "Are they dead?" |
>|>| "Does it matter?" |
>|>| - Pugsley and Wednesday in "The Addams Family." |
>|>-------------------------------------------------------------------------
>
>I believe that that argument isn't the best. I understand that Linux in and
>of itself is a rather large achievement, I'm simply wondering why some have
>not decided to take it a step further -- making it more distributed and
>possibly more like Mach.
There are undoubtedly other avenues of interest that would probably yield
greater benefits than pursuing microkernel-ness in Linux.
>Honestly, I can't afford Mach, but it would be nice to have some "mach-like"
>features built into it, like running subsystems in user space. Someone replied
>that this would give a performance hit, but I don't see how, other than deman
>loading a library ( the load time and fixup time ). Making large portions
>of the operating system running outside of the kernel is generally considered
>a "good thing" since it enhances modularity. Hell, I thought Minix did this
>with the file system, althought I can't be sure.
Minix *does* do this with the filesystem, and it has to go to some lengths
to do things like tty I/O that can block for indefinite periods of time.
The Minix filesystem is single-threaded, which yields a significant
performance hit under multiuser conditions (admittedly, a condition which,
while not entirely outside of Minix's domain, is not one of the primary
design considerations for Minix).
Quite a lot of interesting communications has to go on between the filesystem,
the memory manager, and the Minix kernel for some of the POSIX/Un*x semantics
to be implemented. Consider the case where a process dies...*everyone* has
to be notified about it in one way or another. Consider the case when the
process has to dump core...now the memory manager has to cause a file to be
written that contains the contents of the process' memory image.
Stuff like that is positively *easy* in a monolithic kernel design, provided
you've taken care of the race conditions that can occur. It's harder in a
microkernel architecture like Minix, but these problems, I think, stem more
from the way the problem of building an operating system is factored than
from whether or not the implementation makes use of a microkernel architecture.
I think the system call server approach of Mach works much better than the
modular design approach of Minix when it comes to implementing the semantics
of Un*x. No doubt this is because Un*x was designed originally *as* a
monolithic kernel, and its behavioral semantics reflect this to a degree.
>If you look at where most new operating systems are heading, such as NT,
>NextStep, new versions of OS/2 and AIX, etc. they are using very Mach like
>kernels. Rick Rashid is working for Microsoft now as a matter of fact. :-)
The architecture you use to build your kernel should be based on the
properties you want your kernel to have, not on whether or not everyone
else happens to be tackling the problem a certain way.
>Granted, if I wanted Mach I should get Mach, but I want cheap more than I want
>microkernel, so take this simply as a suggestion of a useful feature that if
>added would probably make updating the whole operating a lot easier.
Certainly it would help to some degree, but one must always ask at what
cost such a capability would come. The answer to that is not clear to me,
but I strongly suspect there are other avenues that would be much more
profitable than the avenue of building in loadable device driver/filesystem
capabilities.
>Brian
--
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?