Rev 39 | Rev 45 | Go to most recent revision | Details | Compare with Previous | Last modification | View Log | RSS feed
| Rev | Author | Line No. | Line |
|---|---|---|---|
| 9 | bondari | 1 | <?xml version="1.0" encoding="UTF-8"?> |
| 39 | bondari | 2 | <chapter id="architecture"> |
| 3 | <?dbhtml filename="arch.html"?> |
||
| 9 | bondari | 4 | |
| 39 | bondari | 5 | <title>Architecture overview</title> |
| 37 | bondari | 6 | |
| 39 | bondari | 7 | <section> |
| 8 | <title>Scheme</title> |
||
| 38 | bondari | 9 | |
| 39 | bondari | 10 | <para><mediaobject id="arch1"> |
| 11 | <imageobject role="html"> |
||
| 12 | <imagedata fileref="images/arch1.png" format="PNG" /> |
||
| 13 | </imageobject> |
||
| 38 | bondari | 14 | |
| 39 | bondari | 15 | <imageobject role="fop"> |
| 16 | <imagedata fileref="images.vector/arch1.svg" format="SVG" /> |
||
| 17 | </imageobject> |
||
| 18 | </mediaobject></para> |
||
| 19 | </section> |
||
| 38 | bondari | 20 | |
| 39 | bondari | 21 | <section> |
| 22 | <title>Kernel primitives</title> |
||
| 38 | bondari | 23 | |
| 39 | bondari | 24 | <para><termdef><glossterm>Thread</glossterm> is the basic execution |
| 25 | primitive.</termdef></para> |
||
| 38 | bondari | 26 | |
| 39 | bondari | 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> |
||
| 37 | bondari | 30 | |
| 40 | bondari | 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> |
||
| 37 | bondari | 34 | |
| 40 | bondari | 35 | <para><termdef><glossterm>Address space area</glossterm> is a mutually |
| 39 | bondari | 36 | disjunctive range of memory with the code, stack and data. |
| 37 | </termdef></para> |
||
| 37 | bondari | 38 | |
| 40 | bondari | 39 | <para><termdef><glossterm>Address space</glossterm> is a aggregating |
| 39 | bondari | 40 | entity for address space areas, connecting them to the task. |
| 41 | </termdef></para> |
||
| 42 | </section> |
||
| 37 | bondari | 43 | |
| 39 | bondari | 44 | <section> |
| 45 | <title>Monolithic microkernel</title> |
||
| 37 | bondari | 46 | |
| 39 | bondari | 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> |
||
| 37 | bondari | 53 | |
| 39 | bondari | 54 | <formalpara> |
| 55 | <title>Memory management</title> |
||
| 38 | bondari | 56 | |
| 40 | bondari | 57 | <para>HelenOS has all its memory |
| 39 | bondari | 58 | management functionality in the kernel, available to the memory |
| 59 | management server via the set of syscalls.</para> |
||
| 60 | </formalpara> |
||
| 38 | bondari | 61 | |
| 39 | bondari | 62 | <formalpara> |
| 63 | <title>Kernel device drivers</title> |
||
| 9 | bondari | 64 | |
| 39 | bondari | 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> |
||
| 40 | bondari | 88 | Console and frame buffer |
| 39 | bondari | 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> |