Subversion Repositories HelenOS-doc

<?xml version="1.0" encoding="UTF-8"?>
<chapter id="architecture">
  <?dbhtml filename="arch.html"?>

  <title>Architecture overview</title>

  <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>

  <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>
    <title>Scheduling</title>

    <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>