| 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> |