Rev 62 | Rev 77 | Go to most recent revision | Show entire file | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
Rev 62 | Rev 72 | ||
---|---|---|---|
Line 17... | Line 17... | ||
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><mediaobject id="arch1" xreflabel=""> |
23 | <mediaobject id="arch1" xreflabel=""> |
23 | <imageobject role="html"> |
24 | <imageobject role="html"> |
24 | <imagedata fileref="images/arch1.png" format="PNG" /> |
25 | <imagedata fileref="images/arch1.png" format="PNG" /> |
25 | </imageobject> |
26 | </imageobject> |
26 | 27 | ||
27 | <imageobject role="fop"> |
28 | <imageobject role="fop"> |
28 | <imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
29 | <imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
29 | </imageobject> |
30 | </imageobject> |
30 | </mediaobject> |
31 | </mediaobject> |
- | 32 | ||
31 | <title>HelenOS architecture overview.</title> |
33 | <title>HelenOS architecture overview.</title> |
32 | </figure> |
34 | </figure> |
33 | 35 | ||
34 | <para>HelenOS is comprised of the kernel and userspace server tasks. The |
36 | <para>HelenOS is comprised of the kernel and the userspace server tasks. The |
35 | kernel provides scheduling, memory management and IPC. It also contains |
37 | kernel provides scheduling, memory management and IPC. It also contains |
36 | essential device drivers that control the system clock and other devices |
38 | essential device drivers that control the system clock and other devices |
37 | necessary to guarantee a safe environment. Userspace communicates with the |
39 | necessary to guarantee a safe environment. Userspace communicates with the |
38 | kernel through a small set of syscalls. The userspace layer consists of |
40 | kernel through a small set of syscalls. The userspace layer consists of |
39 | tasks with different roles, capabilities and privileges. Some of the tasks |
41 | tasks with different roles, capabilities and privileges. Some of the tasks |
Line 42... | Line 44... | ||
42 | via kernel-provided IPC.</para> |
44 | via kernel-provided IPC.</para> |
43 | 45 | ||
44 | <section> |
46 | <section> |
45 | <title>Scheduling</title> |
47 | <title>Scheduling</title> |
46 | 48 | ||
- | 49 | <indexterm> |
|
- | 50 | <primary>thread</primary> |
|
- | 51 | </indexterm> |
|
- | 52 | ||
47 | <para>Kernel's unit of execution flow is a thread. A thread is an entity |
53 | <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 |
54 | 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 |
55 | 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 |
56 | can be several pseudo threads running within one userspace thread that |
51 | maps to one kernel thread. Threads are grouped into tasks by functionality |
57 | maps to one kernel thread. Threads are grouped into tasks by functionality |
52 | they provide (i.e. several threads implement functionality of one task). |
58 | they provide (i.e. several threads implement functionality of one task). |
- | 59 | <indexterm> |
|
- | 60 | <primary>task</primary> |
|
53 | Tasks serve as containers of threads, they provide linkage to address |
61 | </indexterm> Tasks serve as containers of threads, they provide linkage |
54 | space and are communication endpoints for IPC. Finally, tasks can be |
62 | to address space and are communication endpoints for IPC. Finally, tasks |
55 | holders of capabilities that entitle them to do certain sensitive |
63 | can be holders of capabilities that entitle them to do certain sensitive |
56 | operations (e.g access raw hardware and physical memory).</para> |
64 | operations (e.g access raw hardware and physical memory).</para> |
57 | 65 | ||
58 | <para>The scheduler deploys several run queues on each processor. A thread |
66 | <para>The scheduler deploys several run queues on each processor. A thread |
59 | ready for execution is put into one of the run queues, depending on its |
67 | ready for execution is put into one of the run queues, depending on its |
60 | priority and its current processor, from where it is eventually picked up |
68 | priority and its current processor, from where it is eventually picked up |
Line 78... | Line 86... | ||
78 | <para>The virtual address translation layer currently supports two |
86 | <para>The virtual address translation layer currently supports two |
79 | mechanisms for mapping virtual memory pages to physical memory frames |
87 | mechanisms for mapping virtual memory pages to physical memory frames |
80 | (i.e. 4-level hierarchical page tables and global page hash table), and is |
88 | (i.e. 4-level hierarchical page tables and global page hash table), and is |
81 | further extensible to other mechanisms.</para> |
89 | further extensible to other mechanisms.</para> |
82 | 90 | ||
- | 91 | <indexterm> |
|
- | 92 | <primary>address space</primary> |
|
- | 93 | </indexterm> |
|
- | 94 | ||
83 | <para>Userspace tasks depend on support of address spaces provided by the |
95 | <para>Userspace tasks depend on support of address spaces provided by the |
84 | kernel. Each address space is a set of mutually dijunctive address space |
96 | kernel. Each address space is a set of mutually dijunctive address space |
85 | areas that group pages of common attributes. An address space area is |
97 | areas that group pages of common attributes. An address space area is |
86 | usually connected to, and backed by, anonymous memory, executable image of |
98 | usually connected to, and backed by, anonymous memory, executable image of |
87 | some program or continuous region of physical memory. However, swapping |
99 | some program or continuous region of physical memory. However, swapping |
88 | pages in and out to external memory is not supported. Address space areas |
100 | pages in and out to external memory is not supported. Address space areas |
89 | can be easily shared among address spaces.</para> |
101 | can be easily shared among address spaces.</para> |
90 | </section> |
102 | </section> |
91 | 103 | ||
92 | <section> |
104 | <section> |
- | 105 | <indexterm> |
|
- | 106 | <primary>IPC</primary> |
|
- | 107 | </indexterm> |
|
- | 108 | ||
93 | <title>IPC</title> |
109 | <title>IPC</title> |
94 | 110 | ||
95 | <para>Due to the fact that HelenOS is a microkernel, strong emphasis is |
111 | <para>Due to the fact that HelenOS is a microkernel, strong emphasis is |
96 | put on its IPC (Inter-Process Communication<footnote> |
112 | put on its IPC (Inter-Process Communication<footnote> |
97 | <para>The term Inter-Process Communication is slightly confusing |
113 | <para>The term Inter-Process Communication is slightly confusing |
Line 101... | Line 117... | ||
101 | to refer to communication among tasks.</para> |
117 | to refer to communication among tasks.</para> |
102 | </footnote>). Tasks communicate by passing very short messages to one |
118 | </footnote>). Tasks communicate by passing very short messages to one |
103 | another or by sending (i.e. sharing) address space areas when larger data |
119 | another or by sending (i.e. sharing) address space areas when larger data |
104 | is to be transfered.</para> |
120 | is to be transfered.</para> |
105 | 121 | ||
- | 122 | <indexterm> |
|
- | 123 | <primary>IPC</primary> |
|
- | 124 | ||
- | 125 | <secondary>- phone</secondary> |
|
- | 126 | </indexterm> |
|
- | 127 | ||
- | 128 | <indexterm> |
|
- | 129 | <primary>IPC</primary> |
|
- | 130 | ||
- | 131 | <secondary>- answerbox</secondary> |
|
- | 132 | </indexterm> |
|
- | 133 | ||
- | 134 | <indexterm> |
|
- | 135 | <primary>IPC</primary> |
|
- | 136 | ||
- | 137 | <secondary>- message queue</secondary> |
|
- | 138 | </indexterm> |
|
- | 139 | ||
106 | <para>The abstraction uses terms like phones, calls and answerboxes, but |
140 | <para>The abstraction uses terms like phones, calls and answerboxes, but |
107 | is pretty similar to well-known abstraction of message queues. A task can |
141 | is pretty similar to well-known abstraction of message queues. A task can |
108 | have multiple simultaneous simplex connections to several other tasks. A |
142 | have multiple simultaneous simplex connections to several other tasks. A |
109 | connection leads from one of the source task's phones to the destination |
143 | connection leads from one of the source task's phones to the destination |
110 | task's answerbox. The phones are used as handles for making calls to other |
144 | task's answerbox. The phones are used as handles for making calls to other |