Rev 45 | Rev 49 | Go to most recent revision | Show entire file | Ignore 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> |
| - | 30 | ||
| 17 | </mediaobject> |
31 | <caption>HelenOS architecture overview</caption> |
| 18 | </para> |
32 | </mediaobject></para> |
| - | 33 | ||
| - | 34 | <para>HelenOS is comprised of the kernel and userspace server tasks. The |
|
| - | 35 | kernel provides scheduling, memory management and IPC. It also contains |
|
| - | 36 | essential device drivers that control the system clock and other devices |
|
| - | 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 |
|
| 19 | </section> |
42 | via kernel-provided IPC.</para> |
| 20 | 43 | ||
| 21 | <section> |
44 | <section> |
| - | 45 | <title>Scheduling</title> |
|
| - | 46 | ||
| 22 | <para>The HelenOS operating system is designed as a relatively small |
47 | <para>Kernel's unit of execution flow is a thread. A thread is an entity |
| 23 | microkernel assisted with a set of userspace drivers and server tasks. |
48 | that executes code and has a stack that takes up some space in memory. The |
| 24 | HelenOS is not very radical in what subsystems should or should not be |
49 | relation between kernel and userspace threads is 1:1:n, meaning that there |
| 25 | implemented in the kernel - in some cases, both kernel and userspace |
50 | can be several pseudo threads running within one userspace thread that |
| 26 | drivers exist. The reason for creating the system as a microkernel is |
51 | maps to one kernel thread. Threads are grouped into tasks by functionality |
| 27 | prosaic. Even though it is initially more difficult to get the same level |
52 | they provide (i.e. several threads implement functionality of one task). |
| 28 | of functionality from a microkernel than it is in the case of a simple |
53 | Tasks serve as containers of threads, they provide linkage to address |
| 29 | monolithic kernel, a microkernel is much easier to maintain once the |
54 | space and are communication endpoints for IPC.</para> |
| - | 55 | ||
| 30 | pieces have been put to work together. Therefore, the kernel of HelenOS, |
56 | <para>The scheduler deploys several run queues on each processor. A thread |
| 31 | as well as the essential userspace libraries thereof can be maintained by |
57 | ready for execution is put into one of the run queues, depending on its |
| 32 | only a few developers who understand them completely. In addition, a |
58 | priority and its current processor, from where it is eventually picked up |
| 33 | microkernel based operating system reaches completion sooner than |
59 | by the scheduler. Special purpose kernel threads strive to keep processors |
| 34 | monolithic kernels as the system can be used even without some traditional |
60 | balanced by thread migration. Threads are scheduled by the round robing |
| 35 | subsystems (e.g. block devices, filesystems and networking).</para> |
61 | scheduling policy with respect to multiple priority run queues.</para> |
| 36 | 62 | ||
| 37 | <para>HelenOS is comprised of the kernel and userspace server tasks. The |
- | |
| 38 | kernel provides scheduling, memory management and IPC. It also contains |
- | |
| 39 | essential device drivers that control the system clock and other devices |
- | |
| 40 | necessary to guarantee a safe environment. Userspace communicates with the |
- | |
| 41 | kernel through </para> |
63 | <para></para> |
| 42 | </section> |
64 | </section> |
| 43 | </chapter> |
65 | </chapter> |
| 44 | 66 | ||