Rev 37 | Rev 39 | 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> |
38 | bondari | 21 | <title>Kernel primitives</title> |
22 | <para> |
||
23 | <termdef><glossterm>Thread</glossterm> is the basic execution primitive.</termdef> |
||
24 | </para> |
||
25 | |||
26 | <para> |
||
27 | <termdef><glossterm>Thread context</glossterm> represents state of the <emphasis>thread</emphasis>. |
||
28 | Thread context is built of the context registers contents, FPU state and the stack.</termdef> |
||
29 | </para> |
||
30 | |||
31 | <para> |
||
32 | <termdef> |
||
33 | <glossterm>Task</glossterm> is a multi-purpose entity, serving to |
||
34 | <itemizedlist> |
||
35 | <listitem>incorporate set if its threads</listitem> |
||
36 | <listitem>provide common address space to its threads</listitem> |
||
37 | <listitem>be an end-point in IPC</listitem> |
||
38 | </itemizedlist> |
||
39 | |||
40 | </termdef> |
||
41 | </para> |
||
42 | |||
43 | <para> |
||
44 | <termdef> |
||
45 | <glossterm>Address space area</glossterm> is a mutually disjunctive range of memory with the code, stack and data. |
||
46 | </termdef> |
||
47 | </para> |
||
48 | |||
49 | <para> |
||
50 | <termdef> |
||
51 | <glossterm>Address space</glossterm> is a aggregating entity for address space areas, connecting them to the task. |
||
52 | </termdef> |
||
53 | </para> |
||
54 | </section> |
||
55 | |||
56 | <section> |
||
37 | bondari | 57 | <title>Monolithic microkernel</title> |
58 | <para> |
||
38 | bondari | 59 | Though HelenOS was initially planned as a microkernel, we were trying to avoid several issues, connected |
37 | bondari | 60 | with microkernels, such as much higher overhead during memory management and hardware operations. For this reason |
38 | bondari | 61 | some of the subsystems, that are to be implemented as servers in classic microkernel design, were implemented |
37 | bondari | 62 | as a part of kernel, thus minimizing this overhead. |
63 | </para> |
||
64 | |||
65 | <formalpara> |
||
66 | <title>Memory management</title> |
||
67 | <para> |
||
68 | Unlike the classic microkernel, HelenOS has all its memory management functionality in the kernel, available to the memory |
||
69 | management server via the set of syscalls. |
||
70 | </para> |
||
71 | </formalpara> |
||
72 | |||
73 | <formalpara> |
||
74 | <title>Kernel device drivers</title> |
||
75 | <para> |
||
76 | HelenOS kernel has some of the very basic device drivers |
||
77 | <itemizedlist> |
||
78 | <listitem>ACPI</listitem> |
||
79 | <listitem>APIC</listitem> |
||
80 | <listitem>SMP configuration</listitem> |
||
81 | <listitem>System clock</listitem> |
||
82 | <listitem>Interrupt controllers</listitem> |
||
83 | <listitem>Console</listitem> |
||
84 | <listitem>VESA & frame buffer</listitem> |
||
85 | </itemizedlist> |
||
86 | |||
87 | </para> |
||
88 | </formalpara> |
||
89 | |||
90 | </section> |
||
91 | |||
92 | <section> |
||
38 | bondari | 93 | <title>IPC</title> |
37 | bondari | 94 | |
38 | bondari | 95 | <para>HelenOS IPC is designed in analogy with telephone communication. |
96 | Each task has an <emphasis>answerbox</emphasis> and a set of <emphasis>phones</emphasis> to call another tasks' answerboxes. |
||
37 | bondari | 97 | </para> |
38 | bondari | 98 | |
99 | <para>Communication |
||
100 | is possible after the connection is established, and can be either <emphasis>asynchronious</emphasis> or <emphasis>synchronious</emphasis>. |
||
37 | bondari | 101 | </para> |
38 | bondari | 102 | |
37 | bondari | 103 | </section> |
104 | |||
105 | <section> |
||
38 | bondari | 106 | <title>Functionality model</title> |
37 | bondari | 107 | |
16 | bondari | 108 | <para> |
38 | bondari | 109 | As you know, microkernel design is very simple, just enough to provide communication facility for tasks. Most of the OS functionality |
110 | is performed by server tasks, that are running in userspace. |
||
111 | Thus most of the system calls in monolithic kernels, are the IPC calls on server tasks in microkernels. |
||
16 | bondari | 112 | </para> |
113 | |||
114 | <para> |
||
38 | bondari | 115 | Moreover, problems experience the device drivers. Running in the user space, device driver still needs to recieve interrupts |
116 | and access hardware directly. |
||
16 | bondari | 117 | </para> |
38 | bondari | 118 | |
119 | <para> |
||
120 | This raises two major problems in microkernels: |
||
121 | |||
122 | <orderedlist numeration="loweralpha"> |
||
123 | <listitem>What is the recipient address of the server (e.g. "memory manager" or a specific device driver) ?</listitem> |
||
124 | <listitem>How this server task is going to access hardware or kernel while running in the user mode?</listitem> |
||
125 | </orderedlist> |
||
126 | |||
127 | </para> |
||
128 | |||
129 | |||
130 | <formalpara id="intro_ns"> |
||
131 | <title>Name server</title> |
||
132 | <para>As every microkernel, HelenOS has a "Name server" task with "well known" IPC address, that connects user task to any server |
||
133 | just by the string service indentification.</para> |
||
134 | </formalpara> |
||
135 | |||
136 | |||
137 | <formalpara id="intro_ddi"> |
||
138 | <title>Device driver interface</title> |
||
139 | <para>Device drivers use special syscalls to map physical memory areas into their address space, to map port regions (mostly ia32). |
||
140 | Interrupts are delivered to the device driver task by the standard IPC means. |
||
141 | </para> |
||
142 | </formalpara> |
||
143 | |||
20 | jermar | 144 | </section> |
38 | bondari | 145 | |
146 | |||
147 | |||
148 | |||
11 | bondari | 149 | </chapter> |
9 | bondari | 150 |