\documentstyle[11pt,fullpage]{article}
\title{Microkernels and Protocol Implementations}
\author{Greg Hudson}
\begin{document}
\maketitle

Clark brings up several problems with operating system implementations
of protocols: protocols often require timed events for which operating
system internals have little support; implementations which handle
protocol events at interrupt time can easily bring down the whole
operating system; the scheduler cannot control the amount of time used
by protocol implementations in the operating system; and it seems
unlikely that a single implementation of the protocol will be
efficient for all purposes.  Balanced against these are the
disadvantages of implementing protocols in user space: the scheduler
is often slow enough to put significant performance limitations on the
protocol process, and the user process may not have access to the
proper hooks to make, for instance, network communication look like a
general byte stream.

In Clark's example of the TCP/IP implementation, several components
are not replaceable because the kernel must demultiplex TCP/IP packets
before it knows which user process should have control over them, and
there must be hooks in the byte-stream operations (in the case of
Unix, routines like read() and write()) to call network routines.

Microkernel-based operating systems resolves some of the issues Clark
brings up: such operating systems tend to have support for preemptable
operating system code, for instance, which doesn't operate in
interrupt mode.  Moreover, since low-level components of such
operatings are replaceable, programs which require high bandwidth can
have different TCP implementations than programs which want to
minimize CPU overhead, without sacrificing the read() and write()
interface.

Microkernels do not solve some of the fundamental difficulties,
however: the scheduler is a fairly expensive part of any operating
system, and if you wish the scheduler to control the amount of CPU
time used by network routines in any given time slice, you have to put
up with the scheduler's performance.  Microkernel-based operating
systems tend to involve more inter-process communication and
scheduling overhead than monolithic operating systems.

Some monolithic operating systems allow the user to dynamically load
modules into the kernel.  This allows, for instance, several TCP
implementations to be running at the same time, without extra
inter-process communication overhead.  It doesn't solve the
fundamental scheduler overhead issue by itself, but it does give the
programmer enough control over the system to take an arbitrary
approach to this problem.  Microkernels, by contrast, don't allow
anything outside the microkernel to run independently of the
scheduler.

In summary, microkernels resolve some of the issues associated with
implementing protocols in the operating system by virtue of a more
flexible design than traditional monolithic operating systems.  Bypass
mechanisms such as dynamically loadable kernel modules give the
programmer even more flexibility to resolve these issues.

\end{document}

