Rev 45 | Rev 49 | Go to most recent revision | Show entire file | Regard whitespace | Details | Blame | Last modification | View Log | RSS feed
Rev 45 | Rev 48 | ||
---|---|---|---|
Line 2... | Line 2... | ||
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 |
|
- | 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 |
|
- | 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 |
|
- | 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 |
|
- | 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 |
|
- | 16 | userspace libraries thereof can be maintained by only a few developers who |
|
7 | <section> |
17 | understand them completely. In addition, a microkernel based operating |
- | 18 | system reaches completion sooner than monolithic kernels as the system can |
|
- | 19 | be used even without some traditional subsystems (e.g. block devices, |
|
8 | <para> |
20 | filesystems and networking).</para> |
- | 21 | ||
9 | <mediaobject id="arch1"> |
22 | <para><mediaobject id="arch1" xreflabel=""> |
10 | <imageobject role="html"> |
23 | <imageobject role="html"> |
11 | <imagedata fileref="images/arch1.png" format="PNG" /> |
24 | <imagedata fileref="images/arch1.png" format="PNG" /> |
12 | </imageobject> |
25 | </imageobject> |
13 | 26 | ||
14 | <imageobject role="fop"> |
27 | <imageobject role="fop"> |
15 | <imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
28 | <imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
16 | </imageobject> |
29 | </imageobject> |
17 | </mediaobject> |
- | |
18 | </para> |
- | |
19 | </section> |
- | |
20 | 30 | ||
21 | <section> |
- | |
22 | <para>The HelenOS operating system is designed as a relatively small |
31 | <caption>HelenOS architecture overview</caption> |
23 | microkernel assisted with a set of userspace drivers and server tasks. |
- | |
24 | HelenOS is not very radical in what subsystems should or should not be |
- | |
25 | implemented in the kernel - in some cases, both kernel and userspace |
- | |
26 | drivers exist. The reason for creating the system as a microkernel is |
- | |
27 | prosaic. Even though it is initially more difficult to get the same level |
- | |
28 | of functionality from a microkernel than it is in the case of a simple |
- | |
29 | monolithic kernel, a microkernel is much easier to maintain once the |
- | |
30 | pieces have been put to work together. Therefore, the kernel of HelenOS, |
- | |
31 | as well as the essential userspace libraries thereof can be maintained by |
- | |
32 | only a few developers who understand them completely. In addition, a |
- | |
33 | microkernel based operating system reaches completion sooner than |
- | |
34 | monolithic kernels as the system can be used even without some traditional |
- | |
35 | subsystems (e.g. block devices, filesystems and networking).</para> |
32 | </mediaobject></para> |
36 | 33 | ||
37 | <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 |
38 | kernel provides scheduling, memory management and IPC. It also contains |
35 | kernel provides scheduling, memory management and IPC. It also contains |
39 | essential device drivers that control the system clock and other devices |
36 | essential device drivers that control the system clock and other devices |
40 | 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 |
|
- | 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 |
|
- | 41 | are just ordinary user programs. All of them communicate with other threads |
|
41 | kernel through </para> |
42 | via kernel-provided IPC.</para> |
- | 43 | ||
- | 44 | <section> |
|
- | 45 | <title>Scheduling</title> |
|
- | 46 | ||
- | 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 |
|
- | 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 |
|
- | 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). |
|
- | 53 | Tasks serve as containers of threads, they provide linkage to address |
|
- | 54 | space and are communication endpoints for IPC.</para> |
|
- | 55 | ||
- | 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 |
|
- | 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 |
|
- | 60 | balanced by thread migration. Threads are scheduled by the round robing |
|
- | 61 | scheduling policy with respect to multiple priority run queues.</para> |
|
- | 62 | ||
- | 63 | <para></para> |
|
42 | </section> |
64 | </section> |
43 | </chapter> |
65 | </chapter> |
44 | 66 |