Subversion Repositories HelenOS-doc

Rev

Rev 131 | Rev 138 | 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
 
131 jermar 5
  <title>Architecture Overview</title>
37 bondari 6
 
48 jermar 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>
38 bondari 21
 
101 bondari 22
  <figure float="1">
87 bondari 23
    <mediaobject id="arch1">
24
      <imageobject role="pdf">
126 jermar 25
        <imagedata fileref="images/arch1.pdf" format="PDF" />
77 bondari 26
      </imageobject>
27
 
48 jermar 28
      <imageobject role="html">
29
        <imagedata fileref="images/arch1.png" format="PNG" />
30
      </imageobject>
38 bondari 31
 
48 jermar 32
      <imageobject role="fop">
105 bondari 33
        <imagedata fileref="images/arch1.svg" format="SVG" />
72 bondari 34
      </imageobject>
62 jermar 35
    </mediaobject>
72 bondari 36
 
62 jermar 37
    <title>HelenOS architecture overview.</title>
72 bondari 38
  </figure>
48 jermar 39
 
72 bondari 40
  <para>HelenOS is comprised of the kernel and the userspace server tasks. The
48 jermar 41
  kernel provides scheduling, memory management and IPC. It also contains
42
  essential device drivers that control the system clock and other devices
43
  necessary to guarantee a safe environment. Userspace communicates with the
44
  kernel through a small set of syscalls. The userspace layer consists of
45
  tasks with different roles, capabilities and privileges. Some of the tasks
46
  serve as device drivers, naming servers, managers of various kinds and some
47
  are just ordinary user programs. All of them communicate with other threads
48
  via kernel-provided IPC.</para>
49
 
39 bondari 50
  <section>
48 jermar 51
    <title>Scheduling</title>
38 bondari 52
 
72 bondari 53
    <indexterm>
54
      <primary>thread</primary>
55
    </indexterm>
56
 
48 jermar 57
    <para>Kernel's unit of execution flow is a thread. A thread is an entity
58
    that executes code and has a stack that takes up some space in memory. The
59
    relation between kernel and userspace threads is 1:1:n, meaning that there
60
    can be several pseudo threads running within one userspace thread that
61
    maps to one kernel thread. Threads are grouped into tasks by functionality
62
    they provide (i.e. several threads implement functionality of one task).
72 bondari 63
    <indexterm>
64
        <primary>task</primary>
65
      </indexterm> Tasks serve as containers of threads, they provide linkage
66
    to address space and are communication endpoints for IPC. Finally, tasks
67
    can be holders of capabilities that entitle them to do certain sensitive
58 jermar 68
    operations (e.g access raw hardware and physical memory).</para>
48 jermar 69
 
70
    <para>The scheduler deploys several run queues on each processor. A thread
71
    ready for execution is put into one of the run queues, depending on its
72
    priority and its current processor, from where it is eventually picked up
73
    by the scheduler. Special purpose kernel threads strive to keep processors
74
    balanced by thread migration. Threads are scheduled by the round robing
75
    scheduling policy with respect to multiple priority run queues.</para>
49 jermar 76
  </section>
48 jermar 77
 
49 jermar 78
  <section>
131 jermar 79
    <title>Memory Management</title>
49 jermar 80
 
81
    <para>Memory management is another large subsystem in HelenOS. It serves
82
    the kernel to satisfy its own memory allocation requests, provides
83
    translation between virtual and physical memory addresses and manages
84
    virtual address spaces of userspace tasks.</para>
85
 
86
    <para>Kernel allocates memory from the slab allocator, which itself
87
    allocates memory from a buddy system based allocator of physical memory
88
    frames.</para>
89
 
90
    <para>The virtual address translation layer currently supports two
91
    mechanisms for mapping virtual memory pages to physical memory frames
92
    (i.e. 4-level hierarchical page tables and global page hash table), and is
93
    further extensible to other mechanisms.</para>
94
 
72 bondari 95
    <indexterm>
96
      <primary>address space</primary>
97
    </indexterm>
98
 
49 jermar 99
    <para>Userspace tasks depend on support of address spaces provided by the
100
    kernel. Each address space is a set of mutually dijunctive address space
101
    areas that group pages of common attributes. An address space area is
50 jermar 102
    usually connected to, and backed by, anonymous memory, executable image of
103
    some program or continuous region of physical memory. However, swapping
104
    pages in and out to external memory is not supported. Address space areas
105
    can be easily shared among address spaces.</para>
39 bondari 106
  </section>
49 jermar 107
 
108
  <section>
72 bondari 109
    <indexterm>
110
      <primary>IPC</primary>
111
    </indexterm>
112
 
49 jermar 113
    <title>IPC</title>
114
 
115
    <para>Due to the fact that HelenOS is a microkernel, strong emphasis is
116
    put on its IPC (Inter-Process Communication<footnote>
117
        <para>The term Inter-Process Communication is slightly confusing
118
        because in HelenOS terminology there are tasks instead of processes.
119
        However, its abbreviation, IPC, is being publicly used as a standard
120
        name for similar facilities. This book will therefore use the term IPC
121
        to refer to communication among tasks.</para>
122
      </footnote>). Tasks communicate by passing very short messages to one
123
    another or by sending (i.e. sharing) address space areas when larger data
124
    is to be transfered.</para>
125
 
72 bondari 126
    <indexterm>
127
      <primary>IPC</primary>
128
 
129
      <secondary>- phone</secondary>
130
    </indexterm>
131
 
132
    <indexterm>
133
      <primary>IPC</primary>
134
 
135
      <secondary>- answerbox</secondary>
136
    </indexterm>
137
 
138
    <indexterm>
139
      <primary>IPC</primary>
140
 
141
      <secondary>- message queue</secondary>
142
    </indexterm>
143
 
49 jermar 144
    <para>The abstraction uses terms like phones, calls and answerboxes, but
145
    is pretty similar to well-known abstraction of message queues. A task can
146
    have multiple simultaneous simplex connections to several other tasks. A
147
    connection leads from one of the source task's phones to the destination
148
    task's answerbox. The phones are used as handles for making calls to other
149
    tasks. Calls can be synchronous or asynchronous and can be forwarded from
150
    one task to another.</para>
151
  </section>
132 bondari 152
</chapter>