Subversion Repositories shark

Rev

Details | Last modification | View Log | RSS feed

Rev Author Line No. Line
1676 tullio 1
%----------------------------------------------------------------------------
2
\chapter{Introduction}
3
%----------------------------------------------------------------------------
4
 
5
Real-time computing is required in many application domains, ranging
6
from embedded process control to multimedia systems. Each application
7
has peculiar characteristics in terms of timing constraints and computational
8
requirements (such as periodicity, criticality of the deadlines, tolerance
9
to jitter, and so on). For this reason, a lot of different scheduling
10
algorithms and resource allocation protocols have been proposed to
11
conform to such different application demands, from the classical
12
fixed or dynamic priority allocation schemes to adaptive or feedback-based
13
systems.
14
 
15
However, most of the new approaches have been only theoretically analyzed,
16
and sometimes evaluated using a scheduling simulator. In this case,
17
the algorithm performance is not evaluated on real examples, but only
18
on a synthetic workload. This choice is often dictated from the fact
19
that writing a kernel from scratch every time a new scheduling algorithm
20
is proposed would be unrealistic and would not offer the availability
21
of meaningful applications. A more effective approach is to modify
22
an existing kernel (such as Linux), since most of the existing applications
23
and device drivers written for the host OS can be used in a straightforward
24
fashion. On the other hand, a general purpose kernel is designed aiming
25
at specific goals and generally its architecture is not modular enough
26
for replacing or modifying the scheduling policy. Moreover, classical
27
OSs do not allow to easily define a scheduling policy for resources
28
other than the CPU and this poses a further limitation for testing
29
novel research solutions. This is mainly due to the fact that the
30
classical OS structure does not permit a precise \emph{device scheduling}
31
(due to problems involving resource contention, priority inversion,
32
interrupt accounting, long non-preemptive sections, and so on). A
33
small kernel providing short non-preemptable sections, aperiodic real-time
34
threads for handling interrupts, and a distinction between \emph{device
35
drivers} accessing the hardware and \emph{device managers} implementing
36
the \emph{device scheduling} algorithms would help the progress in
37
this research field. The problems explained above emerge both in the
38
educational and research environments, when the focus is oriented
39
in developing and testing new scheduling algorithms rather than hacking
40
the code of a complex system.
41
 
42
S.Ha.R.K. (Soft and Hard Real-time Kernel), is a research kernel purposely
43
designed to help the implementation and testing of new scheduling
44
algorithms, both for the CPU and for other resources. The kernel can
45
be used to perform early validation of the scheduling algorithms produced
46
in the research labs, and to show the application of real-time scheduling
47
in real-time systems courses. These goals are fulfilled by making
48
a trade off between simplicity and flexibility of the programming
49
interface on one hand and efficiency on the other. This approach allows
50
a developer to focus his/her attention on the real algorithmic issues,
51
thus saving significant time in the implementation of new solutions.
52
Another important design guideline is the use of standard naming conventions
53
for the support libraries in order to ease the porting of meaningful
54
applications written for other platforms. The results have been satisfactory
55
for applications such as an MPEG player, a set of network drivers
56
and a FFT library.
57
 
58
The kernel provides the basic mechanisms for queue management and
59
dispatching and uses one or more external configurable modules to
60
perform scheduling decisions. These external modules can implement
61
periodic scheduling algorithms, soft task management through real-time
62
servers, semaphore protocols, and resource management policies. The
63
modules implementing the most common algorithms (such as RM, EDF,
64
Round Robin, and so on) are already provided, and it is easy to develop
65
new modules. Each new module can be created as a set of functions
66
that \emph{abstract} from the implementation of the other scheduling
67
modules and from the resource handling functions. Also the applications
68
can be developed independently from a particular system configuration,
69
so that new modules can be added or replaced to evaluate the effects
70
of specific scheduling policies in terms of predictability, overhead,
71
and performance. Low-level drivers for the most typical hardware resources
72
(like network cards, graphic cards, and hard disks) are also provided,
73
without imposing any form of device scheduling. In this way, device
74
scheduling can be implemented by the user to test new solutions. To
75
avoid the implementation of a new non-standard programming interface,
76
which would discourage people from using the kernel, S.Ha.R.K. implements
77
the standard POSIX 1003.13 PSE52 interface
78
%
79
% Tool: no such reference!
80
%
81
% \cite{POSIX1003.1,POSIX1003.13}
82
.
83
 
84
This manual was derived from the Hartik User Manual release 3.3.1.
85
 
86
%----------------------------------------------------------------------------
87
\section{General Description}
88
%----------------------------------------------------------------------------
89
 
90
S.Ha.R.K. has been designed as a library of functions which extends
91
the classical C library, by providing a multiprogramming environment
92
with an explicit management of time. From a logical point of view,
93
the system is based on a \emph{Host} computer where the application
94
is developed and on a \emph{Target} computer where the application
95
executes. Development tools are located on the host system, where
96
a general purpose operating system is used. After its compilation,
97
the application is loaded on the target system using the appropriate
98
\emph{loader}. This separation, typical of many hard real-time development
99
systems, enables the final application to run on a variety of target
100
systems, ranging from typical PC to embedded micro-controllers. From
101
a practical point of view, host and target may be the same computer
102
and in the rest of this manual we will not further distinguish between
103
them.
104
 
105
S.Ha.R.K. has been developed focusing on modularity of the kernel
106
source code. S.Ha.R.K. is fundamentally a set of routines that runs
107
on top of a library for OS development called OSLib (see http://oslib.sourceforge.net)
108
that has these requirements:
109
 
110
\begin{description}
111
 
112
\item [Operating~System~(OS)]You can compile OSLib/S.Ha.R.K. programs
113
using some different host OS. In theory, any OS supporting gcc can
114
be used; in practice, we successfully compiled OSLib/S.Ha.R.K. from
115
Linux, DOS and Cygwin.
116
 
117
\item [Compiler]The used compiler is gcc. You can use the gcc version that
118
you prefer (we tested gcc 3.3.3 and older version), the important
119
thing is that the linker must produce ELF binaries (in order to be
120
MultiBoot compliant and to avoid problems with the Linux source code
121
inside S.Ha.R.K.). An ELF cross-compile version of gcc is included
122
inside the DJGPP distribution on the S.Ha.R.K. website, so you can
123
easily compile OSLib/S.Ha.R.K. programs inside a standard DOS environment.
124
To compile under Cygwin, it is required to build an ELF cross-compile
125
gcc/linker couple.
126
 
127
\item [Other~utilities]GNU Make \index{Make}, uname, pwd, cp, rm, X (these
128
utilities can be found in the utility package on the S.Ha.R.K. web
129
site).
130
 
131
\item [Target~Requirements]The target have to be at least a PC based on
132
Intel 80486 (or compatible) - SMP is not supported - with at least
133
4Mb of RAM. In order to load OSLib/S.Ha.R.K. programs (MultiBoot compliant),
134
the target must have GRUB installed, or it must run a real mode operating
135
system (such as MS-DOS or FreeDOS). If you intend to boot OSLib/S.Ha.R.K.
136
programs from DOS, you also have to download our DOS eXtender X.
137
 
138
\end{description}
139
 
140
Compilation and application linking can be done using the \emph{make}\index{make}
141
utility, available in any of the development environments mentioned
142
above. In this case, a {}``makefile''\index{makefile} containing
143
the names of all of the .C files composing the application and the
144
directives to link the needed libraries have to be written. For more
145
information, you can look at the installation txt file from the website
146
download page.
147
 
148
%----------------------------------------------------------------------------
149
\section{SHARK.CFG}
150
%----------------------------------------------------------------------------
151
 
152
Inside \texttt{shark.cfg} you can find the main parameters for S.Ha.R.K.
153
configuration. All the stettings inside this file will be crucial
154
to run correctly S.Ha.R.K. and to get the maximum performaces on a
155
x86 machines. The most important options related to the Real-Time
156
behaviour are:
157
 
158
\begin{description}
159
\item MEM\_START = [number]
160
\end{description}
161
 
162
\begin{itemize}
163
\item Kernel image start point. The kernel image file will be loaded starting
164
from this physical memory address. Default value is 0x220000, but DOS users,
165
should set an high address (like 0x1720000) if Smartdrive or other tools which
166
require Extended Memory are used.
167
\end{itemize}
168
 
169
\begin{description}
170
\item TSC = [TRUE,FLASE]
171
\end{description}
172
 
173
\begin{itemize}
174
\item This option enables the Time Step Counter inside the CPU (Pentium
175
or higher). Kern\_gettime function will use the TSC register which
176
is faster and more precise than the external PIT. The default value
177
is TRUE. If the system cannot find the TSC, this feature will be disabled
178
and PIT will be used to get the system time.
179
\end{itemize}
180
 
181
\begin{description}
182
\item APIC = [TRUE,FALSE]
183
\end{description}
184
 
185
\begin{itemize}
186
\item This option enables the APIC (Pentium Pro or higher). As TSC, APIC
187
is faster and more precise than the standard PIT. It will be used
188
to generate the timer interrupts. The default value is TRUE. If the
189
system cannot find the APIC, the feature will be disabled. On some
190
embedded systems or old PC, the APIC check could hang the system,
191
so you must disable it manually. APIC requires the TSC.
192
\end{itemize}
193
 
194
\begin{description}
195
\item TIMER\_OPT = [1000,2000,4000,8000]
196
\end{description}
197
 
198
\begin{itemize}
199
\item Enable TSC read timer optimization. The 4 values are suggested for
200
different CPU speeds, allowing different wraparound performance: TIMER\_OPT =
201
1000 for CPU < 1 GHz, wraparound of 585 years; TIMER\_OPT = 2000 for 1 GHz <
202
CPU < 2 GHz, wraparound of 146 years; TIMER\_OPT = 4000 for 2 GHz < CPU < 4 GHz,
203
wraparound of36 years; TIMER\_OPT = 8000 for CPU < 8 GHz, wraparound of 292
204
years.
205
\end{itemize}
206
 
207
\begin{description}
208
\item TRACER = [NO,OLD,NEW]
209
\end{description}
210
 
211
\begin{itemize}
212
\item Select the tracer to be used for tracing events. While TRACER = OLD is for
213
backward compatibility, TRACER = NEW should be the preferred option when event
214
tracing is required. The event tracer can be disabled by selecting TRACER = NO.
215
\end{itemize}
216
 
217
\begin{description}
218
\item BIOS = [X,VM86]
219
\end{description}
220
 
221
\begin{itemize}
222
\item Select the BIOS interrupt access mode. BIOS = X means that you must use
223
x.exe as shark loader if shark needs to call BIOS interrupt (Ex. to enable
224
graphics); BIOS = VM86 means that shark call the BIOS interrupts as Virtual
225
Machine 86, and you can load a graphical demo also through GRUB.
226
\item Notice that VM86 MODE IS NOT COMPATIBLE WITH SOME VGA CARDS (like MATROX).
227
\end{itemize}
228
 
229
\begin{description}
230
\item FB = [VESA,FINDPCI,VGA16]
231
\end{description}
232
 
233
\begin{itemize}
234
\item Select the FrameBuffer configuration. It can use the VBE interrupts to
235
enable the selected video mode (VESA), or enable the VGA16 (4 bit per plane)
236
video mode (VGA16). Using FINDPCI, the FrameBuffer driver will try to find a
237
PCI/AGP graphical card. If a card is found, FB will use a specific driver to
238
enable it; however, few graphic adapters are currently supported with specific
239
drivers. Since almost all adapters support the VESA standard, FB = VESA is
240
usually the best choice.
241
\end{itemize}
242
 
243
\begin{description}
244
\item FG = [NORMAL,FORCE\_PXC]
245
\end{description}
246
 
247
\begin{itemize}
248
\item Select the FrameGrabber configuration. FORCE\_PXC forces the frame grabber to init a PXC200 card, and should be used carefully.
249
\end{itemize}
250
 
251
\begin{description}
252
\item SHARK\_FS = [YES,NO]
253
\end{description}
254
 
255
\begin{itemize}
256
\item Select the S.Ha.R.K. file system support. SHARK\_FS = YES makes the kernel
257
to include the File System library, which supports the FAT16 filesystem only. If
258
you don't have a FAT16 filesystem, set SHARK\_FS = NO.
259
\end{itemize}
260
 
261
\begin{description}
262
\item [{\Large NOTE:}]{\Large You must recompile S.Ha.R.K. if you modify}
263
\texttt{\Large shark.cfg}{\Large \par}
264
\end{description}
265
 
266
%----------------------------------------------------------------------------
267
\section{Predefined Types and Constants}
268
%----------------------------------------------------------------------------
269
 
270
Tables~\ref{t:types}, \ref{t:task}, \ref{t:stati}, \ref{t:limits}
271
show a subset of the predefined data types in S.Ha.R.K., a subset
272
of the possible task states and Models and the system basic constants.
273
 
274
\begin{table}
275
\begin{center}\begin{tabular}{|l|l|}
276
\hline
277
\emph{Type} & \emph{Description} \\
278
\hline
279
BYTE & unsigned char, {[}0, 255{]} \\
280
WORD & unsigned int, {[}0, 65535{]} \\
281
DWORD & unsigned long, {[}0, 0xFFFFFFFF{]} \\
282
TIME & unsigned long, {[}0, 0xFFFFFFFF{]} \\
283
PID & Task identifier \\
284
TASK & task \\
285
PORT & communication endpoints \\
286
CAB & cyclic asynchronous buffers  \\
287
\hline
288
\end{tabular}\end{center}
289
\caption{\label{t:types}Predefined types.}
290
\end{table}
291
 
292
\begin{table}
293
\begin{center}\begin{tabular}{|l|c|}
294
\hline
295
\emph{Identifier} & \emph{Value}\\
296
\hline
297
FREE & 0 \\
298
EXE & 1 \\
299
SLEEP & 2 \\
300
WAIT\_JOIN & 3 \\
301
WAIT\_COND & 4 \\
302
WAIT\_SIG & 5 \\
303
WAIT\_SEM & 6 \\
304
WAIT\_NANOSLEEP & 7\\
305
WAIT\_SIGSUSPEND & 8 \\
306
WAIT\_MQSEND & 9\\
307
WAIT\_MQRECEIVE & 10  \\
308
\hline
309
\end{tabular}\end{center}
310
 
311
\caption{\label{t:stati}Task states. (Note that a scheduling module can add
312
its private task states.)}
313
\end{table}
314
 
315
\begin{table}
316
\begin{center}\begin{tabular}{|l|c|}
317
\hline
318
\emph{Identifier} & Class \\
319
\hline
320
HARD\_TASK\_MODEL & Periodic and sporadic hard tasks \\
321
SOFT\_TASK\_MODEL & Periodic and aperiodic soft tasks\\
322
NRT\_TASK\_MODEL & Non-real-time tasks \\
323
JOB\_TASK\_MODEL & A task instance (job) that can be inserted into another module \\
324
DUMMY\_TASK\_MODEL & Model used for the Dummy Task \\
325
ELASTIC\_TASK\_MODEL & Elastic task, used with the Elastic Module \\
326
\hline
327
\end{tabular}\end{center}
328
 
329
\caption{\label{t:task}Basic Task Models included with the default distribution
330
(see include/kernel/model.h).}
331
\end{table}
332
 
333
\begin{table}
334
\begin{center}\begin{tabular}{|l|c|}
335
\hline
336
\emph{Identifier} & \emph{Value} \\
337
\hline
338
MAX\_PROC & 66 \\
339
MAX\_RUNLEVEL\_FUNC & 40 \\
340
JET\_TABLE\_DIM & 20 \\
341
MAX\_CANCPOINTS &  20 \\
342
MAX\_SIGINTPOINTS & 20 \\
343
MAX\_SCHED\_LEVEL &  16  \\
344
MAX\_RES\_LEVEL & 8 \\
345
MAX\_LEVELNAME & 20 \\
346
MAX\_MODULENAME & 20 \\
347
MAX\_TASKNAME & 20 \\
348
NIL & -1 \\
349
RUNLEVEL\_STARTUP & 0 \\
350
RUNLEVEL\_INIT & 1 \\
351
RUNLEVEL\_RUNNING & 3 \\
352
RUNLEVEL\_SHUTDOWN & 2 \\
353
RUNLEVEL\_BEFORE\_EXIT & 4 \\
354
RUNLEVEL\_AFTER\_EXIT & 5 \\
355
NO\_AT\_ABORT & 8 \\
356
\hline
357
\end{tabular}\end{center}
358
 
359
\caption{\label{t:limits}System constants (see include/kernel/const.h).}
360
\end{table}
361