Rev 49 | Rev 52 | Go to most recent revision | Only display areas with differences | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
Rev 49 | Rev 50 | ||
---|---|---|---|
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 | <para><mediaobject id="arch1" xreflabel=""> |
22 | <para><mediaobject id="arch1" xreflabel=""> |
23 | <imageobject role="html"> |
23 | <imageobject role="html"> |
24 | <imagedata fileref="images/arch1.png" format="PNG" /> |
24 | <imagedata fileref="images/arch1.png" format="PNG" /> |
25 | </imageobject> |
25 | </imageobject> |
26 | 26 | ||
27 | <imageobject role="fop"> |
27 | <imageobject role="fop"> |
28 | <imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
28 | <imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
29 | </imageobject> |
29 | </imageobject> |
30 | 30 | ||
31 | <caption>HelenOS architecture overview</caption> |
31 | <caption>HelenOS architecture overview</caption> |
32 | </mediaobject></para> |
32 | </mediaobject></para> |
33 | 33 | ||
34 | <para>HelenOS is comprised of the kernel and userspace server tasks. The |
34 | <para>HelenOS is comprised of the kernel and userspace server tasks. The |
35 | kernel provides scheduling, memory management and IPC. It also contains |
35 | kernel provides scheduling, memory management and IPC. It also contains |
36 | essential device drivers that control the system clock and other devices |
36 | essential device drivers that control the system clock and other devices |
37 | necessary to guarantee a safe environment. Userspace communicates with the |
37 | necessary to guarantee a safe environment. Userspace communicates with the |
38 | kernel through a small set of syscalls. The userspace layer consists of |
38 | kernel through a small set of syscalls. The userspace layer consists of |
39 | tasks with different roles, capabilities and privileges. Some of the tasks |
39 | tasks with different roles, capabilities and privileges. Some of the tasks |
40 | serve as device drivers, naming servers, managers of various kinds and some |
40 | serve as device drivers, naming servers, managers of various kinds and some |
41 | are just ordinary user programs. All of them communicate with other threads |
41 | are just ordinary user programs. All of them communicate with other threads |
42 | via kernel-provided IPC.</para> |
42 | via kernel-provided IPC.</para> |
43 | 43 | ||
44 | <section> |
44 | <section> |
45 | <title>Scheduling</title> |
45 | <title>Scheduling</title> |
46 | 46 | ||
47 | <para>Kernel's unit of execution flow is a thread. A thread is an entity |
47 | <para>Kernel's unit of execution flow is a thread. A thread is an entity |
48 | that executes code and has a stack that takes up some space in memory. The |
48 | that executes code and has a stack that takes up some space in memory. The |
49 | relation between kernel and userspace threads is 1:1:n, meaning that there |
49 | relation between kernel and userspace threads is 1:1:n, meaning that there |
50 | can be several pseudo threads running within one userspace thread that |
50 | can be several pseudo threads running within one userspace thread that |
51 | maps to one kernel thread. Threads are grouped into tasks by functionality |
51 | maps to one kernel thread. Threads are grouped into tasks by functionality |
52 | they provide (i.e. several threads implement functionality of one task). |
52 | they provide (i.e. several threads implement functionality of one task). |
53 | Tasks serve as containers of threads, they provide linkage to address |
53 | Tasks serve as containers of threads, they provide linkage to address |
54 | space and are communication endpoints for IPC.</para> |
54 | space and are communication endpoints for IPC.</para> |
55 | 55 | ||
56 | <para>The scheduler deploys several run queues on each processor. A thread |
56 | <para>The scheduler deploys several run queues on each processor. A thread |
57 | ready for execution is put into one of the run queues, depending on its |
57 | ready for execution is put into one of the run queues, depending on its |
58 | priority and its current processor, from where it is eventually picked up |
58 | priority and its current processor, from where it is eventually picked up |
59 | by the scheduler. Special purpose kernel threads strive to keep processors |
59 | by the scheduler. Special purpose kernel threads strive to keep processors |
60 | balanced by thread migration. Threads are scheduled by the round robing |
60 | balanced by thread migration. Threads are scheduled by the round robing |
61 | scheduling policy with respect to multiple priority run queues.</para> |
61 | scheduling policy with respect to multiple priority run queues.</para> |
62 | </section> |
62 | </section> |
63 | 63 | ||
64 | <section> |
64 | <section> |
65 | <title>Memory management</title> |
65 | <title>Memory management</title> |
66 | 66 | ||
67 | <para>Memory management is another large subsystem in HelenOS. It serves |
67 | <para>Memory management is another large subsystem in HelenOS. It serves |
68 | the kernel to satisfy its own memory allocation requests, provides |
68 | the kernel to satisfy its own memory allocation requests, provides |
69 | translation between virtual and physical memory addresses and manages |
69 | translation between virtual and physical memory addresses and manages |
70 | virtual address spaces of userspace tasks.</para> |
70 | virtual address spaces of userspace tasks.</para> |
71 | 71 | ||
72 | <para>Kernel allocates memory from the slab allocator, which itself |
72 | <para>Kernel allocates memory from the slab allocator, which itself |
73 | allocates memory from a buddy system based allocator of physical memory |
73 | allocates memory from a buddy system based allocator of physical memory |
74 | frames.</para> |
74 | frames.</para> |
75 | 75 | ||
76 | <para>The virtual address translation layer currently supports two |
76 | <para>The virtual address translation layer currently supports two |
77 | mechanisms for mapping virtual memory pages to physical memory frames |
77 | mechanisms for mapping virtual memory pages to physical memory frames |
78 | (i.e. 4-level hierarchical page tables and global page hash table), and is |
78 | (i.e. 4-level hierarchical page tables and global page hash table), and is |
79 | further extensible to other mechanisms.</para> |
79 | further extensible to other mechanisms.</para> |
80 | 80 | ||
81 | <para>Userspace tasks depend on support of address spaces provided by the |
81 | <para>Userspace tasks depend on support of address spaces provided by the |
82 | kernel. Each address space is a set of mutually dijunctive address space |
82 | kernel. Each address space is a set of mutually dijunctive address space |
83 | areas that group pages of common attributes. An address space area is |
83 | areas that group pages of common attributes. An address space area is |
84 | usually connected to, and backed by, an anonymous memory or an executable |
84 | usually connected to, and backed by, anonymous memory, executable image of |
- | 85 | some program or continuous region of physical memory. However, swapping |
|
85 | image of some program. Anonymous memory address space areas can be easily |
86 | pages in and out to external memory is not supported. Address space areas |
86 | shared among address spaces.</para> |
87 | can be easily shared among address spaces.</para> |
87 | </section> |
88 | </section> |
88 | 89 | ||
89 | <section> |
90 | <section> |
90 | <title>IPC</title> |
91 | <title>IPC</title> |
91 | 92 | ||
92 | <para>Due to the fact that HelenOS is a microkernel, strong emphasis is |
93 | <para>Due to the fact that HelenOS is a microkernel, strong emphasis is |
93 | put on its IPC (Inter-Process Communication<footnote> |
94 | put on its IPC (Inter-Process Communication<footnote> |
94 | <para>The term Inter-Process Communication is slightly confusing |
95 | <para>The term Inter-Process Communication is slightly confusing |
95 | because in HelenOS terminology there are tasks instead of processes. |
96 | because in HelenOS terminology there are tasks instead of processes. |
96 | However, its abbreviation, IPC, is being publicly used as a standard |
97 | However, its abbreviation, IPC, is being publicly used as a standard |
97 | name for similar facilities. This book will therefore use the term IPC |
98 | name for similar facilities. This book will therefore use the term IPC |
98 | to refer to communication among tasks.</para> |
99 | to refer to communication among tasks.</para> |
99 | </footnote>). Tasks communicate by passing very short messages to one |
100 | </footnote>). Tasks communicate by passing very short messages to one |
100 | another or by sending (i.e. sharing) address space areas when larger data |
101 | another or by sending (i.e. sharing) address space areas when larger data |
101 | is to be transfered.</para> |
102 | is to be transfered.</para> |
102 | 103 | ||
103 | <para>The abstraction uses terms like phones, calls and answerboxes, but |
104 | <para>The abstraction uses terms like phones, calls and answerboxes, but |
104 | is pretty similar to well-known abstraction of message queues. A task can |
105 | is pretty similar to well-known abstraction of message queues. A task can |
105 | have multiple simultaneous simplex connections to several other tasks. A |
106 | have multiple simultaneous simplex connections to several other tasks. A |
106 | connection leads from one of the source task's phones to the destination |
107 | connection leads from one of the source task's phones to the destination |
107 | task's answerbox. The phones are used as handles for making calls to other |
108 | task's answerbox. The phones are used as handles for making calls to other |
108 | tasks. Calls can be synchronous or asynchronous and can be forwarded from |
109 | tasks. Calls can be synchronous or asynchronous and can be forwarded from |
109 | one task to another.</para> |
110 | one task to another.</para> |
110 | </section> |
111 | </section> |
111 | </chapter> |
112 | </chapter> |