Subversion Repositories HelenOS-doc

Rev

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>