In a monolithic kerne1

In a monolithic kernel, all OS services
run along with the main kernel thread, thus also residing in the same
memory area. This approach provides rich and powerful hardware
access. Some developers, such as UNIX developer Ken Thompson,
maintain that it is "easier to implement a monolithic kernel"[30] than
microkernels. The main disadvantages of monolithic kernels are the
dependencies between system components — a bug in a device driver
might crash the entire system — and the fact that large kernels can
become very difficult to maintain.
Monolithic kernels, which have traditionally been used by Unix-like
operating systems, contain all the operating system core functions and
the device drivers (small programs that allow the operating system to
interact with hardware devices, such as disk drives, video cards and
printers). This is the traditional design of UNIX systems. A monolithic
kernel is one single program that contains all of the code necessary to
perform every kernel related task. Every part which is to be accessed by
most programs which cannot be put in a library is in the kernel space:
Device drivers, Scheduler, Memory handling, File systems, Network
stacks. Many system calls are provided to applications, to allow them to
access all those services. A monolithic kernel, while initially loaded with
subsystems that may not be needed can be tuned to a point where it is

as fast as or faster than the one that was specifically designed for the
hardware, although more in a general sense. Modern monolithic
kernels, such as those of Linux and FreeBSD, both of which fall into the
category of Unix-like operating systems, feature the ability to load
modules at runtime, thereby allowing easy extension of the kernel's
capabilities as required, while helping to minimize the amount of code
running in kernel space. In the monolithic kernel, some advantages
hinge on these points:
 Since there is less software involved it is faster.
 As it is one single piece of software it should be smaller both in
source and compiled forms.
 Less code generally means fewer bugs which can translate to fewer
security problems.
Most work in the monolithic kernel is done via system calls. These are
interfaces, usually kept in a tabular structure, that access some
subsystem within the kernel such as disk operations. Essentially calls
are made within programs and a checked copy of the request is passed
through the system call. Hence, not far to travel at all. The monolithic
Linux kernel can be made extremely small not only because of its ability
to dynamically load modules but also because of its ease of
customization. In fact, there are some versions that are small enough to
fit together with a large number of utilities and other programs on a
single floppy disk and still provide a fully functional operating system
(one of the most popular of which is muLinux). This ability to miniaturize
its kernel has also led to a rapid growth in the use of Linux in embedded
systems (i.e., computer circuitry built into other products).
These types of kernels consist of the core functions of the operating
system and the device drivers with the ability to load modules at
runtime. They provide rich and powerful abstractions of the underlying
hardware. They provide a small set of simple hardware abstractions and
use applications called servers to provide more functionality. This

particular approach defines a high-level virtual interface over the
hardware, with a set of system calls to implement operating system
services such as process management, concurrency and memory
management in several modules that run in supervisor mode. This
design has several flaws and limitations:
 Coding in kernel space is hard, since you cannot use common
libraries (like a full-featured libc), debugging is harder (it's hard to use
a source-level debugger like gdb), rebooting the computer is often
needed. This is not just a problem of convenience to the developers.
Debugging is harder, and as difficulties become stronger, it becomes
more likely that code is "buggier".
 Bugs in one part of the kernel have strong side effects, since every
function in the kernel has all the privileges, a bug in one function can
corrupt data structure of another, totally unrelated part of the kernel,
or of any running program.
 Kernels often become very huge, and difficult to maintain.
 Even if the modules servicing these operations are separate from the
whole, the code integration is tight and difficult to do correctly.
 Since the modules run in the same address space, a bug can bring
down the entire system.
 The disadvantage cited for monolithic kernels is that they are not
portable; that is, they must be rewritten for each new architecture
that the operating system is to be used on.

In the microkernel approach, the kernel itself only provides basic functionality that
allows the execution of servers, separate programs that assume former kernel
functions, such as device drivers, GUI servers, etc.
[edit]Microkernels
Main article: Microkernel
Microkernel (also abbreviated μK or uK) is the term describing an
approach to Operating System design by which the functionality of the
system is moved out of the traditional "kernel", into a set of "servers"
that communicate through a "minimal" kernel, leaving as little as
possible in "system space" and as much as possible in "user space". A
microkernel that is designed for a specific platform or device is only ever
going to have what it needs to operate. The microkernel approach
consists of defining a simple abstraction over the hardware, with a set of
primitives or system calls to implement minimal OS services such
as memory management, multitasking, and inter-process communication.
Other services, including those normally provided by the kernel, such
as networking, are implemented in user-space programs, referred to
as servers. Microkernels are easier to maintain than monolithic kernels,
but the large number of system calls and context switches might slow
down the system because they typically generate more overhead than
plain function calls.
Only parts which really require being in a privileged mode are in kernel
space: IPC (Inter-Process Communication), Basic scheduler, or
scheduling primitives, Basic memory handling, Basic I/O primitives.
Many critical parts are now running in user space: The complete
scheduler, Memory handling, File systems, and Network stacks. Micro
kernels were invented as a reaction to traditional "monolithic" kernel
design, whereby all system functionality was put in a one static program
running in a special "system" mode of the processor. In the microkernel,
only the most fundamental of tasks are performed such as being able to
access some (not necessarily all) of the hardware, manage memory and
coordinate message passing between the processes. Some systems

that use micro kernels are QNX and the HURD. In the case of QNX and
HURD, user sessions can be entire snapshots of the system itself or
views as it is referred to. The very essence of the microkernel
architecture illustrates some of its advantages:
 Maintenance is generally easier.
 Patches can be tested in a separate instance, and then swapped in
to take over a production instance.
 Rapid development time and new software can be tested without
having to reboot the kernel.
 More persistence in general, if one instance goes hay-wire, it is often
possible to substitute it with an operational mirror.
Most micro kernels use a message passing system of some sort to
handle requests from one server to another. The message passing
system generally operates on a port basis with the microkernel. As an
example, if a request for more memory is sent, a port is opened with the
microkernel and the request sent through. Once within the microkernel,
the steps are similar to system calls. The rationale was that it would
bring modularity in the system architecture, which would entail a cleaner
system, easier to debug or dynamically modify, customizable to users'
needs, and more performing. They are part of the operating systems
like AIX, BeOS, Hurd, Mach, Mac OS X, MINIX, QNX. Etc. Although
micro kernels are very small by themselves, in combination with all their
required auxiliary code they are, in fact, often larger than monolithic
kernels. Advocates of monolithic kernels also point out that the two-
tiered structure of microkernel systems, in which most of the operating
system does not interact directly with the hardware, creates a not-
insignificant cost in terms of system efficiency. These types of kernels
normally provide only the minimal services such as defining memory
address spaces, Inter-process communication (IPC) and the process
management. The other functions such as running the hardware
processes are not handled directly by micro kernels. Micro kernels

define the abstraction over the hardware with a set system calls that
implement minimal operating services such as thread management,
address space and interposes communication. Proponents of micro
kernels point out those monolithic kernels have the disadvantage that
an error in the kernel can cause the entire system to crash. However,
with a microkernel, if a kernel process crashes, it is still possible to
prevent a crash of the system as a whole by merely restarting the
service that caused the error. Although this sounds sensible, it is
questionable how important it is in reality, because operating systems
with monolithic kernels such as Linux have become extremely stable
and can run for years without crashing.
Other services provided by the kernel such as networking are
implemented in user-space programs such referred as servers. Servers
allow the operating system to be modified by simply starting and
stopping programs. For a machine without networking support, for
instance, doesn't start the networking server. Micro kernels generally
under perform traditional designs because of the overhead of moving in
and out of the kernel to move data between the various applications and
servers. The problem has been addressed in recent versions of the
kernel.
Disadvantages in the microkernel exist however. Some are:
 Larger running memory footprint
 More software for interfacing is required, there is a potential for
performance loss.
 Messaging bugs can be harder to fix due to the longer trip they have
to take versus the one off copy in a monolithic kernel.
 Process management in general can be very complicated.
 The disadvantages for micro kernels are extremely context based.
As an example, they work well for small single purpose (and critical)
systems because if not many processes need to run, then the
complications of process management are effectively mitigated.

A microkernel allows the implementation of the remaining part of the
operating system as a normal application program written in a high-level
language, and the use of different operating systems on top of the same
unchanged kernel.[21] It is also possible to dynamically switch among
operating systems and to have more than one active simultaneously.[21]
[edit]Monolithic kernels vs. microkernels
As the computer kernel grows, a number of problems become evident.
One of the most obvious is that the memory footprint increases. This is
mitigated to some degree by perfecting the virtual memory system, but
not all computer architectures have virtual memory support.[31] To reduce
the kernel's footprint, extensive editing has to be performed to carefully
remove unneeded code, which can be very difficult with non-obvious
interdependencies between parts of a kernel with millions of lines of
code.
By the early 1990s, due to the various shortcomings of monolithic
kernels versus microkernels, monolithic kernels were considered
obsolete by virtually all operating system researchers. As a result, the
design of Linux as a monolithic kernel rather than a microkernel was the
topic of a famous debate between Linus Torvalds and Andrew
Tanenbaum.[32] There is merit on both sides of the argument presented in
theTanenbaum–Torvalds debate.
[edit]Performances
Monolithic kernels are designed to have all of their code in the same
address space (kernel space), which some developers argue is
necessary to increase the performance of the system.[33] Some
developers also maintain that monolithic systems are extremely efficient
if well-written.[33][unreliable source?]
The monolithic model tends to be more
efficient[citation needed]
through the use of shared kernel memory, rather than
the slower IPC system of microkernel designs, which is typically based
on message passing.[citation needed]

The performance of microkernels constructed in the 1980s and early
1990s was poor.[34][35] Studies that empirically measured the
performance of these microkernels did not analyze the reasons of such
inefficiency.[34] The explanations of this data were left to "folklore", with
the assumption that they were due to the increased frequency of
switches from "kernel-mode" to "user-mode",[34] to the increased
frequency of inter-process communication[34] and to the increased
frequency of context switches.[34]
In fact, as guessed in 1995, the reasons for the poor performance of
microkernels might as well have been: (1) an actual inefficiency of the
whole microkernel approach, (2) the particular concepts implemented in
those microkernels, and (3) the particular implementation of those
concepts.[34] Therefore it remained to be studied if the solution to build
an efficient microkernel was, unlike previous attempts, to apply the
correct construction techniques.[34]
On the other end, the hierarchical protection domains architecture that
leads to the design of a monolithic kernel[29] has a significant
performance drawback each time there's an interaction between
different levels of protection (i.e. when a process has to manipulate a
data structure both in 'user mode' and 'supervisor mode'), since this
requires message copying by value.[36]
By the mid-1990s, most researchers had abandoned the belief that
careful tuning could reduce this overhead dramatically,[citation needed]
but
recently, newer microkernels, optimized for performance, such
as L4[37] and K42 have addressed these problems.[verification needed]

The hybrid kernel approach combines the speed and simpler design of a monolithic
kernel with the modularity and execution safety of a microkernel.
[edit]Hybrid (or) Modular kernels
Main article: Hybrid kernel
They are part of the operating systems such as Microsoft Windows NT,
2000 and XP. Dragonfly BSD etc. Similar to micro kernels, except they
include some additional code in kernel-space to increase performance.
These kernels represent a compromise that was implemented by some
developers before it was demonstrated that pure micro kernels can
provide high performance. These types of kernels are extensions of
micro kernels with some properties of monolithic kernels. Unlike
monolithic kernels, these types of kernels are unable to load modules at
runtime on their own. Hybrid kernels are micro kernels that have some
"none essential" code in kernel-space in order for the code to run more
quickly than it would were it to be in user-space. Hybrid kernels are a
compromise between the monolithic and microkernel designs. This
implies running some services (such as the network stack or
the filesystem) in kernel space to reduce the performance overhead of a
traditional microkernel, but still running kernel code (such as device
drivers) as servers in user space.
Many traditionally monolithic kernels are now at least adding (if not
actively exploiting) the module capability. The most well known of these
kernels is the Linux kernel. The modular kernel essentially can have
parts of it that are built into the core kernel binary or binaries that load

into memory on demand. It is important to note that a code tainted
module has the potential to destabilize a running kernel. Many people
become confused on this point when discussing micro kernels. It is
possible to write a driver for a microkernel in a completely separate
memory space and test it before "going" live. When a kernel module is
loaded, it accesses the monolithic portion's memory space by adding to
it what it needs, therefore, opening the doorway to possible pollution. A
few advantages to the modular (or) Hybrid kernel are:
 Faster development time for drivers that can operate from within
modules. No reboot required for testing (provided the kernel is not
destabilized).
 On demand capability versus spending time recompiling a whole
kernel for things like new drivers or subsystems.
 Faster integration of third party technology (related to development
but pertinent unto itself nonetheless).
Modules, generally, communicate with the kernel using a module
interface of some sort. The interface is generalized (although particular
to a given operating system) so it is not always possible to use modules.
Often the device drivers may need more flexibility than the module
interface affords. Essentially, it is two system calls and often the safety
checks that only have to be done once in the monolithic kernel now may
be done twice. Some of the disadvantages of the modular approach are:
 With more interfaces to pass through, the possibility of increased
bugs exists (which implies more security holes).
 Maintaining modules can be confusing for some administrators when
dealing with problems like symbol differences.
[edit]Nanokernels
Main article: Nanokernel
A nanokernel delegates virtually all services — including even the most
basic ones like interrupt controllers or the timer — to device drivers to make

the kernel memory requirement even smaller than a traditional
microkernel.[38]
[edit]Exokernels
Main article: Exokernel
Exokernels are a still experimental approach to operating system
design. They differ from the other types of kernels in that their
functionality is limited to the protection and multiplexing of the raw
hardware, and they provide no hardware abstractions on top of which
applications can be constructed. This separation of hardware protection
from hardware management enables application developers to
determine how to make the most efficient use of the available hardware
for each specific program.
Exokernels in themselves they are extremely small. However, they are
accompanied by library operating systems, which provide application
developers with the conventional functionalities of a complete operating
system. A major advantage of exokernel-based systems is that they can
incorporate multiple library operating systems, each exporting a different
API (application programming interface), such as one for Linux and one
for Microsoft Windows, thus making it possible to simultaneously run
both Linux and Windows applications. They are evolving and still under
experimental stage in development of an operating system that could
incorporate multiple library operating systems and are intended to
simultaneously run multiple operating systems of different kinds like
Linux and Microsoft Windows together using appropriate Application
Programming Interface (API). They provide minimal abstractions,
allowing low-level hardware access.
In exokernel systems, library operating systems provide the abstractions
typically present in monolithic kernels. Exokernels, also known vertically
structured operating systems, are a new and radical approach to OS
design. The idea is to force as very few abstractions possible on
developers, enabling them to make as many decisions as possible

regarding hardware abstractions. They are limited to protection and
multiplexing resources. They enable low-level access to the hardware.
The applications and abstractions that require specific memory
addresses or disk blocks, the kernel ensures that the request resource
is free and the application is allowed to access it. The kernel utilizes
library operating systems to provide abstractions. MIT has constructed
an exokernel called ExOS. An exokernel is a type of kernel that does
not abstract hardware into theoretical models. Instead it allocates
physical hardware resources, such as processor time, memory pages,
and disk blocks, to different programs. A program running on an
exokernel can link to a library operating system that uses the exokernel
to simulate the abstractions of a well-known OS, or it can develop
application-specific abstractions for better performance.[39]
[edit]History of kernel development
[edit]Early operating system kernels
Main article: History of operating systems
Strictly speaking, an operating system (and thus, a kernel) is
not required to run a computer. Programs can be directly loaded and
executed on the "bare metal" machine, provided that the authors of
those programs are willing to work without any hardware abstraction or
operating system support. Most early computers operated this way
during the 1950s and early 1960s, which were reset and reloaded
between the execution of different programs. Eventually, small ancillary
programs such as program loaders and debuggers were left in memory
between runs, or loaded from ROM. As these were developed, they
formed the basis of what became early operating system kernels.
The "bare metal"approach is still used today on some video game
consoles and embedded systems,[citation needed]
but in general, newer
computers use modern operating systems and kernels.
In 1969 the RC 4000 Multiprogramming System introduced the system
design philosophy of a small nucleus "upon which operating systems for

different purposes could be built in an orderly manner",[40] what would be
called the microkernel approach.
[edit]Time-sharing operating systems
Main article: Time-sharing
In the decade preceding Unix, computers had grown enormously in
power — to the point where computer operators were looking for new
ways to get people to use the spare time on their machines. One of the
major developments during this era was time-sharing, whereby a number
of users would get small slices of computer time, at a rate at which it
appeared they were each connected to their own, slower, machine.[41]
The development of time-sharing systems led to a number of problems.
One was that users, particularly at universities where the systems were
being developed, seemed to want to hack the system to get
more CPU time. For this reason, security and access control became a
major focus of the Multics project in 1965.[42] Another ongoing issue was
properly handling computing resources: users spent most of their time
staring at the screen and thinking instead of actually using the
resources of the computer, and a time-sharing system should give the
CPU time to an active user during these periods. Finally, the systems
typically offered a memory hierarchy several layers deep, and partitioning
this expensive resource led to major developments in virtual
memory systems.
[edit]Amiga
Main article: AmigaOS
The Commodore Amiga was released in 1985, and was among the first
(and certainly most successful) home computers to feature a hybrid
architecture.[citation needed]
The Amiga's kernel executive
component, exec.library, uses microkernel message passing design but
there are other kernel components, like graphics.library, that had a
direct access to the hardware. There is no memory protection and the
kernel is almost always running in a user mode. Only special actions are

executed in kernel mode and user mode applications can ask operating
system to execute their code in kernel mode.
[edit]Unix
Main article: Unix
A diagram of the predecessor/successor family relationship for Unix-like systems.
During the design phase of Unix, programmers decided to model every
high-leveldevice as a file, because they believed the purpose of
computation was data transformation.[43] For instance, printers were
represented as a "file" at a known location — when data was copied to
the file, it printed out. Other systems, to provide a similar functionality,
tended to virtualize devices at a lower level — that is, both
devices and files would be instances of some lower level concept.

Virtualizing the system at the file level allowed users to manipulate the
entire system using their existing file management utilities and
concepts, dramatically simplifying operation. As an extension of the
same paradigm, Unix allows programmers to manipulate files using a
series of small programs, using the concept of pipes, which allowed
users to complete operations in stages, feeding a file through a chain of
single-purpose tools. Although the end result was the same, using
smaller programs in this way dramatically increased flexibility as well as
ease of development and use, allowing the user to modify their workflow
by adding or removing a program from the chain.
In the Unix model, the Operating System consists of two parts; first, the
huge collection of utility programs that drive most operations, the other
the kernel that runs the programs.[43] Under Unix, from a programming
standpoint, the distinction between the two is fairly thin; the kernel is a
program, running in supervisor mode,[44] that acts as a program loader
and supervisor for the small utility programs making up the rest of the
system, and to provide locking and I/O services for these programs;
beyond that, the kernel didn't intervene at all in user space.
Over the years the computing model changed, and Unix's treatment of
everything as a file or byte stream no longer was as universally
applicable as it was before. Although a terminal could be treated as a file
or a byte stream, which is printed to or read from, the same did not
seem to be true for a graphical user interface.Networking posed another
problem. Even if network communication can be compared to file
access, the low-level packet-oriented architecture dealt with discrete
chunks of data and not with whole files. As the capability of computers
grew, Unix became increasingly cluttered with code. It is also because
the modularity of the Unix kernel is extensively scalable.[45] While
kernels might have had 100,000 lines of code in the seventies and
eighties, kernels of modern Unix successors like Linux have more than
13 million lines.[46]

Modern Unix-derivatives are generally based on module-loading
monolithic kernels. Examples of this are the Linux kernel in its
manydistributions as well as the Berkeley software distribution variant
kernels such as FreeBSD, DragonflyBSD, OpenBSD and NetBSD. Apart
from these alternatives, amateur developers maintain an active operating
system development community, populated by self-written hobby kernels
which mostly end up sharing many features with Linux, FreeBSD,
DragonflyBSD, OpenBSD or NetBSD kernels and/or being compatible
with them.[47]
[edit]Mac OS
Main article: History of Mac OS
Apple Computer first launched Mac OS in 1984, bundled with its Apple
Macintosh personal computer. For the first few releases, Mac OS (or
System Software, as it was called) lacked many essential features, such
as multitasking and a hierarchical filesystem. With time, the OS evolved
and eventually became Mac OS 9 and had many new features added,
but the kernel basically stayed the same.[citation needed]
Against this, Mac OS
X is based on Darwin, which uses a hybrid kernel called XNU, which was
created combining the 4.3BSD kernel and theMach kernel.[48]
[edit]Microsoft Windows
Main article: History of Microsoft Windows
Microsoft Windows was first released in 1985 as an add-on to MS-DOS.
Because of its dependence on another operating system, initial releases
of Windows, prior to Windows 95, were considered an operating
environment (not to be confused with an operating system). This product
line continued to evolve through the 1980s and 1990s, culminating with
release of the Windows 9x series (upgrading the system's capabilities to
32-bit addressing and pre-emptive multitasking) through the mid 1990s
and ending with the release of Windows Me in 2000. Microsoft also
developed Windows NT, an operating system intended for high-end and
business users. This line started with the release ofWindows NT 3.1 in

1993, and has continued through the years of 2000 with Windows
7 and Windows Server 2008.
The release of Windows XP in October 2001 brought these two product
lines together, with the intent of combining the stability of the NT kernel
with consumer features from the 9x series.[49] The architecture of Windows
NT's kernel is considered a hybrid kernel because the kernel itself
contains tasks such as the Window Manager and the IPC Manager, but
several subsystems run in user mode.[50] The precise breakdown of user
mode and kernel mode components has changed from release to
release, but the introduction of the User Mode Driver Framework in Windows
Vista, and user-mode thread scheduling in Windows 7,[51] have brought
more kernel-mode functionality into user-mode processes.
Development of microkernels
Although Mach, developed at Carnegie Mellon University from 1985 to
1994, is the best-known general-purpose microkernel, other
microkernels have been developed with more specific aims. The L4
microkernel family (mainly the L3 and the L4 kernel) was created to
demonstrate that microkernels are not necessarily slow.[37] Newer
implementations such as Fiasco and Pistachio are able to run Linux next
to other L4 processes in separate address spaces.[52][53]
QNX is a real-time operating system with a minimalistic microkernel design
that has been developed since 1982, having been far more successful
than Mach in achieving the goals of the microkernel paradigm.[54] It is
principally used in embedded systems and in situations where software is
not allowed to fail, such as the robotic arms on the space shuttle and
machines that control grinding of glass to extremely fine tolerances,
where a tiny mistake may cost hundreds of thousands of dollars.

In a monolithic kerne1

More Related Content

What's hot (19)

Similar to In a monolithic kerne1 (20)

More from Teja Bheemanapally (20)

Recently uploaded (20)

In a monolithic kerne1