Phil Payne Wrote:
> > > The story goes that Andrew Tannenbaum (Comp Sci professor and
> > > creator of MINIX, which few can dispute was an inspiration for Linux)
> > > criticized Linux as "out of date", being monolithic.
> >
> > See
> > http://www.oreilly.com/catalog/opensources/book/appa.html
> > Enjoyable reading!
>
> "Most older operating systems are monolithic, that is, the whole
> operating system is a single a.out file that runs in 'kernel mode.'
> This binary contains the process management, memory management,
> file system and the rest. Examples of such systems are UNIX, MS-DOS,
> VMS, MVS, OS/360, MULTICS, and many more."
>
> I can't comment on his other qualifications, but I find 'monolithic'
> to be a very poor characterisation of MVS at all levels. If you
> take Supervisor State to be equivalent to "kernel mode" then he's
> way off base - very little of MVS runs that way. Key 0 may be a
> better approximation, but even that isn't so much. People have
> been mixing'n'matching bits of MVS releases, VSAM, DFSMS, JES for
> years.
>
> True, you don't have quite the same flexibility that you inevitably
> get with a open source system, but nevertheless ...
My understanding of microKernel architectures may be a little
wimpy; My experience was through fighting through QNX.
The following is a barely-informed opinion and is in no way
to be considered authoritative:
In a microKernel architecture, the only *true* kernel item
is the scheduler. Everything else is a module that runs as
if it's a "user process"; Your device drivers are, in effect,
userland processes (albeit potentially multithreaded). Each
component communicates to other components via messages
rather than the "syscall" (SVC etc) mechanism.
One advantage (AFAIK) is that it's easier to identify and
isolate the layers of the servicing system.
The downside (I learned this almost 10 years ago) is that if
it's proprietary *and* a microkernel, if a component doesn't
work right there's no way around it. Customers tend to build
systems that aren't easily predicted by the vendor, so the
interactions may get pathological.
So part of it is a matter of how fine-grained the scheduler
work and how far apart each component of the system is. It'd
be like having VM run one VM instance providing disk services
(or instance per controller, instance per drive), another set
of instances to handle the tape system, more instances to deal
with communications (one instance per layer, for instance) and
they'd ALL communication via either VCTC or IUCV. The only
job for the hypervisor is to manage scheduling and memory
management. No hypervisor services, just message passing.
So the scheduler has to be pretty fscking quick consider how
many context switches are needed to get any kind of work done.
So MVS *is* monolithic; The "fragments" of OS services are
not fine-grained enough despite the modularity of the system.
Linux is also, as is *BSD. GNU's HURD is based upon the
Mach microKernel. AIX is modular but "monolithic".
--
John R. Campbell Speaker to Machines [EMAIL PROTECTED]
- As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!
"It is impossible for ANY man to learn about impotence the hard way." - me
"ZIF is not a desirable trait when selecting a spouse." - me
