4,40 → 4,62 |
|
<title>Architecture overview</title> |
|
<section> |
<para> |
<mediaobject id="arch1"> |
<imageobject role="html"> |
<imagedata fileref="images/arch1.png" format="PNG" /> |
</imageobject> |
<para>The HelenOS operating system is designed as a relatively small |
microkernel assisted with a set of userspace drivers and server tasks. |
HelenOS is not very radical in what subsystems should or should not be |
implemented in the kernel - in some cases, both kernel and userspace drivers |
exist. The reason for creating the system as a microkernel is prosaic. Even |
though it is initially more difficult to get the same level of functionality |
from a microkernel than it is in the case of a simple monolithic kernel, a |
microkernel is much easier to maintain once the pieces have been put to work |
together. Therefore, the kernel of HelenOS, as well as the essential |
userspace libraries thereof can be maintained by only a few developers who |
understand them completely. In addition, a microkernel based operating |
system reaches completion sooner than monolithic kernels as the system can |
be used even without some traditional subsystems (e.g. block devices, |
filesystems and networking).</para> |
|
<imageobject role="fop"> |
<imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
</imageobject> |
</mediaobject> |
</para> |
</section> |
<para><mediaobject id="arch1" xreflabel=""> |
<imageobject role="html"> |
<imagedata fileref="images/arch1.png" format="PNG" /> |
</imageobject> |
|
<imageobject role="fop"> |
<imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
</imageobject> |
|
<caption>HelenOS architecture overview</caption> |
</mediaobject></para> |
|
<para>HelenOS is comprised of the kernel and userspace server tasks. The |
kernel provides scheduling, memory management and IPC. It also contains |
essential device drivers that control the system clock and other devices |
necessary to guarantee a safe environment. Userspace communicates with the |
kernel through a small set of syscalls. The userspace layer consists of |
tasks with different roles, capabilities and privileges. Some of the tasks |
serve as device drivers, naming servers, managers of various kinds and some |
are just ordinary user programs. All of them communicate with other threads |
via kernel-provided IPC.</para> |
|
<section> |
<para>The HelenOS operating system is designed as a relatively small |
microkernel assisted with a set of userspace drivers and server tasks. |
HelenOS is not very radical in what subsystems should or should not be |
implemented in the kernel - in some cases, both kernel and userspace |
drivers exist. The reason for creating the system as a microkernel is |
prosaic. Even though it is initially more difficult to get the same level |
of functionality from a microkernel than it is in the case of a simple |
monolithic kernel, a microkernel is much easier to maintain once the |
pieces have been put to work together. Therefore, the kernel of HelenOS, |
as well as the essential userspace libraries thereof can be maintained by |
only a few developers who understand them completely. In addition, a |
microkernel based operating system reaches completion sooner than |
monolithic kernels as the system can be used even without some traditional |
subsystems (e.g. block devices, filesystems and networking).</para> |
<title>Scheduling</title> |
|
<para>HelenOS is comprised of the kernel and userspace server tasks. The |
kernel provides scheduling, memory management and IPC. It also contains |
essential device drivers that control the system clock and other devices |
necessary to guarantee a safe environment. Userspace communicates with the |
kernel through </para> |
<para>Kernel's unit of execution flow is a thread. A thread is an entity |
that executes code and has a stack that takes up some space in memory. The |
relation between kernel and userspace threads is 1:1:n, meaning that there |
can be several pseudo threads running within one userspace thread that |
maps to one kernel thread. Threads are grouped into tasks by functionality |
they provide (i.e. several threads implement functionality of one task). |
Tasks serve as containers of threads, they provide linkage to address |
space and are communication endpoints for IPC.</para> |
|
<para>The scheduler deploys several run queues on each processor. A thread |
ready for execution is put into one of the run queues, depending on its |
priority and its current processor, from where it is eventually picked up |
by the scheduler. Special purpose kernel threads strive to keep processors |
balanced by thread migration. Threads are scheduled by the round robing |
scheduling policy with respect to multiple priority run queues.</para> |
|
<para></para> |
</section> |
</chapter> |