Rev 40 | Rev 48 | Go to most recent revision | Show entire file | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
Rev 40 | Rev 45 | ||
---|---|---|---|
Line 3... | Line 3... | ||
3 | <?dbhtml filename="arch.html"?> |
3 | <?dbhtml filename="arch.html"?> |
4 | 4 | ||
5 | <title>Architecture overview</title> |
5 | <title>Architecture overview</title> |
6 | 6 | ||
7 | <section> |
7 | <section> |
8 | <title>Scheme</title> |
8 | <para> |
9 | - | ||
10 | <para><mediaobject id="arch1"> |
9 | <mediaobject id="arch1"> |
11 | <imageobject role="html"> |
10 | <imageobject role="html"> |
12 | <imagedata fileref="images/arch1.png" format="PNG" /> |
11 | <imagedata fileref="images/arch1.png" format="PNG" /> |
13 | </imageobject> |
12 | </imageobject> |
14 | 13 | ||
15 | <imageobject role="fop"> |
14 | <imageobject role="fop"> |
16 | <imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
15 | <imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
17 | </imageobject> |
16 | </imageobject> |
18 | </mediaobject></para> |
17 | </mediaobject> |
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 incorporate set if its threads, provide common address space to its threads, |
- | |
33 | be an end-point in IPC.</termdef></para> |
- | |
34 | - | ||
35 | <para><termdef><glossterm>Address space area</glossterm> is a mutually |
- | |
36 | disjunctive range of memory with the code, stack and data. |
- | |
37 | </termdef></para> |
- | |
38 | - | ||
39 | <para><termdef><glossterm>Address space</glossterm> is a aggregating |
- | |
40 | entity for address space areas, connecting them to the task. |
- | |
41 | </termdef></para> |
- | |
42 | </section> |
- | |
43 | - | ||
44 | <section> |
- | |
45 | <title>Monolithic microkernel</title> |
- | |
46 | - | ||
47 | <para>Though HelenOS was initially planned as a microkernel, we were |
- | |
48 | trying to avoid several issues, connected with microkernels, such as much |
- | |
49 | higher overhead during memory management and hardware operations. For this |
- | |
50 | reason some of the subsystems, that are to be implemented as servers in |
- | |
51 | classic microkernel design, were implemented as a part of kernel, thus |
- | |
52 | minimizing this overhead.</para> |
- | |
53 | - | ||
54 | <formalpara> |
- | |
55 | <title>Memory management</title> |
- | |
56 | - | ||
57 | <para>HelenOS has all its memory |
- | |
58 | management functionality in the kernel, available to the memory |
- | |
59 | management server via the set of syscalls.</para> |
- | |
60 | </formalpara> |
- | |
61 | - | ||
62 | <formalpara> |
- | |
63 | <title>Kernel device drivers</title> |
- | |
64 | - | ||
65 | <para>HelenOS kernel has some of the very basic device drivers |
- | |
66 | <itemizedlist> |
- | |
67 | <listitem> |
- | |
68 | ACPI |
- | |
69 | </listitem> |
- | |
70 | - | ||
71 | <listitem> |
- | |
72 | APIC |
- | |
73 | </listitem> |
- | |
74 | - | ||
75 | <listitem> |
- | |
76 | SMP configuration |
- | |
77 | </listitem> |
- | |
78 | - | ||
79 | <listitem> |
- | |
80 | System clock |
- | |
81 | </listitem> |
- | |
82 | - | ||
83 | <listitem> |
- | |
84 | Interrupt controllers |
- | |
85 | </listitem> |
- | |
86 | - | ||
87 | <listitem> |
- | |
88 | Console and frame buffer |
- | |
89 | </listitem> |
- | |
90 | - | ||
91 | </itemizedlist></para> |
- | |
92 | </formalpara> |
18 | </para> |
93 | </section> |
- | |
94 | - | ||
95 | <section> |
- | |
96 | <title>IPC</title> |
- | |
97 | - | ||
98 | <para>HelenOS IPC is designed in analogy with telephone communication. |
- | |
99 | Each task has an <emphasis>answerbox</emphasis> and a set of |
- | |
100 | <emphasis>phones</emphasis> to call another tasks' answerboxes.</para> |
- | |
101 | - | ||
102 | <para>Communication is possible after the connection is established, and |
- | |
103 | can be either <emphasis>asynchronious</emphasis> or |
- | |
104 | <emphasis>synchronious</emphasis>.</para> |
- | |
105 | </section> |
19 | </section> |
106 | 20 | ||
107 | <section> |
21 | <section> |
108 | <title>Functionality model</title> |
- | |
109 | - | ||
110 | <para>As you know, microkernel design is very simple, just enough to |
22 | <para>The HelenOS operating system is designed as a relatively small |
111 | provide communication facility for tasks. Most of the OS functionality is |
23 | microkernel assisted with a set of userspace drivers and server tasks. |
112 | performed by server tasks, that are running in userspace. Thus most of the |
24 | HelenOS is not very radical in what subsystems should or should not be |
113 | system calls in monolithic kernels, are the IPC calls on server tasks in |
25 | implemented in the kernel - in some cases, both kernel and userspace |
114 | microkernels.</para> |
- | |
115 | - | ||
116 | <para>Moreover, problems experience the device drivers. Running in the |
26 | drivers exist. The reason for creating the system as a microkernel is |
117 | user space, device driver still needs to recieve interrupts and access |
27 | prosaic. Even though it is initially more difficult to get the same level |
118 | hardware directly.</para> |
- | |
119 | - | ||
120 | <para>This raises two major problems in microkernels: <orderedlist |
28 | of functionality from a microkernel than it is in the case of a simple |
121 | numeration="loweralpha"> |
29 | monolithic kernel, a microkernel is much easier to maintain once the |
122 | <listitem> |
- | |
123 | What is the recipient address of the server (e.g. "memory manager" or a specific device driver) ? |
30 | pieces have been put to work together. Therefore, the kernel of HelenOS, |
124 | </listitem> |
- | |
125 | - | ||
126 | <listitem> |
- | |
127 | How this server task is going to access hardware or kernel while running in the user mode? |
31 | as well as the essential userspace libraries thereof can be maintained by |
128 | </listitem> |
- | |
129 | </orderedlist></para> |
- | |
130 | - | ||
131 | <formalpara id="intro_ns"> |
- | |
132 | <title>Name server</title> |
32 | only a few developers who understand them completely. In addition, a |
133 | - | ||
134 | <para>As every microkernel, HelenOS has a "Name server" task with "well |
33 | microkernel based operating system reaches completion sooner than |
135 | known" IPC address, that connects user task to any server just by the |
34 | monolithic kernels as the system can be used even without some traditional |
136 | string service indentification.</para> |
35 | subsystems (e.g. block devices, filesystems and networking).</para> |
137 | </formalpara> |
- | |
138 | 36 | ||
139 | <formalpara id="intro_ddi"> |
- | |
140 | <title>Device driver interface</title> |
37 | <para>HelenOS is comprised of the kernel and userspace server tasks. The |
141 | - | ||
142 | <para>Device drivers use special syscalls to map physical memory areas |
38 | kernel provides scheduling, memory management and IPC. It also contains |
143 | into their address space, to map port regions (mostly ia32). Interrupts |
39 | essential device drivers that control the system clock and other devices |
144 | are delivered to the device driver task by the standard IPC |
40 | necessary to guarantee a safe environment. Userspace communicates with the |
145 | means.</para> |
41 | kernel through </para> |
146 | </formalpara> |
- | |
147 | </section> |
42 | </section> |
148 | </chapter> |
43 | </chapter> |
149 | 44 |