Subversion Repositories HelenOS-doc

Rev

Rev 49 | Rev 58 | Go to most recent revision | Blame | Compare with Previous | Last modification | View Log | Download | RSS feed

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <chapter id="architecture">
  3.   <?dbhtml filename="arch.html"?>
  4.  
  5.   <title>Architecture overview</title>
  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
  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,
  20.   filesystems and networking).</para>
  21.  
  22.   <para><mediaobject id="arch1" xreflabel="">
  23.       <imageobject role="html">
  24.         <imagedata fileref="images/arch1.png" format="PNG" />
  25.       </imageobject>
  26.  
  27.       <imageobject role="fop">
  28.         <imagedata fileref="images.vector/arch1.svg" format="SVG" />
  29.       </imageobject>
  30.  
  31.       <caption>HelenOS architecture overview</caption>
  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
  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.  </section>
  63.  
  64.  <section>
  65.    <title>Memory management</title>
  66.  
  67.    <para>Memory management is another large subsystem in HelenOS. It serves
  68.    the kernel to satisfy its own memory allocation requests, provides
  69.    translation between virtual and physical memory addresses and manages
  70.    virtual address spaces of userspace tasks.</para>
  71.  
  72.    <para>Kernel allocates memory from the slab allocator, which itself
  73.    allocates memory from a buddy system based allocator of physical memory
  74.    frames.</para>
  75.  
  76.    <para>The virtual address translation layer currently supports two
  77.    mechanisms for mapping virtual memory pages to physical memory frames
  78.    (i.e. 4-level hierarchical page tables and global page hash table), and is
  79.    further extensible to other mechanisms.</para>
  80.  
  81.    <para>Userspace tasks depend on support of address spaces provided by the
  82.    kernel. Each address space is a set of mutually dijunctive address space
  83.    areas that group pages of common attributes. An address space area is
  84.    usually connected to, and backed by, anonymous memory, executable image of
  85.    some program or continuous region of physical memory. However, swapping
  86.    pages in and out to external memory is not supported. Address space areas
  87.    can be easily shared among address spaces.</para>
  88.  </section>
  89.  
  90.  <section>
  91.    <title>IPC</title>
  92.  
  93.    <para>Due to the fact that HelenOS is a microkernel, strong emphasis is
  94.    put on its IPC (Inter-Process Communication<footnote>
  95.        <para>The term Inter-Process Communication is slightly confusing
  96.        because in HelenOS terminology there are tasks instead of processes.
  97.        However, its abbreviation, IPC, is being publicly used as a standard
  98.        name for similar facilities. This book will therefore use the term IPC
  99.        to refer to communication among tasks.</para>
  100.      </footnote>). Tasks communicate by passing very short messages to one
  101.    another or by sending (i.e. sharing) address space areas when larger data
  102.    is to be transfered.</para>
  103.  
  104.    <para>The abstraction uses terms like phones, calls and answerboxes, but
  105.    is pretty similar to well-known abstraction of message queues. A task can
  106.    have multiple simultaneous simplex connections to several other tasks. A
  107.    connection leads from one of the source task's phones to the destination
  108.     task's answerbox. The phones are used as handles for making calls to other
  109.    tasks. Calls can be synchronous or asynchronous and can be forwarded from
  110.    one task to another.</para>
  111.  </section>
  112. </chapter>