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>

  <figure>

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

    </mediaobject>

    <title>HelenOS architecture overview.</title>

  </figure>

  <para>HelenOS is comprised of the kernel and the 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>

    <indexterm>

      <primary>thread</primary>

    </indexterm>

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

    <indexterm>

        <primary>task</primary>

      </indexterm> Tasks serve as containers of threads, they provide linkage

    to address space and are communication endpoints for IPC. Finally, tasks

    can be holders of capabilities that entitle them to do certain sensitive

    operations (e.g access raw hardware and physical memory).</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>

  </section>

  <section>

    <title>Memory management</title>

    <para>Memory management is another large subsystem in HelenOS. It serves

    the kernel to satisfy its own memory allocation requests, provides

    translation between virtual and physical memory addresses and manages

    virtual address spaces of userspace tasks.</para>

    <para>Kernel allocates memory from the slab allocator, which itself

    allocates memory from a buddy system based allocator of physical memory

    frames.</para>

    <para>The virtual address translation layer currently supports two

    mechanisms for mapping virtual memory pages to physical memory frames

    (i.e. 4-level hierarchical page tables and global page hash table), and is

    further extensible to other mechanisms.</para>

    <indexterm>

      <primary>address space</primary>

    </indexterm>

    <para>Userspace tasks depend on support of address spaces provided by the

    kernel. Each address space is a set of mutually dijunctive address space

    areas that group pages of common attributes. An address space area is

    usually connected to, and backed by, anonymous memory, executable image of

    some program or continuous region of physical memory. However, swapping

    pages in and out to external memory is not supported. Address space areas

    can be easily shared among address spaces.</para>

  </section>

  <section>

    <indexterm>

      <primary>IPC</primary>

    </indexterm>

    <title>IPC</title>

    <para>Due to the fact that HelenOS is a microkernel, strong emphasis is

    put on its IPC (Inter-Process Communication<footnote>

        <para>The term Inter-Process Communication is slightly confusing

        because in HelenOS terminology there are tasks instead of processes.

        However, its abbreviation, IPC, is being publicly used as a standard

        name for similar facilities. This book will therefore use the term IPC

        to refer to communication among tasks.</para>

      </footnote>). Tasks communicate by passing very short messages to one

    another or by sending (i.e. sharing) address space areas when larger data

    is to be transfered.</para>

    <indexterm>

      <primary>IPC</primary>

      <secondary>- phone</secondary>

    </indexterm>

    <indexterm>

      <primary>IPC</primary>

      <secondary>- answerbox</secondary>

    </indexterm>

    <indexterm>

      <primary>IPC</primary>

      <secondary>- message queue</secondary>

    </indexterm>

    <para>The abstraction uses terms like phones, calls and answerboxes, but

    is pretty similar to well-known abstraction of message queues. A task can

    have multiple simultaneous simplex connections to several other tasks. A

    connection leads from one of the source task's phones to the destination

    task's answerbox. The phones are used as handles for making calls to other

    tasks. Calls can be synchronous or asynchronous and can be forwarded from

    one task to another.</para>

  </section>

</chapter>