Subversion Repositories HelenOS-doc

Rev

Rev 27 | Rev 38 | Go to most recent revision | Details | Compare with Previous | Last modification | View Log | RSS feed

Rev Author Line No. Line
9 bondari 1 
<?xml version="1.0" encoding="UTF-8"?>
2 
 
11 bondari 3 
<chapter id="architecture"><?dbhtml filename="arch.html"?>
4 
    <title>Architecture overview</title>
16 bondari 5 
    <section>
27 bondari 6 
        <title>Scheme</title>
7 
        <para>
8 
            <mediaobject id="arch1">
9 
                <imageobject role="html">
10 
                    <imagedata format="PNG" fileref="images/arch1.png"/>
11 
                </imageobject>
12 
 
13 
                <imageobject role="fop">
14 
                    <imagedata format="SVG" fileref="images.vector/arch1.svg" />
15 
                </imageobject>
16 
            </mediaobject>
17 
        </para>
18 
    </section>
37 bondari 19 
 
27 bondari 20 
    <section>
37 bondari 21 
        <title>Monolithic microkernel</title>
22 
        <para>
23 
            Though HelenOS was initially planned as a microkernel, we where trying to avoid several issues, connected
24 
            with microkernels, such as much higher overhead during memory management and hardware operations. For this reason
25 
            some of the subsytems, that are to be implmented as servers in classic microkernel design, where implemented
26 
            as a part of kernel, thus minimizing this overhead.
27 
        </para>
28 
 
29 
        <formalpara>
30 
        <title>Memory management</title>
31 
        <para>
32 
            Unlike the classic microkernel, HelenOS has all its memory management functionality in the kernel, available to the memory
33 
            management server via the set of syscalls.
34 
        </para>
35 
        </formalpara>
36 
 
37 
        <formalpara>
38 
        <title>Kernel device drivers</title>
39 
        <para>
40 
            HelenOS kernel has some of the very basic device drivers
41 
            <itemizedlist>
42 
            <listitem>ACPI</listitem>
43 
            <listitem>APIC</listitem>
44 
            <listitem>SMP configuration</listitem>
45 
            <listitem>System clock</listitem>
46 
            <listitem>Interrupt controllers</listitem>
47 
            <listitem>Console</listitem>
48 
            <listitem>VESA &amp; frame buffer</listitem>
49 
            </itemizedlist>
50 
 
51 
        </para>
52 
        </formalpara>
53 
 
54 
    </section>
55 
 
56 
    <section>
57 
        <title>Kernel primitives</title>
58 
        <para>
59 
        <termdef><glossterm>Thread</glossterm> is the basic execution primitive.</termdef>
60 
        </para>
61 
 
62 
        <para>
63 
        <termdef><glossterm>Thread context</glossterm> represents state of the <emphasis>thread</emphasis>. Contains registers state, FPU state, stack(s).</termdef>
64 
        </para>
65 
 
66 
        <para>
67 
        <termdef><glossterm>Task</glossterm> </termdef>
68 
        </para>
69 
 
70 
 
71 
        <para>
72 
        <termdef>
73 
            <glossterm>Address space area</glossterm> is a mutually disjunctive range of memory with the code, stack and data.
74 
        </termdef>
75 
        </para>
76 
 
77 
        <para>
78 
        <termdef>
79 
            <glossterm>Address space</glossterm> is a aggregating entity for address space areas, connecting them to the task.
80 
        </termdef>
81 
        </para>             1
82 
    </section>
83 
 
84 
 
85 
 
86 
    <section>
87 
        <title>IPC</title>
88 
 
89 
        <para>
90 
            Due to the high intertask communication traffic, IPC becomes critical subsystem for microkernels, putting high demands on the
91 
            speed, latency and reliability of IPC model and implementation. HelenOS IPC is designed in analogy with telephone communication.
92 
            Each task has an <emphasis>answerbox</emphasis> and a set of <emphasis>phones</emphasis> to call another tasks' answerboxes. Communication
93 
            is possible after the link establishment, and can be either <emphasis>asynchronious</emphasis> or <emphasis>synchronious</emphasis>.
94 
         </para>
95 
 
96 
    </section>
97 
 
98 
 
99 
    <section>
16 bondari 100 
        <para>Task ID - unique 64 bit number. Used for syscalls.</para>
101 
        <para>Contains threads</para>
102 
        <para>Address space is created per task</para>
103 
        <para>Memory mapping is per task</para>
104 
        <para>Context per thread. (Note 2 stacks on IA64).</para>
105 
        <para>IPC answer box associated per task</para>
37 bondari 106 
 
107 
 
16 bondari 108 
        <title>Memory management</title>
109 
        <para>
110 
        Zones - linked list (not many zones, so we can afford it. Can be replaced with B-tree in the future)
111 
        Number of zones depends on HW tables. Describe zone allocation/deallocation algoritm
112 
        </para>
20 jermar 113 
        <para>Page tables. 4 level hierarchical and hash directly supported. B+ Tree can be implemented.</para>
16 bondari 114 
        <para>For paging there is an abstract layer</para>
115 
        <para>TLB shootdown implementation (update TLB upon mapping update/remove).
116 
        TLB shootdown ASID/ASID:PAGE/ALL.
117 
        TLB shootdown requests can come in asynchroniously
118 
        so there is a cache of TLB shootdown requests. Upon cache overflow TLB shootdown ALL is executed</para>
119 
 
120 
        <para>
121 
            Address spaces. Address space area (B+ tree). Only for uspace. Set of syscalls (shrink/extend etc).
122 
            Special address space area type - device - prohibits shrink/extend syscalls to call on it.
123 
            Address space has link to mapping tables (hierarchical - per Address space, hash - global tables).
124 
        </para>
20 jermar 125 
    </section>
11 bondari 126 
</chapter>
9 bondari 127