| 4,40 → 4,62 |
|---|
| |
| <title>Architecture overview</title> |
| |
| <section> |
| <para> |
| <mediaobject id="arch1"> |
| <imageobject role="html"> |
| <imagedata fileref="images/arch1.png" format="PNG" /> |
| </imageobject> |
| <para>The HelenOS operating system is designed as a relatively small |
| microkernel assisted with a set of userspace drivers and server tasks. |
| HelenOS is not very radical in what subsystems should or should not be |
| implemented in the kernel - in some cases, both kernel and userspace drivers |
| exist. The reason for creating the system as a microkernel is prosaic. Even |
| though it is initially more difficult to get the same level of functionality |
| from a microkernel than it is in the case of a simple monolithic kernel, a |
| microkernel is much easier to maintain once the pieces have been put to work |
| together. Therefore, the kernel of HelenOS, as well as the essential |
| userspace libraries thereof can be maintained by only a few developers who |
| understand them completely. In addition, a microkernel based operating |
| system reaches completion sooner than monolithic kernels as the system can |
| be used even without some traditional subsystems (e.g. block devices, |
| filesystems and networking).</para> |
| |
| <imageobject role="fop"> |
| <imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
| </imageobject> |
| </mediaobject> |
| </para> |
| </section> |
| <para><mediaobject id="arch1" xreflabel=""> |
| <imageobject role="html"> |
| <imagedata fileref="images/arch1.png" format="PNG" /> |
| </imageobject> |
| |
| <imageobject role="fop"> |
| <imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
| </imageobject> |
| |
| <caption>HelenOS architecture overview</caption> |
| </mediaobject></para> |
| |
| <para>HelenOS is comprised of the kernel and userspace server tasks. The |
| kernel provides scheduling, memory management and IPC. It also contains |
| essential device drivers that control the system clock and other devices |
| necessary to guarantee a safe environment. Userspace communicates with the |
| kernel through a small set of syscalls. The userspace layer consists of |
| tasks with different roles, capabilities and privileges. Some of the tasks |
| serve as device drivers, naming servers, managers of various kinds and some |
| are just ordinary user programs. All of them communicate with other threads |
| via kernel-provided IPC.</para> |
| |
| <section> |
| <para>The HelenOS operating system is designed as a relatively small |
| microkernel assisted with a set of userspace drivers and server tasks. |
| HelenOS is not very radical in what subsystems should or should not be |
| implemented in the kernel - in some cases, both kernel and userspace |
| drivers exist. The reason for creating the system as a microkernel is |
| prosaic. Even though it is initially more difficult to get the same level |
| of functionality from a microkernel than it is in the case of a simple |
| monolithic kernel, a microkernel is much easier to maintain once the |
| pieces have been put to work together. Therefore, the kernel of HelenOS, |
| as well as the essential userspace libraries thereof can be maintained by |
| only a few developers who understand them completely. In addition, a |
| microkernel based operating system reaches completion sooner than |
| monolithic kernels as the system can be used even without some traditional |
| subsystems (e.g. block devices, filesystems and networking).</para> |
| <title>Scheduling</title> |
| |
| <para>HelenOS is comprised of the kernel and userspace server tasks. The |
| kernel provides scheduling, memory management and IPC. It also contains |
| essential device drivers that control the system clock and other devices |
| necessary to guarantee a safe environment. Userspace communicates with the |
| kernel through </para> |
| <para>Kernel's unit of execution flow is a thread. A thread is an entity |
| that executes code and has a stack that takes up some space in memory. The |
| relation between kernel and userspace threads is 1:1:n, meaning that there |
| can be several pseudo threads running within one userspace thread that |
| maps to one kernel thread. Threads are grouped into tasks by functionality |
| they provide (i.e. several threads implement functionality of one task). |
| Tasks serve as containers of threads, they provide linkage to address |
| space and are communication endpoints for IPC.</para> |
| |
| <para>The scheduler deploys several run queues on each processor. A thread |
| ready for execution is put into one of the run queues, depending on its |
| priority and its current processor, from where it is eventually picked up |
| by the scheduler. Special purpose kernel threads strive to keep processors |
| balanced by thread migration. Threads are scheduled by the round robing |
| scheduling policy with respect to multiple priority run queues.</para> |
| |
| <para></para> |
| </section> |
| </chapter> |