Rev 72 | Rev 87 | Go to most recent revision | Only display areas with differences | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
Rev 72 | Rev 77 | ||
---|---|---|---|
1 | <?xml version="1.0" encoding="UTF-8"?> |
1 | <?xml version="1.0" encoding="UTF-8"?> |
2 | <chapter id="architecture"> |
2 | <chapter id="architecture"> |
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 | <para>The HelenOS operating system is designed as a relatively small |
7 | <para>The HelenOS operating system is designed as a relatively small |
8 | microkernel assisted with a set of userspace drivers and server tasks. |
8 | microkernel assisted with a set of userspace drivers and server tasks. |
9 | HelenOS is not very radical in what subsystems should or should not be |
9 | HelenOS is not very radical in what subsystems should or should not be |
10 | implemented in the kernel - in some cases, both kernel and userspace drivers |
10 | implemented in the kernel - in some cases, both kernel and userspace drivers |
11 | exist. The reason for creating the system as a microkernel is prosaic. Even |
11 | exist. The reason for creating the system as a microkernel is prosaic. Even |
12 | though it is initially more difficult to get the same level of functionality |
12 | though it is initially more difficult to get the same level of functionality |
13 | from a microkernel than it is in the case of a simple monolithic kernel, a |
13 | from a microkernel than it is in the case of a simple monolithic kernel, a |
14 | microkernel is much easier to maintain once the pieces have been put to work |
14 | microkernel is much easier to maintain once the pieces have been put to work |
15 | together. Therefore, the kernel of HelenOS, as well as the essential |
15 | together. Therefore, the kernel of HelenOS, as well as the essential |
16 | userspace libraries thereof can be maintained by only a few developers who |
16 | userspace libraries thereof can be maintained by only a few developers who |
17 | understand them completely. In addition, a microkernel based operating |
17 | understand them completely. In addition, a microkernel based operating |
18 | system reaches completion sooner than monolithic kernels as the system can |
18 | system reaches completion sooner than monolithic kernels as the system can |
19 | be used even without some traditional subsystems (e.g. block devices, |
19 | be used even without some traditional subsystems (e.g. block devices, |
20 | filesystems and networking).</para> |
20 | filesystems and networking).</para> |
21 | 21 | ||
22 | <figure> |
22 | <figure> |
23 | <mediaobject id="arch1" xreflabel=""> |
23 | <mediaobject id="arch1" xreflabel=""> |
- | 24 | <imageobject role="eps"> |
|
- | 25 | <imagedata fileref="images.vector/arch1.eps" format="EPS" scale="100" /> |
|
- | 26 | </imageobject> |
|
- | 27 | ||
24 | <imageobject role="html"> |
28 | <imageobject role="html"> |
25 | <imagedata fileref="images/arch1.png" format="PNG" /> |
29 | <imagedata fileref="images/arch1.png" format="PNG" /> |
26 | </imageobject> |
30 | </imageobject> |
27 | 31 | ||
28 | <imageobject role="fop"> |
32 | <imageobject role="fop"> |
29 | <imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
33 | <imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
30 | </imageobject> |
34 | </imageobject> |
31 | </mediaobject> |
35 | </mediaobject> |
32 | 36 | ||
33 | <title>HelenOS architecture overview.</title> |
37 | <title>HelenOS architecture overview.</title> |
34 | </figure> |
38 | </figure> |
35 | 39 | ||
36 | <para>HelenOS is comprised of the kernel and the userspace server tasks. The |
40 | <para>HelenOS is comprised of the kernel and the userspace server tasks. The |
37 | kernel provides scheduling, memory management and IPC. It also contains |
41 | kernel provides scheduling, memory management and IPC. It also contains |
38 | essential device drivers that control the system clock and other devices |
42 | essential device drivers that control the system clock and other devices |
39 | necessary to guarantee a safe environment. Userspace communicates with the |
43 | necessary to guarantee a safe environment. Userspace communicates with the |
40 | kernel through a small set of syscalls. The userspace layer consists of |
44 | kernel through a small set of syscalls. The userspace layer consists of |
41 | tasks with different roles, capabilities and privileges. Some of the tasks |
45 | tasks with different roles, capabilities and privileges. Some of the tasks |
42 | serve as device drivers, naming servers, managers of various kinds and some |
46 | serve as device drivers, naming servers, managers of various kinds and some |
43 | are just ordinary user programs. All of them communicate with other threads |
47 | are just ordinary user programs. All of them communicate with other threads |
44 | via kernel-provided IPC.</para> |
48 | via kernel-provided IPC.</para> |
45 | 49 | ||
46 | <section> |
50 | <section> |
47 | <title>Scheduling</title> |
51 | <title>Scheduling</title> |
48 | 52 | ||
49 | <indexterm> |
53 | <indexterm> |
50 | <primary>thread</primary> |
54 | <primary>thread</primary> |
51 | </indexterm> |
55 | </indexterm> |
52 | 56 | ||
53 | <para>Kernel's unit of execution flow is a thread. A thread is an entity |
57 | <para>Kernel's unit of execution flow is a thread. A thread is an entity |
54 | that executes code and has a stack that takes up some space in memory. The |
58 | that executes code and has a stack that takes up some space in memory. The |
55 | relation between kernel and userspace threads is 1:1:n, meaning that there |
59 | relation between kernel and userspace threads is 1:1:n, meaning that there |
56 | can be several pseudo threads running within one userspace thread that |
60 | can be several pseudo threads running within one userspace thread that |
57 | maps to one kernel thread. Threads are grouped into tasks by functionality |
61 | maps to one kernel thread. Threads are grouped into tasks by functionality |
58 | they provide (i.e. several threads implement functionality of one task). |
62 | they provide (i.e. several threads implement functionality of one task). |
59 | <indexterm> |
63 | <indexterm> |
60 | <primary>task</primary> |
64 | <primary>task</primary> |
61 | </indexterm> Tasks serve as containers of threads, they provide linkage |
65 | </indexterm> Tasks serve as containers of threads, they provide linkage |
62 | to address space and are communication endpoints for IPC. Finally, tasks |
66 | to address space and are communication endpoints for IPC. Finally, tasks |
63 | can be holders of capabilities that entitle them to do certain sensitive |
67 | can be holders of capabilities that entitle them to do certain sensitive |
64 | operations (e.g access raw hardware and physical memory).</para> |
68 | operations (e.g access raw hardware and physical memory).</para> |
65 | 69 | ||
66 | <para>The scheduler deploys several run queues on each processor. A thread |
70 | <para>The scheduler deploys several run queues on each processor. A thread |
67 | ready for execution is put into one of the run queues, depending on its |
71 | ready for execution is put into one of the run queues, depending on its |
68 | priority and its current processor, from where it is eventually picked up |
72 | priority and its current processor, from where it is eventually picked up |
69 | by the scheduler. Special purpose kernel threads strive to keep processors |
73 | by the scheduler. Special purpose kernel threads strive to keep processors |
70 | balanced by thread migration. Threads are scheduled by the round robing |
74 | balanced by thread migration. Threads are scheduled by the round robing |
71 | scheduling policy with respect to multiple priority run queues.</para> |
75 | scheduling policy with respect to multiple priority run queues.</para> |
72 | </section> |
76 | </section> |
73 | 77 | ||
74 | <section> |
78 | <section> |
75 | <title>Memory management</title> |
79 | <title>Memory management</title> |
76 | 80 | ||
77 | <para>Memory management is another large subsystem in HelenOS. It serves |
81 | <para>Memory management is another large subsystem in HelenOS. It serves |
78 | the kernel to satisfy its own memory allocation requests, provides |
82 | the kernel to satisfy its own memory allocation requests, provides |
79 | translation between virtual and physical memory addresses and manages |
83 | translation between virtual and physical memory addresses and manages |
80 | virtual address spaces of userspace tasks.</para> |
84 | virtual address spaces of userspace tasks.</para> |
81 | 85 | ||
82 | <para>Kernel allocates memory from the slab allocator, which itself |
86 | <para>Kernel allocates memory from the slab allocator, which itself |
83 | allocates memory from a buddy system based allocator of physical memory |
87 | allocates memory from a buddy system based allocator of physical memory |
84 | frames.</para> |
88 | frames.</para> |
85 | 89 | ||
86 | <para>The virtual address translation layer currently supports two |
90 | <para>The virtual address translation layer currently supports two |
87 | mechanisms for mapping virtual memory pages to physical memory frames |
91 | mechanisms for mapping virtual memory pages to physical memory frames |
88 | (i.e. 4-level hierarchical page tables and global page hash table), and is |
92 | (i.e. 4-level hierarchical page tables and global page hash table), and is |
89 | further extensible to other mechanisms.</para> |
93 | further extensible to other mechanisms.</para> |
90 | 94 | ||
91 | <indexterm> |
95 | <indexterm> |
92 | <primary>address space</primary> |
96 | <primary>address space</primary> |
93 | </indexterm> |
97 | </indexterm> |
94 | 98 | ||
95 | <para>Userspace tasks depend on support of address spaces provided by the |
99 | <para>Userspace tasks depend on support of address spaces provided by the |
96 | kernel. Each address space is a set of mutually dijunctive address space |
100 | kernel. Each address space is a set of mutually dijunctive address space |
97 | areas that group pages of common attributes. An address space area is |
101 | areas that group pages of common attributes. An address space area is |
98 | usually connected to, and backed by, anonymous memory, executable image of |
102 | usually connected to, and backed by, anonymous memory, executable image of |
99 | some program or continuous region of physical memory. However, swapping |
103 | some program or continuous region of physical memory. However, swapping |
100 | pages in and out to external memory is not supported. Address space areas |
104 | pages in and out to external memory is not supported. Address space areas |
101 | can be easily shared among address spaces.</para> |
105 | can be easily shared among address spaces.</para> |
102 | </section> |
106 | </section> |
103 | 107 | ||
104 | <section> |
108 | <section> |
105 | <indexterm> |
109 | <indexterm> |
106 | <primary>IPC</primary> |
110 | <primary>IPC</primary> |
107 | </indexterm> |
111 | </indexterm> |
108 | 112 | ||
109 | <title>IPC</title> |
113 | <title>IPC</title> |
110 | 114 | ||
111 | <para>Due to the fact that HelenOS is a microkernel, strong emphasis is |
115 | <para>Due to the fact that HelenOS is a microkernel, strong emphasis is |
112 | put on its IPC (Inter-Process Communication<footnote> |
116 | put on its IPC (Inter-Process Communication<footnote> |
113 | <para>The term Inter-Process Communication is slightly confusing |
117 | <para>The term Inter-Process Communication is slightly confusing |
114 | because in HelenOS terminology there are tasks instead of processes. |
118 | because in HelenOS terminology there are tasks instead of processes. |
115 | However, its abbreviation, IPC, is being publicly used as a standard |
119 | However, its abbreviation, IPC, is being publicly used as a standard |
116 | name for similar facilities. This book will therefore use the term IPC |
120 | name for similar facilities. This book will therefore use the term IPC |
117 | to refer to communication among tasks.</para> |
121 | to refer to communication among tasks.</para> |
118 | </footnote>). Tasks communicate by passing very short messages to one |
122 | </footnote>). Tasks communicate by passing very short messages to one |
119 | another or by sending (i.e. sharing) address space areas when larger data |
123 | another or by sending (i.e. sharing) address space areas when larger data |
120 | is to be transfered.</para> |
124 | is to be transfered.</para> |
121 | 125 | ||
122 | <indexterm> |
126 | <indexterm> |
123 | <primary>IPC</primary> |
127 | <primary>IPC</primary> |
124 | 128 | ||
125 | <secondary>- phone</secondary> |
129 | <secondary>- phone</secondary> |
126 | </indexterm> |
130 | </indexterm> |
127 | 131 | ||
128 | <indexterm> |
132 | <indexterm> |
129 | <primary>IPC</primary> |
133 | <primary>IPC</primary> |
130 | 134 | ||
131 | <secondary>- answerbox</secondary> |
135 | <secondary>- answerbox</secondary> |
132 | </indexterm> |
136 | </indexterm> |
133 | 137 | ||
134 | <indexterm> |
138 | <indexterm> |
135 | <primary>IPC</primary> |
139 | <primary>IPC</primary> |
136 | 140 | ||
137 | <secondary>- message queue</secondary> |
141 | <secondary>- message queue</secondary> |
138 | </indexterm> |
142 | </indexterm> |
139 | 143 | ||
140 | <para>The abstraction uses terms like phones, calls and answerboxes, but |
144 | <para>The abstraction uses terms like phones, calls and answerboxes, but |
141 | is pretty similar to well-known abstraction of message queues. A task can |
145 | is pretty similar to well-known abstraction of message queues. A task can |
142 | have multiple simultaneous simplex connections to several other tasks. A |
146 | have multiple simultaneous simplex connections to several other tasks. A |
143 | connection leads from one of the source task's phones to the destination |
147 | connection leads from one of the source task's phones to the destination |
144 | task's answerbox. The phones are used as handles for making calls to other |
148 | task's answerbox. The phones are used as handles for making calls to other |
145 | tasks. Calls can be synchronous or asynchronous and can be forwarded from |
149 | tasks. Calls can be synchronous or asynchronous and can be forwarded from |
146 | one task to another.</para> |
150 | one task to another.</para> |
147 | </section> |
151 | </section> |
148 | </chapter> |
152 | </chapter> |