Subversion Repositories HelenOS-doc

Rev

Rev 48 | Rev 50 | Go to most recent revision | Only display areas with differences | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed

Rev 48 Rev 49
1
<?xml version="1.0" encoding="UTF-8"?>
1
<?xml version="1.0" encoding="UTF-8"?>
2
<chapter id="architecture">
2
<chapter id="architecture">
3
  <?dbhtml filename="arch.html"?>
3
  <?dbhtml filename="arch.html"?>
4
 
4
 
5
  <title>Architecture overview</title>
5
  <title>Architecture overview</title>
6
 
6
 
7
  <para>The HelenOS operating system is designed as a relatively small
7
  <para>The HelenOS operating system is designed as a relatively small
8
  microkernel assisted with a set of userspace drivers and server tasks.
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
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
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
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
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
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
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
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
16
  userspace libraries thereof can be maintained by only a few developers who
17
  understand them completely. In addition, a microkernel based operating
17
  understand them completely. In addition, a microkernel based operating
18
  system reaches completion sooner than monolithic kernels as the system can
18
  system reaches completion sooner than monolithic kernels as the system can
19
  be used even without some traditional subsystems (e.g. block devices,
19
  be used even without some traditional subsystems (e.g. block devices,
20
  filesystems and networking).</para>
20
  filesystems and networking).</para>
21
 
21
 
22
  <para><mediaobject id="arch1" xreflabel="">
22
  <para><mediaobject id="arch1" xreflabel="">
23
      <imageobject role="html">
23
      <imageobject role="html">
24
        <imagedata fileref="images/arch1.png" format="PNG" />
24
        <imagedata fileref="images/arch1.png" format="PNG" />
25
      </imageobject>
25
      </imageobject>
26
 
26
 
27
      <imageobject role="fop">
27
      <imageobject role="fop">
28
        <imagedata fileref="images.vector/arch1.svg" format="SVG" />
28
        <imagedata fileref="images.vector/arch1.svg" format="SVG" />
29
      </imageobject>
29
      </imageobject>
30
 
30
 
31
      <caption>HelenOS architecture overview</caption>
31
      <caption>HelenOS architecture overview</caption>
32
    </mediaobject></para>
32
    </mediaobject></para>
33
 
33
 
34
  <para>HelenOS is comprised of the kernel and userspace server tasks. The
34
  <para>HelenOS is comprised of the kernel and userspace server tasks. The
35
  kernel provides scheduling, memory management and IPC. It also contains
35
  kernel provides scheduling, memory management and IPC. It also contains
36
  essential device drivers that control the system clock and other devices
36
  essential device drivers that control the system clock and other devices
37
  necessary to guarantee a safe environment. Userspace communicates with the
37
  necessary to guarantee a safe environment. Userspace communicates with the
38
  kernel through a small set of syscalls. The userspace layer consists of
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
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
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
41
  are just ordinary user programs. All of them communicate with other threads
42
  via kernel-provided IPC.</para>
42
  via kernel-provided IPC.</para>
43
 
43
 
44
  <section>
44
  <section>
45
    <title>Scheduling</title>
45
    <title>Scheduling</title>
46
 
46
 
47
    <para>Kernel's unit of execution flow is a thread. A thread is an entity
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
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
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
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
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).
52
    they provide (i.e. several threads implement functionality of one task).
53
    Tasks serve as containers of threads, they provide linkage to address
53
    Tasks serve as containers of threads, they provide linkage to address
54
    space and are communication endpoints for IPC.</para>
54
    space and are communication endpoints for IPC.</para>
55
 
55
 
56
    <para>The scheduler deploys several run queues on each processor. A thread
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
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
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
59
    by the scheduler. Special purpose kernel threads strive to keep processors
60
    balanced by thread migration. Threads are scheduled by the round robing
60
    balanced by thread migration. Threads are scheduled by the round robing
61
    scheduling policy with respect to multiple priority run queues.</para>
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, an anonymous memory or an executable
-
 
85
    image of some program. Anonymous memory address space areas can be easily
-
 
86
    shared among address spaces.</para>
-
 
87
  </section>
-
 
88
 
-
 
89
  <section>
-
 
90
    <title>IPC</title>
-
 
91
 
-
 
92
    <para>Due to the fact that HelenOS is a microkernel, strong emphasis is
-
 
93
    put on its IPC (Inter-Process Communication<footnote>
-
 
94
        <para>The term Inter-Process Communication is slightly confusing
-
 
95
        because in HelenOS terminology there are tasks instead of processes.
-
 
96
        However, its abbreviation, IPC, is being publicly used as a standard
-
 
97
        name for similar facilities. This book will therefore use the term IPC
-
 
98
        to refer to communication among tasks.</para>
-
 
99
      </footnote>). Tasks communicate by passing very short messages to one
-
 
100
    another or by sending (i.e. sharing) address space areas when larger data
-
 
101
    is to be transfered.</para>
62
 
102
 
-
 
103
    <para>The abstraction uses terms like phones, calls and answerboxes, but
-
 
104
    is pretty similar to well-known abstraction of message queues. A task can
-
 
105
    have multiple simultaneous simplex connections to several other tasks. A
-
 
106
    connection leads from one of the source task's phones to the destination
-
 
107
    task's answerbox. The phones are used as handles for making calls to other
-
 
108
    tasks. Calls can be synchronous or asynchronous and can be forwarded from
63
    <para></para>
109
    one task to another.</para>
64
  </section>
110
  </section>
65
</chapter>
111
</chapter>