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 |