Subversion Repositories HelenOS-doc

Rev

Rev 39 | Rev 45 | 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.   <section>
  8.     <title>Scheme</title>
  9.  
  10.     <para><mediaobject id="arch1">
  11.         <imageobject role="html">
  12.           <imagedata fileref="images/arch1.png" format="PNG" />
  13.         </imageobject>
  14.  
  15.         <imageobject role="fop">
  16.           <imagedata fileref="images.vector/arch1.svg" format="SVG" />
  17.         </imageobject>
  18.       </mediaobject></para>
  19.   </section>
  20.  
  21.   <section>
  22.     <title>Kernel primitives</title>
  23.  
  24.     <para><termdef><glossterm>Thread</glossterm> is the basic execution
  25.     primitive.</termdef></para>
  26.  
  27.     <para><termdef><glossterm>Thread context</glossterm> represents state of
  28.     the <emphasis>thread</emphasis>. Thread context is built of the context
  29.     registers contents, FPU state and the stack.</termdef></para>
  30.  
  31.     <para><termdef><glossterm>Task</glossterm> is a multi-purpose entity,
  32.     serving to incorporate set if its threads, provide common address space to its threads,
  33.     be an end-point in IPC.</termdef></para>
  34.  
  35.     <para><termdef><glossterm>Address space area</glossterm> is a mutually
  36.     disjunctive range of memory with the code, stack and data.
  37.     </termdef></para>
  38.  
  39.     <para><termdef><glossterm>Address space</glossterm> is a aggregating
  40.     entity for address space areas, connecting them to the task.
  41.     </termdef></para>
  42.   </section>
  43.  
  44.   <section>
  45.     <title>Monolithic microkernel</title>
  46.  
  47.     <para>Though HelenOS was initially planned as a microkernel, we were
  48.     trying to avoid several issues, connected with microkernels, such as much
  49.     higher overhead during memory management and hardware operations. For this
  50.     reason some of the subsystems, that are to be implemented as servers in
  51.     classic microkernel design, were implemented as a part of kernel, thus
  52.     minimizing this overhead.</para>
  53.  
  54.     <formalpara>
  55.       <title>Memory management</title>
  56.  
  57.       <para>HelenOS has all its memory
  58.       management functionality in the kernel, available to the memory
  59.       management server via the set of syscalls.</para>
  60.     </formalpara>
  61.  
  62.     <formalpara>
  63.       <title>Kernel device drivers</title>
  64.  
  65.       <para>HelenOS kernel has some of the very basic device drivers
  66.       <itemizedlist>
  67.           <listitem>
  68.             ACPI
  69.           </listitem>
  70.  
  71.           <listitem>
  72.             APIC
  73.           </listitem>
  74.  
  75.           <listitem>
  76.             SMP configuration
  77.           </listitem>
  78.  
  79.           <listitem>
  80.             System clock
  81.           </listitem>
  82.  
  83.           <listitem>
  84.             Interrupt controllers
  85.           </listitem>
  86.  
  87.           <listitem>
  88.             Console and frame buffer
  89.           </listitem>
  90.  
  91.         </itemizedlist></para>
  92.     </formalpara>
  93.   </section>
  94.  
  95.   <section>
  96.     <title>IPC</title>
  97.  
  98.     <para>HelenOS IPC is designed in analogy with telephone communication.
  99.     Each task has an <emphasis>answerbox</emphasis> and a set of
  100.     <emphasis>phones</emphasis> to call another tasks' answerboxes.</para>
  101.  
  102.    <para>Communication is possible after the connection is established, and
  103.    can be either <emphasis>asynchronious</emphasis> or
  104.    <emphasis>synchronious</emphasis>.</para>
  105.  </section>
  106.  
  107.  <section>
  108.    <title>Functionality model</title>
  109.  
  110.    <para>As you know, microkernel design is very simple, just enough to
  111.    provide communication facility for tasks. Most of the OS functionality is
  112.    performed by server tasks, that are running in userspace. Thus most of the
  113.    system calls in monolithic kernels, are the IPC calls on server tasks in
  114.    microkernels.</para>
  115.  
  116.    <para>Moreover, problems experience the device drivers. Running in the
  117.    user space, device driver still needs to recieve interrupts and access
  118.    hardware directly.</para>
  119.  
  120.    <para>This raises two major problems in microkernels: <orderedlist
  121.        numeration="loweralpha">
  122.        <listitem>
  123.          What is the recipient address of the server (e.g. "memory manager" or a specific device driver) ?
  124.        </listitem>
  125.  
  126.        <listitem>
  127.          How this server task is going to access hardware or kernel while running in the user mode?
  128.        </listitem>
  129.      </orderedlist></para>
  130.  
  131.    <formalpara id="intro_ns">
  132.      <title>Name server</title>
  133.  
  134.      <para>As every microkernel, HelenOS has a "Name server" task with "well
  135.      known" IPC address, that connects user task to any server just by the
  136.      string service indentification.</para>
  137.    </formalpara>
  138.  
  139.    <formalpara id="intro_ddi">
  140.      <title>Device driver interface</title>
  141.  
  142.      <para>Device drivers use special syscalls to map physical memory areas
  143.      into their address space, to map port regions (mostly ia32). Interrupts
  144.      are delivered to the device driver task by the standard IPC
  145.      means.</para>
  146.    </formalpara>
  147.  </section>
  148. </chapter>