Microkernels

harpywarrenDéveloppement de logiciels

14 déc. 2013 (il y a 7 années et 7 mois)

300 vue(s)




Operating Systems Internals: Microkernels


Page
1

of 15

Contents










0


WHAT IS A MICROKERNE
L?


2

WHAT IS A PROCESS MA
DE UP FROM?

4

INTER
-
PROCESS COMMUNICATIO
N (IPC)

5

DISTRIBUTED SYSTEMS


6

4.1

P
RICE
:

P
ERFORMANCE RATIO

6

4.2

F
LEXIBILITY

AND
P
ORTABILITY

7

4.3

R
ELIABILITY

7

4.4

M
AINTAINABILITY AND
U
PGRADABILITY

7

4.5

I
NHERENT

D
ISTRIBUTION

8

4.6

D
ATA SHARING AND COMM
UNICATION

8

4.7

M
ORE COMPLEX SOFTWARE

8

4.8

S
YSTEM OVERLOAD

8

4.9

S
ECURITY

9

4.10

D
ISTRIBUTED
S
YSTEMS
(C
ONTINUED
)

9

MICROKERNEL EXAMPLES


11

5.1

W
INDOWS
NT

11

5.2

C
HORUS

12

5.3

QNX

12


5.2

Amoeba

12

5.5

M
K
L
INUX

13

CONCLUSION


14

BIBLIOGRAPHY


15




Operating Systems Internals: Microkernels


Page
2

of 15

What Is A Microkernel?







1




The traditional operating system is built within a monolithic kernel. This
kernel contains all of the core functions of the operating system, from
scheduling to the management of the file system. In contrast microkernel
systems are essentially monolith
ic kernels that have been cut down to the
bear minimum. Microkernel systems only provide the essential system
functions. Any other operating system services are provided outside the
kernel by user processes (called servers). As advances are made in
computi
ng it is difficult to see the distinction between monolithic kernels and
microkernels. For example monolithic kernel based operating systems such
as Windows 95 have threads, which is an inherent feature of microkernel
architectures.



The many companies cu
rrently involved in the development of
microkernels cannot agree on what services the microkernel should provide.
For example should the device drivers be situated within the kernel? Mach
and Chorus keep the device drivers outside the kernel, but Windows N
T
allows them to run in kernel mode to improve efficiency. Running these
services in kernel mode means message passing is replaced by function
calls, which are a lot more efficient. Should non
-
kernel operations be run in
user space, is another issue? Under

NT many servers run their code in
kernel space for reasons of efficiency. This has led to many companies
stating that NT is not a true microkernel.



Typically the following functions are handled within the microkernel,
although as explained later this is

not a definitive list:




Inter
-
process Communication (via message passing)



Short
-
term scheduling (basic thread process management)



Very low
-
level memory management



Low level Input/Output (mostly interrupt handling)



Low level Network support






Operating Systems Internals: Microkernels


Page
3

of 15

The main goa
l of a microkernel system is to keep it small. The services
contained within the kernel itself are only provided because it would be
expensive, or difficult to provide them elsewhere. The microkernel is the layer
between the physical hardware, and the set
of sub
-
systems that comprise the
remainder of the Operating System. The user
-
level servers that provide the
other operating system functions run outside the kernel in what is called
user
mode
. Any processes within the kernel are said to run in
kernel mode
.

The
user level processes that comprise the sub
-
system typically provide the
following services:




The File system



Directory system



Full process management (scheduling)



Security services



The microkernel replaces the vertical layout of the monolithic
opera
ting system and replaces it by a horizontal one. The microkernel
facilitates communication between the components of the operating system.
The kernel validates messages and either deals with them itself or passes
them between servers. The user level servic
es are granted access to
hardware resources by issuing requests to the kernel via function calls.
Although communication to hardware is done low level through the kernel,
this is transparent to the user. The user simply calls a function through the
server
and the kernel and server communicate to accomplish the task. The
microkernel itself is never scheduled for execution; its simply called by
processes or hardware interrupts.






Operating Systems Internals: Microkernels


Page
4

of 15

What is a process made up from?




2




In order for processing to be carried
out as efficiently as possible,
processes are split into sub tasks called threads. The diagram below shows a
process and it’s threads. Each thread has it’s own Program counter and
stack but the threads within a process share the same address space and
thus

share global variables.


The structure of a process (Tanenbaum 1992)


A thread is to a process, what a process is to a machine. A thread is
the unit of execution and the process is the unit of protection. Many
conventional operating systems built arou
nd the monolithic kernel (such as
UNIX) have the process as the smallest component of execution and also as
the unit of protection. This means that inter
-
process communication is not
possible as the protection of the process prevents this. The family of th
reads
that comprise a process can communicate freely, and they are protected
from outside interference by the process itself. Threads within a process work
in co
-
operation so there is no need for protection. They have unrestricted
access to each others dat
a space so that they can work in parallel to
complete a process. In the same way that processes can be running, ready,
blocked or terminated so can the threads within a process.



While one thread is ‘sleeping’ another thread within that process can
contin
ue with its execution. In addition to this, while one thread is running on
one machine, another thread can run on a different machine. This improves
turnaround and helps reduce any bottle
-
necks in the system by utilising any
CPU idle time on other machines
. Each thread is scheduled independent of
any other threads, although certain threads may have prerequisites. One
example of where a thread
-
based system can be used to complete a process
efficiently is where one thread is dedicated to waiting for signals.

This frees
the rest of the family of threads from interruption so that they can complete
their tasks as quickly as possible.




Operating Systems Internals: Microkernels


Page
5

of 15

Inter
-
process Communication (IPC)




3




In order for the operating system to function, the microkernel must be
able to communic
ate with its user process. This is done via message
passing. The user process (Client) sends a message, or request to the kernel
(Server) asking for some action to be carried out. The message is passed to
the kernel which then relays the message to the ser
ver (see diagram below).
Once the action is complete the kernel passes a message back to the client
giving the results of the action. The diagram below shows the Kernel and
User modes utilised by a microkernel system.



User and Kernel modes (Tan
enbaum 1992)



Message passing is network transparent i.e. we do not need to know if
a message has come from another process on the same machine or from a
process on a totally different machine. This message passing is based on the
client
-
server request
-
re
ply

protocol. The client sends a request to the
server asking for a service and the server responds with the requested
service completed, or returns an error code.



The kernel handles communication between the client and server
processes. Each part of th
e operating system is kept small so that it’s
manageable. If one server were to crash
,

the system should be able to
continue (although some decrease in response time
will

be noticed).



A technique known as
Remote Procedure Call (RPC)

can be used to
ensur
e the distribution of the microkernel system is transparent. This is
where a process calls a procedure on another machine. The User sees no
message passing or input/output as parameters are used to call the
procedures and the results are passed back as a f
unction return.




RPC facilitates communication between a client and a server but does
not allow communication between one sender and many receivers. A method
known as group communication can be used so that a request is broadcast
without a specific desti
nation. This means groups can be built and members
can be destroyed dynamically without causing the system to crash.




Operating Systems Internals: Microkernels


Page
6

of 15

Distributed systems







4





The development of the modular, flexible microkernel systems has
lead to a marked increase in Distributed

Systems. It has always been a good
idea to spread the workload so that the greatest throughput can be achieved,
but only relatively recently have we had the software to utilise the distributed
components effectively. A microkernel system allows the separa
te user level
servers to sit on separate machines, and thus no one machine should
become overloaded. The diagram below shows how a microkernel system
could be arranged to form a distributed system.



Distribution of microkernel servers (Tanenbaum 1992)



Tanenbaum has been developing a microkernel called Amoeba at
Amsterdam University since 1983. This microkernel is partially useful for
Distributed Systems as it makes the system appear as a single pool of
resources. The user is not aware of the system dist
ribution; they simply see a
pool of resources, which they can use.



4.1

Price: Performance ratio


Microkernels allow the operating system to be distributed across a
system. The cost of many lower powered machines offers better performance
for your money w
hen compared to one very powerful, very expensive
computer. When the server processes are slit across machines no one
machine should become overloaded. If this is the case then it would be
advantageous to have two or more machines running a single server p
rocess
e.g. two machines co
-
ordinating the file system. If one central computer (or
one Monolithic kernel) is used, then if this unit is tied up with I/O operations
the CPU idle time goes to waste. Whereas if microkernel architecture is used
the various pr
ocesses can be split up and the smaller easier to manage sub
tasks can be processed quickly, possibly by separate machines. A
microkernels modular nature means a system can be built gradually, and
thus the initial cost can be spread.




Operating Systems Internals: Microkernels


Page
7

of 15

4.2

Flexibility

and P
ortability


The modular microkernel allows user level servers to be added and
removed without having to shut
-
down the system. The flexibility of the
microkernel comes from the fact that it does almost nothing so services can
easily be added on. Each user l
evel server has a well
-
defined interface that is
easy to access and easy to understand. These servers are equally
accessible to the clients irrespective of location, in fact the user it unlikely to
know where the server resides. It is also easy to add a ne
w service and
debug it, as the whole system does not need to be stopped (as in the
monolithic kernel architecture). With flexibility comes portability. Components
(servers) can be mixed and matched to suit the system they are to run on.
Windows NT is a pri
me example of a portable system as it now runs on
several architectures: Intel, Mips, Alpha and a few others under development.
The ability of microkernels to support multiple operating system personalities
means we have access to a more diverse platform o
f applications.


4.3

Reliability


With the modular components being simplified there is less that can
go wrong. In the case of monolithic kernels there are hundreds of thousands
of lines of code. If they go wrong finding the error would be a near impossib
le
task. The modular nature of microkernels means it would be a lot easier to
locate the errors. Should any problems occur then new fixed components can
be inserted and processing can continue.



One of the main ideas behind distributed systems is the abil
ity to
recover from device failures i.e. if one device goes down there is another that
takes over its tasks and the system continues without so much as a ‘hiccup’.
The same applies to software; inoperative components can be replaced as
required without co
mpromising system integrity.


4.4

Maintainability and Upgradability


As mentioned previously it is easier to build and maintain a system,
which is highly cohesive and loosely coupled. Parts of a system can be
upgraded bit by bit without having to replace t
he whole system i.e. maybe a
file server is too slow. This could be replaced without having to replace any of
the other servers. The same is true of microkernel servers. If a piece of code
that handles the file system is too slow then a new service could b
e written
and implemented by the user.





Operating Systems Internals: Microkernels


Page
8

of 15

4.5

Inherent

Distribution


Many applications by their very nature are distributed and microkernel
architecture means the needs of these systems can be met. If tasks need to
be processed in parallel then the nature o
f microkernel systems with inter
-
process communication between user level processes means this is
possible.


4.6

Data sharing and communication


Microkernels use threads to split processes into sub
-
tasks. These
tasks can communicate freely as they share da
ta spaces. With threads you
can have communication so that tasks within a process can work in parallel
(improving turnaround) while still having protection (within the process).


4.7

More complex software


Although more complex software is required for dis
tributed systems, if
it is broken into modules as in microkernel systems, then the individual
components are relatively simple and thus they should be maintainable.
Microkernels are adaptive to mistakes as modules with problems can be
replaced dynamically,

without changing and re
-
compiling the whole system.
Changes can be made dynamically and unlike the monolithic system you do
not have to rebuild the whole system (kernel).


4.8

System overload


The extensive use of message passing made by microkernel syste
ms
has an overhead. The massive amount of information passing through the
system increases the demands on resources and could lead to system
overload. Having said this, although message passing is slower than directly
calling functions the inter
-
process co
mmunication that messages facilitate
outweighs the additional burden of message passing.


Some microkernel systems such as NT can substitute message
passing by running servers in kernel mode. This allows function calls to be
made thus reducing network traf
fic and the message passing overhead.
Chorus has the best of both worlds in terms of speed and flexibility as it can
run server process in both user and kernel mode. Other microkernels such as
QNX allow communication between process by copying information
in shared
memory i.e. rather than passing messages between two processes, an area
of shared memory is copied that contains the information a process requires.





Operating Systems Internals: Microkernels


Page
9

of 15

4.9

Security


With flexibility comes the price of reduced security. When a message
is passed th
e server has no way of knowing from whom the message came.
No ID is put in the message as the sender could simply lie to get around this.
This potential problem of unidentified messages could result in processes
getting at data that they should not be allo
wed to see. The implications of
shared memory communication are even more serious as there is no security
here at all. Microkernels however should only allow processes to share
memory if they are to work co
-
operatively and thus security is not an issue as
they both working together to achieve the same goal.



4.10

Distributed Systems (Continued)



The aim of any modern operating system is to be flexible. Software
unlike hardware tends to be around for many years. UNIX is now 28 years
old but its lack of fle
xibility means it is no longer such a desirable operating
system. The Monolithic UNIX kernel is so large because it contains the
privileged system along with the core kernel within one unit. Microkernels
have split this core kernel from the privileged syst
em to increase modularity.
UNIX is designed around a file system split into layers (encompasses file
system itself, IPC, input/output management, process management). Each
vertical layer can only communicate with the layers above and below it (as
shown in
the next figure). It is difficult to remove a layer because of the tight
interfaces between them.


Assuming the machines are running the same microkernel systems
we only need three levels of protocol to communicate as opposed to seven
under the ISO OSI sev
en layer model. The physical and data link layers need
to take care of packet transfer between the kernel and the user
-
level
processes (servers). There is no session as such as the servers and kernel
and linked all of the time. The diagram below shows the
relationship between
the conventional ISO OSI seven
-
layer model (used by UNIX) and the
protocols within microkernel systems.



Level

OSI ISO 7 layer model

Microkernel system




7

Application


6

Presentation


5

Session

Request
-
Reply

4

Transport


3

Net
work


2

Data
-
Link

Data
-
link

1

Physical

Network (Ethernet/Token ring)






Operating Systems Internals: Microkernels


Page
10

of 15

The microkernels simple structure means communication between the
client and server is reduced to two system calls, one to send and one to
receive. Simplicity is the best form of eff
iciency! (first lecture of the semester
on UNIX).


As mentioned previously, microkernels are cut down to a minimal unit
while still remaining functional. However, it is a common misconception that
the small size of a microkernel is to do with the issue of

efficiency. This is not
true because it has been known for years that monolithic programs are more
efficient due to fewer remote function calls. The incorporation of thread
architecture to achieve IPC and parallelism along with message passing is
not par
t of microkernel architecture; these features simply evolved at the
same time as microkernels developed. Microkernels simply make use of
these features as they improve efficiency and flexibility.




Operating Systems Internals: Microkernels


Page
11

of 15

Microkernel Examples







5



5.1

Windows NT


Windows NT i
s by far the most popular microkernel based system,
largely due to Microsoft’s domination of the computer market. NT provides a
user
-
friendly interface that appeals to both experts and novice users. A major
factor that has contributed to its success is the

massive amounts of money
Microsoft plough into advertising. Concentration of machine specific code in
the microkernel of NT has resulted in NT being ported to several
architectures including Intel, Mips and Alpha systems.


IBM and USL say NT is not a mic
rokernel as NT contains an executive
layer that runs between the microkernel and server processes. This
executive layer runs services such as Input/Output and security. Microsoft
argues that the executive layer communicates with its server processes via
me
ssage passing but this hardly makes it a microkernel. The Process
manager, virtual memory managers along with other server processes are
actually outside the NT kernel so technically NT could be called a
microkernel. However, NT does not follow the golden
rule of microkernels in
that “
all non essential services should run in processors user mode

(Tanenbaum 1992) but, as argued by Microsoft the servers
are

outside the
kernel, they just run their code in kernel mode for reasons of efficiency.
Although USL us
e the argument that NT runs server processes in kernel
mode, their system Chorus also allows sub
-
systems to run their code in
kernel mode if required.


I believe NT is an operating system that uses modular architecture to
provide an efficient operating sys
tem. NT is not however in my opinion a
microkernel as it provides direct access to the hardware through its HAL
(Hardware Abstraction Layer) which by
-
passes the kernel. The kernel still
handles interrupt requests but the device drivers’ work without superv
ision by
the kernel.





Operating Systems Internals: Microkernels


Page
12

of 15

5.2

Chorus


The initial version of Chorus provided the device drivers within the kernel,
but the current version has separated these from the kernel and placed them
in server processes. This separation allows dynamic configuration o
f
devices. USL’s version of Chorus has the advantage that it can run server
processes in kernel mode for efficiency or run them in user mode for
flexibility. Chorus contains the bare minimum facilities, in that the microkernel
supports only the following c
ore services:




Distributed processes (Threads management)



Memory Management



IPC


via Remote Procedure Calls



Low level hardware support


5.3

QNX


The QNX microkernel is simplicity itself as it contains only 14 function
calls. QNX is a mature microkernel an
d has been used commercially for five
years. The kernel handles process scheduling, IPC, interrupt support and low
level network services. As QNX fits entirely in the cache of a standard
486/Pentium it runs very quickly. The dependant IPC of QNX means it i
s
ideally suited to embedded systems. As the kernel does not provide file
system support and other user processes, it is kept small and thus is ideal for
embedded systems. Writing extensions to QNX is relatively straight forward
as there are only a small s
et of API’s to learn (fourteen).


5.2

Amoeba


Tanenbaum developed Amoeba in Amsterdam to make a physically
distributed system behave like one logical system. The IPC provided by
Amoeba is via Remote Procedure Calls. These make a collection of
CPU/Workstations
appear as a pool of resources system i.e. it is transparent
to the user that more than one system exists. The initial release of Amoeba in
1983 was designed to emulate UNIX so that the massive amount of existing
software could be utilised without having to

re
-
code it. In Amoeba the device
drivers reside in the kernel and thus cannot be loaded dynamically as in
Chorus microkernels.






Operating Systems Internals: Microkernels


Page
13

of 15

5.5 MkLinux


MkLinux is an Open Source operating system, which consists of an
implementation of the Linux operating system,

hosted on the Mach
microkernel. There are between 50,000 and 100,000 MkLinux users. A
significant number of the installed MkLinux systems are being used in
mission
-
critical applications.


During the early years, most MkLinux development occurred either at

Apple or at The Open Group Research Institute in Grenoble, France.
MkLinux Developer Release 1 (DR1) was released in early 1996.


Later that year, DR2 was released, incorporating numerous bug fixes.
The Linux server was updated to the 2.0.x source base sh
ortly thereafter. At
about the same time, (December 1996) PCI machines were supported and
DR2.1 was completed and incorporated into Apple's "Reference Release".
DR2.1 was released a few months later. With the exception of shared library
support and support

for 603e machines, very little changed until the
appearance of the G3 Power
-
Macs in late 1997.






Operating Systems Internals: Microkernels


Page
14

of 15

Conclusion









6




The ability to run multiple personalities on top of microkernel
architecture means you are no longer bound by the operating system to

certain software. This could well release the stranglehold Microsoft currently
has on the world market. However with the success of NT, Microsoft cannot
be uprooted so easily.


The technical manager at Chorus systems said “
microkernels will have
the same

impact on the software side as the chip revolution had on the
hardware side
”. Considering Microsoft, Apple, IBM, Novell/USL and Sun are
all heading down the microkernel path it seems that microkernels are the
thing of the future. There is a real need for
an operating system that is
lightweight while still providing the rich graphical environment that Windows
users are accustomed to.


The beauty of the microkernel is that you have the basic system
provided and you build on that. This drastically reduces th
e size of the
Operating System and thus the resources required. The definitions offered by
various manufacturers of what a microkernel should contain are varied, but
the fact remains that a flexible operating system needs to be developed, and
the better wa
y of doing it is by using the microkernel technology.






Word count: 3765



Operating Systems Internals: Microkernels


Page
15

of 15

Bibliography









7



Books


Modern Operating Systems

Andrew S Tanenbaum, 1992,Prentice
-
Hall


Operating Systems (Second Edition)

H.M. Dietel, 1990, Addison Wesley


An Introducti
on to Distributed & Parallel Computing

Joel M. Crichlow, 1988, Prentice Hall

Chapters: 1, 4


Distributed Computing

Fred B. Chambers, David A. Duce, Gillian P. Jones, 1984, Academic Press

Chapters: 12, 13



Internet


(
www.
byte.com)
. The following are articles found using the search engine of
the site:




Inside the Web PC



The Great OS Debate



QNX Forges ahead



Small Kernels Hit it BIG



The Chorus Microkernel



Objects on the March



Personality Plus


The following links are mainly
background reading on the different
microkernels:


www.mklinux.org

www
-
inf.int
-
evry.fr/~adm_chor/faq.html

www.lib.ox.ac.uk/internet/news/faq/archive/chorus
-
faq.html

www.cs.arizona.edu/people/bridges/os/commercial.html

kb.indiana.edu

www.faqs.org/faqs/os
-
research/part2/section
-
6.html

www.cs.vu.nl/pub/amoeba

www.cs.vu.nl/~ast/minix.html

sslab
.postech.ac.kr/~yjnam/L4/l4.html

www2.cs.utah.edu/~lepreau/osdi94/condict/abstract.html

dacny.com/Btrieve/produc_1.htm

www.ntlug.org/~cbbrowne/osmk.html