Rev 138 | Only display areas with differences | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
Rev 138 | Rev 171 | ||
---|---|---|---|
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 which subsystems should or should not be |
9 | HelenOS is not very radical in which 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 float="1"> |
22 | <figure float="1"> |
23 | <mediaobject id="arch1"> |
23 | <mediaobject id="arch1"> |
24 | <imageobject role="pdf"> |
24 | <imageobject role="pdf"> |
25 | <imagedata fileref="images/arch1.pdf" format="PDF" /> |
25 | <imagedata fileref="images/arch1.pdf" format="PDF" /> |
26 | </imageobject> |
26 | </imageobject> |
27 | 27 | ||
28 | <imageobject role="html"> |
28 | <imageobject role="html"> |
29 | <imagedata fileref="images/arch1.png" format="PNG" /> |
29 | <imagedata fileref="images/arch1.png" format="PNG" /> |
30 | </imageobject> |
30 | </imageobject> |
31 | 31 | ||
32 | <imageobject role="fop"> |
32 | <imageobject role="fop"> |
33 | <imagedata fileref="images/arch1.svg" format="SVG" /> |
33 | <imagedata fileref="images/arch1.svg" format="SVG" /> |
34 | </imageobject> |
34 | </imageobject> |
35 | </mediaobject> |
35 | </mediaobject> |
36 | 36 | ||
37 | <title>HelenOS architecture overview.</title> |
37 | <title>HelenOS architecture overview.</title> |
38 | </figure> |
38 | </figure> |
39 | 39 | ||
40 | <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 |
41 | kernel provides scheduling, memory management and IPC. It also contains |
41 | kernel provides scheduling, memory management and IPC. It also contains |
42 | essential device drivers that control the system clock and other devices |
42 | essential device drivers that control the system clock and other devices |
43 | necessary to guarantee a safe environment. Userspace communicates with the |
43 | necessary to guarantee a safe environment. Userspace communicates with the |
44 | 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 |
45 | tasks with different roles, capabilities and privileges. Some of the tasks |
45 | tasks with different roles, capabilities and privileges. Some of the tasks |
46 | 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 |
47 | 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 |
48 | via kernel-provided IPC.</para> |
48 | via kernel-provided IPC.</para> |
49 | 49 | ||
50 | <section> |
50 | <section> |
51 | <title>Scheduling</title> |
51 | <title>Scheduling</title> |
52 | 52 | ||
53 | <indexterm> |
53 | <indexterm> |
54 | <primary>thread</primary> |
54 | <primary>thread</primary> |
55 | </indexterm> |
55 | </indexterm> |
56 | 56 | ||
57 | <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 |
58 | 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 |
59 | 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 |
60 | can be several pseudo threads running within one userspace thread that |
60 | can be several so called fibrils running within one userspace thread that |
61 | 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 |
62 | they provide (i.e. several threads implement functionality of one task). |
62 | they provide (i.e. several threads implement functionality of one task). |
63 | <indexterm> |
63 | <indexterm> |
64 | <primary>task</primary> |
64 | <primary>task</primary> |
65 | </indexterm> Tasks serve as containers of threads, they provide linkage |
65 | </indexterm> Tasks serve as containers of threads, they provide linkage |
66 | to address space and are communication endpoints for IPC. Finally, tasks |
66 | to address space and are communication endpoints for IPC. Finally, tasks |
67 | 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 |
68 | operations (e.g access raw hardware and physical memory).</para> |
68 | operations (e.g access raw hardware and physical memory).</para> |
69 | 69 | ||
70 | <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 |
71 | 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 |
72 | 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 |
73 | by the scheduler. Special purpose kernel threads strive to keep processors |
73 | by the scheduler. Special purpose kernel threads strive to keep processors |
74 | balanced by thread migration. Threads are scheduled by the round robing |
74 | balanced by thread migration. Threads are scheduled by the round robing |
75 | scheduling policy with respect to multiple priority run queues.</para> |
75 | scheduling policy with respect to multiple priority run queues.</para> |
76 | </section> |
76 | </section> |
77 | 77 | ||
78 | <section> |
78 | <section> |
79 | <title>Memory Management</title> |
79 | <title>Memory Management</title> |
80 | 80 | ||
81 | <para>Memory management is another large subsystem in HelenOS. It serves |
81 | <para>Memory management is another large subsystem in HelenOS. It serves |
82 | the kernel to satisfy its own memory allocation requests, provides |
82 | the kernel to satisfy its own memory allocation requests, provides |
83 | translation between virtual and physical memory addresses and manages |
83 | translation between virtual and physical memory addresses and manages |
84 | virtual address spaces of userspace tasks.</para> |
84 | virtual address spaces of userspace tasks.</para> |
85 | 85 | ||
86 | <para>Kernel allocates memory from the slab allocator, which itself |
86 | <para>Kernel allocates memory from the slab allocator, which itself |
87 | allocates memory from a buddy system based allocator of physical memory |
87 | allocates memory from a buddy system based allocator of physical memory |
88 | frames.</para> |
88 | frames.</para> |
89 | 89 | ||
90 | <para>The virtual address translation layer currently supports two |
90 | <para>The virtual address translation layer currently supports two |
91 | mechanisms for mapping virtual memory pages to physical memory frames |
91 | mechanisms for mapping virtual memory pages to physical memory frames |
92 | (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 |
93 | further extensible to other mechanisms.</para> |
93 | further extensible to other mechanisms.</para> |
94 | 94 | ||
95 | <indexterm> |
95 | <indexterm> |
96 | <primary>address space</primary> |
96 | <primary>address space</primary> |
97 | </indexterm> |
97 | </indexterm> |
98 | 98 | ||
99 | <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 |
100 | kernel. Each address space is a set of mutually disjunctive address space |
100 | kernel. Each address space is a set of mutually disjunctive address space |
101 | areas. An address space area is usually connected to, and backed by, |
101 | areas. An address space area is usually connected to, and backed by, |
102 | anonymous memory, executable image of some program or continuous region of |
102 | anonymous memory, executable image of some program or continuous region of |
103 | physical memory. However, swapping pages in and out to external memory is |
103 | physical memory. However, swapping pages in and out to external memory is |
104 | not supported. Address space areas can be easily shared among address |
104 | not supported. Address space areas can be easily shared among address |
105 | spaces.</para> |
105 | spaces.</para> |
106 | </section> |
106 | </section> |
107 | 107 | ||
108 | <section> |
108 | <section> |
109 | <indexterm> |
109 | <indexterm> |
110 | <primary>IPC</primary> |
110 | <primary>IPC</primary> |
111 | </indexterm> |
111 | </indexterm> |
112 | 112 | ||
113 | <title>IPC</title> |
113 | <title>IPC</title> |
114 | 114 | ||
115 | <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 |
116 | put on its IPC (Inter-Process Communication<footnote> |
116 | put on its IPC (Inter-Process Communication<footnote> |
117 | <para>The term Inter-Process Communication is slightly confusing |
117 | <para>The term Inter-Process Communication is slightly confusing |
118 | because in HelenOS terminology there are tasks instead of processes. |
118 | because in HelenOS terminology there are tasks instead of processes. |
119 | However, its abbreviation, IPC, is being publicly used as a standard |
119 | However, its abbreviation, IPC, is being publicly used as a standard |
120 | 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 |
121 | to refer to communication among tasks.</para> |
121 | to refer to communication among tasks.</para> |
122 | </footnote>). Tasks communicate by passing very short messages to one |
122 | </footnote>). Tasks communicate by passing very short messages to one |
123 | 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 |
124 | is to be transfered.</para> |
124 | is to be transfered.</para> |
125 | 125 | ||
126 | <indexterm> |
126 | <indexterm> |
127 | <primary>IPC</primary> |
127 | <primary>IPC</primary> |
128 | 128 | ||
129 | <secondary>- phone</secondary> |
129 | <secondary>- phone</secondary> |
130 | </indexterm> |
130 | </indexterm> |
131 | 131 | ||
132 | <indexterm> |
132 | <indexterm> |
133 | <primary>IPC</primary> |
133 | <primary>IPC</primary> |
134 | 134 | ||
135 | <secondary>- answerbox</secondary> |
135 | <secondary>- answerbox</secondary> |
136 | </indexterm> |
136 | </indexterm> |
137 | 137 | ||
138 | <indexterm> |
138 | <indexterm> |
139 | <primary>IPC</primary> |
139 | <primary>IPC</primary> |
140 | 140 | ||
141 | <secondary>- message queue</secondary> |
141 | <secondary>- message queue</secondary> |
142 | </indexterm> |
142 | </indexterm> |
143 | 143 | ||
144 | <para>The abstraction uses terms like phones, calls and answerboxes, but |
144 | <para>The abstraction uses terms like phones, calls and answerboxes, but |
145 | is similar to well-known abstraction of message queues. A task can have |
145 | is similar to well-known abstraction of message queues. A task can have |
146 | multiple simultaneous simplex connections to several other tasks. A |
146 | multiple simultaneous simplex connections to several other tasks. A |
147 | 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 |
148 | 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 |
149 | tasks. Calls are asynchronous and can be forwarded from one task to |
149 | tasks. Calls are asynchronous and can be forwarded from one task to |
150 | another.</para> |
150 | another.</para> |
151 | </section> |
151 | </section> |
152 | </chapter> |
152 | </chapter> |