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