Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

Comp.os.research: Frequently answered questions [1/3: l/m 13 Aug 1996]
Section - [2.1] Microkernels, macrokernels, and the in-betweenies

( Part1 - Part2 - Part3 - Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Zip codes ]


Top Document: Comp.os.research: Frequently answered questions [1/3: l/m 13 Aug 1996]
Previous Document: [2] Recurrent discussions
Next Document: [2.2] Threads
See reader questions & answers on this topic! - Help others by sharing your knowledge
From: Recurrent discussions

A recurrent topic of discussion in this newsgroup has been the
comparison between microkernel (for example Mach and QNX) and
`macrokernel' (traditional Unix) operating systems.  The basic notion
of a microkernel consists of devolving as much functionality as
possible into processes rather than the kernel itself; different
systems take different approaches to implementing this.

For example, some systems (such as Mach) leave device drivers in the
kernel, and place higher-level services (such as file systems)
outside; others (such as QNX) move device drivers outside of the
kernel.

However, anecdotal evidence [93-03-03-07-56.52] suggests that the
distinction between microkernel and monolithic architectures is
becoming more blurred as time goes on, as the two advance.  For
example, most modern monolithic kernels now implement multiple threads
of execution and fine-grained parallelism.  Architecturally, this
approach begins to appear similar to a microkernel with several
kernel-space processes working from shared memory.

As an aside, people often complain that the Mach system can't be a
`real' microkernel, because it is so large (at least, this is the
argument most frequently cited).  However, I have been told that
automatically-generated code stubs contribute very significantly to
the size of the kernel, and that some size reduction would be likely
if MIG (the stub generator) produced better code.  [Can someone from
CMU comment on this?]  As mentioned above, the leaving of device
drivers in the kernel also contributes to Mach's size.

Debating microkernels versus monolithic kernels on the basis of kernel
size misses the central, architectural point.  In the same way as the
point of a RISC processor is not to minimise the instruction count,
but rather to make a different tradeoff between what is implemented
in the processor instruction set and what is implemented in other
ways, the microkernel architectural issue is to determine which
services are implemented in the microkernel, and which services are
implemented external to that microkernel.  By making appropriate
choices here, the goal is to enhance various OS attributes in a manner
that might not be addressable with a monolithic kernel OS.  System
attributes such as performance, flexibility, realtime, etc. are all
variables which are taken into account.

Some history:

Ira Goldstein and Paul Dale were the coiners of the term `microkernel'
back around 1989.

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Top Document: Comp.os.research: Frequently answered questions [1/3: l/m 13 Aug 1996]
Previous Document: [2] Recurrent discussions
Next Document: [2.2] Threads

Part1 - Part2 - Part3 - Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
os-faq@cse.ucsc.edu





Last Update March 27 2014 @ 02:11 PM