5,9 → 5,8 |
<title>Architecture overview</title> |
|
<section> |
<title>Scheme</title> |
|
<para><mediaobject id="arch1"> |
<para> |
<mediaobject id="arch1"> |
<imageobject role="html"> |
<imagedata fileref="images/arch1.png" format="PNG" /> |
</imageobject> |
15,134 → 14,30 |
<imageobject role="fop"> |
<imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
</imageobject> |
</mediaobject></para> |
</mediaobject> |
</para> |
</section> |
|
<section> |
<title>Kernel primitives</title> |
<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> |
|
<para><termdef><glossterm>Thread</glossterm> is the basic execution |
primitive.</termdef></para> |
|
<para><termdef><glossterm>Thread context</glossterm> represents state of |
the <emphasis>thread</emphasis>. Thread context is built of the context |
registers contents, FPU state and the stack.</termdef></para> |
|
<para><termdef><glossterm>Task</glossterm> is a multi-purpose entity, |
serving to incorporate set if its threads, provide common address space to its threads, |
be an end-point in IPC.</termdef></para> |
|
<para><termdef><glossterm>Address space area</glossterm> is a mutually |
disjunctive range of memory with the code, stack and data. |
</termdef></para> |
|
<para><termdef><glossterm>Address space</glossterm> is a aggregating |
entity for address space areas, connecting them to the task. |
</termdef></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 </para> |
</section> |
|
<section> |
<title>Monolithic microkernel</title> |
|
<para>Though HelenOS was initially planned as a microkernel, we were |
trying to avoid several issues, connected with microkernels, such as much |
higher overhead during memory management and hardware operations. For this |
reason some of the subsystems, that are to be implemented as servers in |
classic microkernel design, were implemented as a part of kernel, thus |
minimizing this overhead.</para> |
|
<formalpara> |
<title>Memory management</title> |
|
<para>HelenOS has all its memory |
management functionality in the kernel, available to the memory |
management server via the set of syscalls.</para> |
</formalpara> |
|
<formalpara> |
<title>Kernel device drivers</title> |
|
<para>HelenOS kernel has some of the very basic device drivers |
<itemizedlist> |
<listitem> |
ACPI |
</listitem> |
|
<listitem> |
APIC |
</listitem> |
|
<listitem> |
SMP configuration |
</listitem> |
|
<listitem> |
System clock |
</listitem> |
|
<listitem> |
Interrupt controllers |
</listitem> |
|
<listitem> |
Console and frame buffer |
</listitem> |
|
</itemizedlist></para> |
</formalpara> |
</section> |
|
<section> |
<title>IPC</title> |
|
<para>HelenOS IPC is designed in analogy with telephone communication. |
Each task has an <emphasis>answerbox</emphasis> and a set of |
<emphasis>phones</emphasis> to call another tasks' answerboxes.</para> |
|
<para>Communication is possible after the connection is established, and |
can be either <emphasis>asynchronious</emphasis> or |
<emphasis>synchronious</emphasis>.</para> |
</section> |
|
<section> |
<title>Functionality model</title> |
|
<para>As you know, microkernel design is very simple, just enough to |
provide communication facility for tasks. Most of the OS functionality is |
performed by server tasks, that are running in userspace. Thus most of the |
system calls in monolithic kernels, are the IPC calls on server tasks in |
microkernels.</para> |
|
<para>Moreover, problems experience the device drivers. Running in the |
user space, device driver still needs to recieve interrupts and access |
hardware directly.</para> |
|
<para>This raises two major problems in microkernels: <orderedlist |
numeration="loweralpha"> |
<listitem> |
What is the recipient address of the server (e.g. "memory manager" or a specific device driver) ? |
</listitem> |
|
<listitem> |
How this server task is going to access hardware or kernel while running in the user mode? |
</listitem> |
</orderedlist></para> |
|
<formalpara id="intro_ns"> |
<title>Name server</title> |
|
<para>As every microkernel, HelenOS has a "Name server" task with "well |
known" IPC address, that connects user task to any server just by the |
string service indentification.</para> |
</formalpara> |
|
<formalpara id="intro_ddi"> |
<title>Device driver interface</title> |
|
<para>Device drivers use special syscalls to map physical memory areas |
into their address space, to map port regions (mostly ia32). Interrupts |
are delivered to the device driver task by the standard IPC |
means.</para> |
</formalpara> |
</section> |
</chapter> |