\documentstyle[11pt,fullpage]{article}
\title{What Microkernels Mean For the Applications Programmer}
\author{Greg Hudson}
\begin{document}
\maketitle

Properly-designed microkernel operating systems represent an opening
up of kernel functionality to the applications programmer.  By
allowing functions which traditionally ran within the kernel to run in
user space, applications programmers can develop specialized file
systems, device drivers, memory management facilities, and other
low-level functions without requiring that their customers have access
to the kernel source.

Traditional operating systems present a general, high-level interface
to the application.  An application performs disk access is through a
file system; it accesses memory through a virtual memory system with
pages mapped into single processes.  Device drivers usually present a
character-stream or block-transfer interface to applications.

These interfaces are very convenient, but one can often achieve
significantly better performance by designing custom disk access or
memory management tools optimized for the particular access patterns
of an application.  Also, a few products involve specialized hardware
modules, and thus specialized device drivers.

Under traditional operating systems, applications programmers have
very few options if they require this kind of functionality.  With a
microkernel operating system, however, applications programmers can
design their own low-level tools that communicate with the
microkernel.  In very well-designed microkernels, some such
functionality may not even require privileged access; for instance, in
the FSF's HURD operating system, a file system can use as its storage
a file in another file system.  Thus the program need not have special
access privileges just because it uses its own file system, although
it may be faster if it can access the raw disk.

Unfortunately, today's microkernel-based operating systems are
significantly larger and slower than comparable monolithic operating
systems.  Thus, the potential for performance improvements is balanced
by an overall performance drop.  This is not a new problem;
flexibility usually comes at a price.  Newer microkernel-based
operating systems may recover some of the performance gap, and newer
hardware may make the 10--15\% performance difference irrelevant.

Portability is also an issue.  The IEEE recently standardized the Unix
system call interface in their POSIX.1 standard, making it relatively
easy to write portable Unix applications.  There is no such standard
for communicating with the microkernel at a lower level.  Thus, for
the time being, custom file systems and other low-level functions will
have to be ported from microkernel to microkernel.

\end{document}

