1,150 → 1,156 |
<?xml version="1.0" encoding="UTF-8"?> |
<chapter id="architecture"> |
<?dbhtml filename="arch.html"?> |
|
<chapter id="architecture"><?dbhtml filename="arch.html"?> |
<title>Architecture overview</title> |
<section> |
<title>Scheme</title> |
<para> |
<mediaobject id="arch1"> |
<imageobject role="html"> |
<imagedata format="PNG" fileref="images/arch1.png"/> |
</imageobject> |
|
<imageobject role="fop"> |
<imagedata format="SVG" fileref="images.vector/arch1.svg" /> |
</imageobject> |
</mediaobject> |
</para> |
</section> |
<title>Architecture overview</title> |
|
<section> |
<title>Kernel primitives</title> |
<para> |
<termdef><glossterm>Thread</glossterm> is the basic execution primitive.</termdef> |
</para> |
<section> |
<title>Scheme</title> |
|
<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><mediaobject id="arch1"> |
<imageobject role="html"> |
<imagedata fileref="images/arch1.png" format="PNG" /> |
</imageobject> |
|
<para> |
<termdef> |
<glossterm>Task</glossterm> is a multi-purpose entity, serving to |
<itemizedlist> |
<listitem>incorporate set if its threads</listitem> |
<listitem>provide common address space to its threads</listitem> |
<listitem>be an end-point in IPC</listitem> |
</itemizedlist> |
<imageobject role="fop"> |
<imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
</imageobject> |
</mediaobject></para> |
</section> |
|
</termdef> |
</para> |
|
<para> |
<termdef> |
<glossterm>Address space area</glossterm> is a mutually disjunctive range of memory with the code, stack and data. |
</termdef> |
</para> |
<section> |
<title>Kernel primitives</title> |
|
<para> |
<termdef> |
<glossterm>Address space</glossterm> is a aggregating entity for address space areas, connecting them to the task. |
</termdef> |
</para> |
</section> |
<para><termdef><glossterm>Thread</glossterm> is the basic execution |
primitive.</termdef></para> |
|
<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> |
<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> |
|
<formalpara> |
<title>Memory management</title> |
<para> |
Unlike the classic microkernel, HelenOS has all its memory management functionality in the kernel, available to the memory |
management server via the set of syscalls. |
</para> |
</formalpara> |
<para><termdef> <glossterm>Task</glossterm> is a multi-purpose entity, |
serving to <itemizedlist> |
<listitem>incorporate set if its threads</listitem> |
|
<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</listitem> |
<listitem>VESA & frame buffer</listitem> |
</itemizedlist> |
<listitem>provide common address space to its threads</listitem> |
|
</para> |
</formalpara> |
<listitem>be an end-point in IPC</listitem> |
</itemizedlist> </termdef></para> |
|
</section> |
<para><termdef> <glossterm>Address space area</glossterm> is a mutually |
disjunctive range of memory with the code, stack and data. |
</termdef></para> |
|
<section> |
<title>IPC</title> |
<para><termdef> <glossterm>Address space</glossterm> is a aggregating |
entity for address space areas, connecting them to the task. |
</termdef></para> |
</section> |
|
<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>Monolithic microkernel</title> |
|
<section> |
<title>Functionality model</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> |
|
<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> |
<formalpara> |
<title>Memory management</title> |
|
|
|
<para>Unlike the classic microkernel, HelenOS has all its memory |
management functionality in the kernel, available to the memory |
management server via the set of syscalls.</para> |
</formalpara> |
|
</chapter> |
<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 |
</listitem> |
|
<listitem> |
VESA & 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> |