WebSVN – HelenOS-doc – Diff – /design/trunk/src/ch_arch_overview.xml


<?xml version="1.0" encoding="UTF-8"?>
<chapter id="architecture">
  <?dbhtml filename="arch.html"?>
 
  <title>Architecture Overview</title>
 
  <para>The HelenOS operating system is designed as a relatively small
  microkernel assisted with a set of userspace drivers and server tasks.
  HelenOS is not very radical in which subsystems should or should not be
  implemented in the kernel - in some cases, both kernel and userspace drivers
  exist. The reason for creating the system as a microkernel is prosaic. Even
  though it is initially more difficult to get the same level of functionality
  from a microkernel than it is in the case of a simple monolithic kernel, a
  microkernel is much easier to maintain once the pieces have been put to work
  together. Therefore, the kernel of HelenOS, as well as the essential
  userspace libraries thereof can be maintained by only a few developers who
  understand them completely. In addition, a microkernel based operating
  system reaches completion sooner than monolithic kernels as the system can
  be used even without some traditional subsystems (e.g. block devices,
  filesystems and networking).</para>
 
  <figure float="1">
    <mediaobject id="arch1">
      <imageobject role="pdf">
        <imagedata fileref="images/arch1.pdf" format="PDF" />
      </imageobject>
 
      <imageobject role="html">
        <imagedata fileref="images/arch1.png" format="PNG" />
      </imageobject>
 
      <imageobject role="fop">
        <imagedata fileref="images/arch1.svg" format="SVG" />
      </imageobject>
    </mediaobject>
 
    <title>HelenOS architecture overview.</title>
  </figure>
 
  <para>HelenOS is comprised of the kernel and the userspace server tasks. The
  kernel provides scheduling, memory management and IPC. It also contains
  essential device drivers that control the system clock and other devices
  necessary to guarantee a safe environment. Userspace communicates with the
  kernel through a small set of syscalls. The userspace layer consists of
  tasks with different roles, capabilities and privileges. Some of the tasks
  serve as device drivers, naming servers, managers of various kinds and some
  are just ordinary user programs. All of them communicate with other threads
  via kernel-provided IPC.</para>
 
  <section>
    <title>Scheduling</title>
 
    <indexterm>
      <primary>thread</primary>
    </indexterm>
 
    <para>Kernel's unit of execution flow is a thread. A thread is an entity
    that executes code and has a stack that takes up some space in memory. The
    relation between kernel and userspace threads is 1:1:n, meaning that there
    can be several so called fibrils running within one userspace thread that
    maps to one kernel thread. Threads are grouped into tasks by functionality
    they provide (i.e. several threads implement functionality of one task).
    <indexterm>
        <primary>task</primary>
      </indexterm> Tasks serve as containers of threads, they provide linkage
    to address space and are communication endpoints for IPC. Finally, tasks
    can be holders of capabilities that entitle them to do certain sensitive
    operations (e.g access raw hardware and physical memory).</para>
 
    <para>The scheduler deploys several run queues on each processor. A thread
    ready for execution is put into one of the run queues, depending on its
    priority and its current processor, from where it is eventually picked up
    by the scheduler. Special purpose kernel threads strive to keep processors
    balanced by thread migration. Threads are scheduled by the round robing
    scheduling policy with respect to multiple priority run queues.</para>
  </section>
 
  <section>
    <title>Memory Management</title>
 
    <para>Memory management is another large subsystem in HelenOS. It serves
    the kernel to satisfy its own memory allocation requests, provides
    translation between virtual and physical memory addresses and manages
    virtual address spaces of userspace tasks.</para>
 
    <para>Kernel allocates memory from the slab allocator, which itself
    allocates memory from a buddy system based allocator of physical memory
    frames.</para>
 
    <para>The virtual address translation layer currently supports two
    mechanisms for mapping virtual memory pages to physical memory frames
    (i.e. 4-level hierarchical page tables and global page hash table), and is
    further extensible to other mechanisms.</para>
 
    <indexterm>
      <primary>address space</primary>
    </indexterm>
 
    <para>Userspace tasks depend on support of address spaces provided by the
    kernel. Each address space is a set of mutually disjunctive address space
    areas. An address space area is usually connected to, and backed by,
    anonymous memory, executable image of some program or continuous region of
    physical memory. However, swapping pages in and out to external memory is
    not supported. Address space areas can be easily shared among address
    spaces.</para>
  </section>
 
  <section>
    <indexterm>
      <primary>IPC</primary>
    </indexterm>
 
    <title>IPC</title>
 
    <para>Due to the fact that HelenOS is a microkernel, strong emphasis is
    put on its IPC (Inter-Process Communication<footnote>
        <para>The term Inter-Process Communication is slightly confusing
        because in HelenOS terminology there are tasks instead of processes.
        However, its abbreviation, IPC, is being publicly used as a standard
        name for similar facilities. This book will therefore use the term IPC
        to refer to communication among tasks.</para>
      </footnote>). Tasks communicate by passing very short messages to one
    another or by sending (i.e. sharing) address space areas when larger data
    is to be transfered.</para>
 
    <indexterm>
      <primary>IPC</primary>
 
      <secondary>- phone</secondary>
    </indexterm>
 
    <indexterm>
      <primary>IPC</primary>
 
      <secondary>- answerbox</secondary>
    </indexterm>
 
    <indexterm>
      <primary>IPC</primary>
 
      <secondary>- message queue</secondary>
    </indexterm>
 
    <para>The abstraction uses terms like phones, calls and answerboxes, but
    is similar to well-known abstraction of message queues. A task can have
    multiple simultaneous simplex connections to several other tasks. A
    connection leads from one of the source task's phones to the destination
    task's answerbox. The phones are used as handles for making calls to other
    tasks. Calls are asynchronous and can be forwarded from one task to
    another.</para>
  </section>
</chapter>

Subversion Repositories HelenOS-doc

(root)/design/trunk/src/ch_arch_overview.xml – Rev 138 → 171

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