Subversion Repositories shark

Compare Revisions

Ignore whitespace Rev 1675 → Rev 1676

/sharkdoc/branches/new_sharkdoc/vol1/vol1.tex
0,0 → 1,77
\documentclass[italian,english]{report}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage{geometry}
\geometry{verbose,a4paper}
\usepackage{array}
\usepackage{longtable}
\usepackage{makeidx}
\makeindex
\usepackage{graphicx}
 
\makeatletter
 
%% Special footnote code from the package 'stblftnt.sty'
%% Author: Robin Fairbairns -- Last revised Dec 13 1996
\let\SF@@footnote\footnote
\def\footnote{\ifx\protect\@typeset@protect
\expandafter\SF@@footnote
\else
\expandafter\SF@gobble@opt
\fi
}
\expandafter\def\csname SF@gobble@opt \endcsname{\@ifnextchar[%]
\SF@gobble@twobracket
\@gobble
}
\edef\SF@gobble@opt{\noexpand\protect
\expandafter\noexpand\csname SF@gobble@opt \endcsname}
\def\SF@gobble@twobracket[#1]#2{}
 
\newenvironment{intest}{\noindent\large\bf\hspace*{1pt}}
{\vspace*{-5pt}\\\line(1,0){433}}
 
\usepackage{babel}
\makeatother
 
\begin{document}
\thispagestyle{empty}
 
\begin{center}{\LARGE S.Ha.R.K. User Manual}\end{center}{\LARGE \par}
\vfill{}
\begin{center}Volume I \end{center}
\begin{center}Kernel Primitives\end{center}
\vfill{}
\begin{center}Written by\end{center}
\begin{center}Giorgio Buttazzo (giorgio at sssup.it)\end{center}
\begin{center}Paolo Gai (pj at sssup.it)\end{center}
\begin{center}Luigi Palopoli (luigi at hartik.sssup.it)\end{center}
\begin{center}Marco Caccamo (caccamo at sssup.it)\end{center}
\begin{center}Giuseppe Lipari (lipari at sssup.it) \end{center}
\begin{center}Tullio Facchinetti (tullio.facchinetti at unipv.it)\end{center}
\vfill{}
 
\begin{center}\includegraphics[width=2cm]{../common/sssup.ps}\end{center}
 
\begin{center}Scuola Superiore di Studi e Perfezionamento S. Anna\end{center}
\begin{center}RETIS Lab\end{center}
\begin{center}Via Carducci, 40 - 56100 Pisa\end{center}
\begin{center}\pagebreak\end{center}
 
\tableofcontents{}
 
\include{introd}
\include{sys}
\include{semaf}
\include{util}
 
\appendix
 
\include{errors}
 
\printindex{}
 
\bibliographystyle{alpha}
\bibliography{../common/biblio}
 
\end{document}
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol1/over.eps
===================================================================
--- branches/new_sharkdoc/vol1/over.eps (nonexistent)
+++ branches/new_sharkdoc/vol1/over.eps (revision 1676)
@@ -0,0 +1,217 @@
+%!PS-Adobe-2.0 EPSF-2.0
+%%Title: over.fig
+%%Creator: fig2dev Version 3.2 Patchlevel 1
+%%CreationDate: Wed Jul 12 11:38:50 2000
+%%For: pj@galadriel (Paolo Gai)
+%%Orientation: Portrait
+%%BoundingBox: 0 0 248 135
+%%Pages: 0
+%%BeginSetup
+%%EndSetup
+%%Magnification: 1.0000
+%%EndComments
+/$F2psDict 200 dict def
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/col-1 {0 setgray} bind def
+/col0 {0.000 0.000 0.000 srgb} bind def
+/col1 {0.000 0.000 1.000 srgb} bind def
+/col2 {0.000 1.000 0.000 srgb} bind def
+/col3 {0.000 1.000 1.000 srgb} bind def
+/col4 {1.000 0.000 0.000 srgb} bind def
+/col5 {1.000 0.000 1.000 srgb} bind def
+/col6 {1.000 1.000 0.000 srgb} bind def
+/col7 {1.000 1.000 1.000 srgb} bind def
+/col8 {0.000 0.000 0.560 srgb} bind def
+/col9 {0.000 0.000 0.690 srgb} bind def
+/col10 {0.000 0.000 0.820 srgb} bind def
+/col11 {0.530 0.810 1.000 srgb} bind def
+/col12 {0.000 0.560 0.000 srgb} bind def
+/col13 {0.000 0.690 0.000 srgb} bind def
+/col14 {0.000 0.820 0.000 srgb} bind def
+/col15 {0.000 0.560 0.560 srgb} bind def
+/col16 {0.000 0.690 0.690 srgb} bind def
+/col17 {0.000 0.820 0.820 srgb} bind def
+/col18 {0.560 0.000 0.000 srgb} bind def
+/col19 {0.690 0.000 0.000 srgb} bind def
+/col20 {0.820 0.000 0.000 srgb} bind def
+/col21 {0.560 0.000 0.560 srgb} bind def
+/col22 {0.690 0.000 0.690 srgb} bind def
+/col23 {0.820 0.000 0.820 srgb} bind def
+/col24 {0.500 0.190 0.000 srgb} bind def
+/col25 {0.630 0.250 0.000 srgb} bind def
+/col26 {0.750 0.380 0.000 srgb} bind def
+/col27 {1.000 0.500 0.500 srgb} bind def
+/col28 {1.000 0.630 0.630 srgb} bind def
+/col29 {1.000 0.750 0.750 srgb} bind def
+/col30 {1.000 0.880 0.880 srgb} bind def
+/col31 {1.000 0.840 0.000 srgb} bind def
+
+end
+save
+-23.0 148.0 translate
+1 -1 scale
+
+/cp {closepath} bind def
+/ef {eofill} bind def
+/gr {grestore} bind def
+/gs {gsave} bind def
+/sa {save} bind def
+/rs {restore} bind def
+/l {lineto} bind def
+/m {moveto} bind def
+/rm {rmoveto} bind def
+/n {newpath} bind def
+/s {stroke} bind def
+/sh {show} bind def
+/slc {setlinecap} bind def
+/slj {setlinejoin} bind def
+/slw {setlinewidth} bind def
+/srgb {setrgbcolor} bind def
+/rot {rotate} bind def
+/sc {scale} bind def
+/sd {setdash} bind def
+/ff {findfont} bind def
+/sf {setfont} bind def
+/scf {scalefont} bind def
+/sw {stringwidth} bind def
+/tr {translate} bind def
+/tnt {dup dup currentrgbcolor
+ 4 -2 roll dup 1 exch sub 3 -1 roll mul add
+ 4 -2 roll dup 1 exch sub 3 -1 roll mul add
+ 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
+ bind def
+/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+ 4 -2 roll mul srgb} bind def
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+%%EndProlog
+
+$F2psBegin
+10 setmiterlimit
+n -1000 1164 m -1000 -1000 l 1301 -1000 l 1301 1164 l cp clip
+ 0.90000 0.90000 sc
+% Polyline
+0.500 slw
+n 44 143 m 44 149 l gs col-1 s gr
+% Polyline
+n 59 143 m 59 149 l gs col-1 s gr
+% Polyline
+n 74 143 m 74 149 l gs col-1 s gr
+% Polyline
+n 89 143 m 89 149 l gs col-1 s gr
+% Polyline
+n 104 143 m 104 149 l gs col-1 s gr
+% Polyline
+n 119 143 m 119 149 l gs col-1 s gr
+% Polyline
+n 134 143 m 134 149 l gs col-1 s gr
+% Polyline
+n 149 143 m 149 149 l gs col-1 s gr
+% Polyline
+n 164 143 m 164 149 l gs col-1 s gr
+% Polyline
+n 179 143 m 179 149 l gs col-1 s gr
+% Polyline
+n 194 143 m 194 149 l gs col-1 s gr
+% Polyline
+n 209 143 m 209 149 l gs col-1 s gr
+% Polyline
+n 224 143 m 224 149 l gs col-1 s gr
+% Polyline
+n 239 143 m 239 149 l gs col-1 s gr
+% Polyline
+n 254 143 m 254 149 l gs col-1 s gr
+% Polyline
+n 269 143 m 269 149 l gs col-1 s gr
+% Polyline
+n 284 143 m 284 149 l gs col-1 s gr
+% Polyline
+n 44 68 m 44 74 l gs col-1 s gr
+% Polyline
+n 59 68 m 59 74 l gs col-1 s gr
+% Polyline
+n 74 68 m 74 74 l gs col-1 s gr
+% Polyline
+n 89 68 m 89 74 l gs col-1 s gr
+% Polyline
+n 104 68 m 104 74 l gs col-1 s gr
+% Polyline
+n 119 68 m 119 74 l gs col-1 s gr
+% Polyline
+n 134 68 m 134 74 l gs col-1 s gr
+% Polyline
+n 149 68 m 149 74 l gs col-1 s gr
+% Polyline
+n 164 68 m 164 74 l gs col-1 s gr
+% Polyline
+n 179 68 m 179 74 l gs col-1 s gr
+% Polyline
+n 194 68 m 194 74 l gs col-1 s gr
+% Polyline
+n 209 68 m 209 74 l gs col-1 s gr
+% Polyline
+n 224 68 m 224 74 l gs col-1 s gr
+% Polyline
+n 239 68 m 239 74 l gs col-1 s gr
+% Polyline
+n 269 68 m 269 74 l gs col-1 s gr
+% Polyline
+n 284 68 m 284 74 l gs col-1 s gr
+% Polyline
+n 59 149 m 59 134 l 29 134 l 29 149 l cp gs 0.60 setgray ef gr gs col-1 s gr
+% Polyline
+n 119 149 m 119 134 l 89 134 l 89 149 l cp gs 0.60 setgray ef gr gs col-1 s gr
+% Polyline
+n 179 149 m 179 134 l 149 134 l 149 149 l cp gs 0.60 setgray ef gr gs col-1 s gr
+% Polyline
+n 284 149 m 284 134 l 254 134 l 254 149 l cp gs 0.60 setgray ef gr gs col-1 s gr
+% Polyline
+n 89 74 m 89 59 l 59 59 l 59 74 l cp gs 0.80 setgray ef gr gs col-1 s gr
+% Polyline
+n 254 74 m 254 59 l 209 59 l 209 74 l cp gs 0.80 setgray ef gr gs col-1 s gr
+/Times-Roman ff 10.00 scf sf
+26 164 m
+gs 1 -1 sc (0) col0 sh gr
+/Times-Roman ff 10.00 scf sf
+86 164 m
+gs 1 -1 sc (4) col0 sh gr
+/Times-Roman ff 10.00 scf sf
+146 164 m
+gs 1 -1 sc (8) col0 sh gr
+/Times-Roman ff 10.00 scf sf
+206 164 m
+gs 1 -1 sc (12) col0 sh gr
+/Times-Roman ff 10.00 scf sf
+266 164 m
+gs 1 -1 sc (16) col0 sh gr
+% Polyline
+n 77 17 m 77 17 l 77 17 l 77 17 l cp gs 0.75 setgray ef gr gs col0 s gr
+% Polyline
+n 29 74 m 299 74 l gs col-1 s gr
+% Polyline
+n 29 119 m 29 149 l 299 149 l gs col-1 s gr
+% Polyline
+n 89 119 m 89 149 l gs col-1 s gr
+% Polyline
+n 149 119 m 149 149 l gs col-1 s gr
+% Polyline
+n 209 119 m 209 149 l gs col-1 s gr
+% Polyline
+n 269 119 m 269 149 l gs col-1 s gr
+% Polyline
+n 29 149 m 29 152 l gs col-1 s gr
+% Polyline
+n 89 149 m 89 152 l gs col-1 s gr
+% Polyline
+n 149 149 m 149 152 l gs col-1 s gr
+% Polyline
+n 209 149 m 209 152 l gs col-1 s gr
+% Polyline
+n 269 149 m 269 152 l gs col-1 s gr
+% Polyline
+n 29 44 m 29 74 l gs col-1 s gr
+% Polyline
+n 254 44 m 254 74 l gs col-1 s gr
+$F2psEnd
+rs
/branches/new_sharkdoc/vol1/over.eps
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol1/semaf.tex
===================================================================
--- branches/new_sharkdoc/vol1/semaf.tex (nonexistent)
+++ branches/new_sharkdoc/vol1/semaf.tex (revision 1676)
@@ -0,0 +1,1155 @@
+%----------------------------------------------------------------------------
+\chapter{Synchronization and communication}
+%----------------------------------------------------------------------------
+
+This chapter describes the task's interaction capabilities provided by the
+S.Ha.R.K. kernel. In order to improve the programming flexibility without
+jeopardizing the hard tasks' a priori guarantee, the kernel implements different
+mechanisms.
+
+In general, hard tasks should not use system calls that can cause an unbounded
+(or unknown) blocking time, since they can jeopardize the system schedulability.
+
+\begin{figure}
+\begin{center}\includegraphics{over.eps}\end{center}
+\caption{EDF Scheduling - Overload due to a task\_delay().}
+\label{fg:semaf-over}
+\end{figure}
+
+For example, consider Figure~\ref{fg:semaf-over}: in this case there are two
+periodic tasks, $\tau_{1}$ (execution time $C_{1}=5$ and period $T_{1}=15$) and
+$\tau_{2}$ (execution time $C_{2}=2$ and period $T_{2}=4$). Since the total
+utilization factor is $U=1/2+1/3=5/6<1$, the system is schedulable by EDF, but
+if $\tau_{1}$ blocks for $8$ time units at time $t=4$, $\tau_{2}$ misses a
+deadline at time $t=16$.
+
+For efficiency reasons, the system does not perform any check to avoid the use
+of blocking primitives in hard tasks; so this aspect is left to the programmer
+responsibility.
+
+%----------------------------------------------------------------------------
+\section{POSIX Semaphores}
+%----------------------------------------------------------------------------
+
+The primitives described in this Section covers the semaphore mechanism
+interface that can be used by the S.Ha.R.K. applications. The semaphore
+interface directly follows the POSIX semaphore interface; the S.Ha.R.K. Kernel
+add also some other primitives that allows to increment/decrement the semaphore
+counter by more than one unit at a time.
+
+These primitives can be used both for synchronization and mutual exclusion. It
+is worth noting that the traditional semaphore mechanism can cause unbounded
+\emph{priority inversion}, so it is not suitable for hard real-time tasks.
+Concerning the synchronization, we note that the guarantee mechanism does not
+take synchronization into account; therefore the programmer should avoid to
+explicitly synchronize hard tasks by means of blocking primitives. It is instead
+possible to use a weak synchronization between hard real-time tasks, realized
+through non-blocking semaphores.
+
+Only \texttt{SEM\_NSEMS\_MAX} semaphores can be created in the system. If an
+application needs to use the POSIX semaphores, it have to add the call to the
+function
+
+\texttt{void SEM\_register\_module(void);}
+
+into the \texttt{\_\_kernel\_register\_levels\_\_} function of the
+initialization file (see Volume III - S.Ha.R.K. Modules).
+
+In this section will be briefly described the POSIX semaphore interface
+\footnote{This section only described unnamed semaphores. The interface for
+named semaphores is also provided, althoutgh it does not use a file system but
+resolve the names internally (as allowed by the POSIX 1003.13 PSE51 profile).}.
+For a complete reference see the POSIX standard (the Linux manpage also works
+well).
+
+%----------------------------------------------------------------------------
+\begin{intest}
+SEM\_INIT\index{sem\_init()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int sem\_init(sem\_t {*}sem, int pshared, unsigned int value);}]
+
+\item [\textbf{Description:}] It is used to initialize a semaphore referred by
+sem. The value of the initialized semaphore is \texttt{value}. The pshared
+argument is ignored. After the call to the primitive, the sem value can bve used
+to refer the semaphore.
+
+\item [\textbf{Return value:}] on successful completion, the function
+initializes the semaphore in sem and returns 0. Otherwise, it returns -1 and
+\texttt{errno} is set according to the POSIX standard.
+
+\item [\textbf{See also}:] sem\_wait(), sem\_trywait, sem\_post(),
+sem\_destroy().
+
+\end{description}
+
+\begin{description}
+\item \texttt{[Example]}
+\end{description}
+
+\begin{verbatim}
+sem_t mutex;
+
+TASK demo(void *arg) {
+ ...
+
+ /* The task enters a critical section protected by a mutex semaphore */
+ sem_wait(&mutex);
+ <critical section>
+ sem_post(&mutex);
+ ...
+}
+
+int main(int argc, char**argv) {
+ ...
+ sem_init(&mutex, 0, 1);
+ ...
+}
+\end{verbatim}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+SEM\_DESTROY\index{sem\_destroy()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int sem\_destroy(sem\_t {*}sem);}]
+
+\item [\textbf{Description:}] It is used to destroy the semaphore indicated by
+sem. Only a semaphore that was created using sem\_init() may be destroyed using
+sem\_destroy(). \textbf{Warning}: This system call does not check if the
+semaphore queue is empty or not, and does not awake tasks blocked on the
+semaphore. The programmer has to make sure that \texttt{s} is free before
+destroying it.
+
+\item [\textbf{Return value}:] on successful completion, the function destroys
+the sem semaphore and returns 0. Otherwise, it returns -1 and \texttt{errno} is
+set according to the POSIX standard.
+
+\item [\textbf{See also}:] sem\_init().
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+SEM\_WAIT\index{sem\_wait()} and SEM\_TRYWAIT\index{sem\_trywait()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int sem\_wait(sem\_t {*}sem);}]
+
+\item [\textbf{int sem\_trywait(sem\_t {*}sem);}]
+
+\item [\textbf{Description:}] is used to lock the semaphore referenced by
+\texttt{sem}. If the semaphore value is currently zero, then the calling task
+shall not return from the call to \texttt{sem\_wait}() until it either locks the
+semaphore. \texttt{sem\_trywait} locks the semaphore referenced by \texttt{sem}
+only if the semaphore is currently not locked; that is, if the semaphore value
+is currently positive. Otherwise, it does not lock the semaphore.
+\texttt{sem\_wait} is a cancellation point.
+
+\item [\textbf{Return value:}] on successful completion the functions return 0.
+Otherwise, they return -1 and \texttt{errno} is set according to the POSIX
+standard.
+
+\item [\textbf{See also}:] sem\_post().
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+SEM\_XWAIT\index{sem\_wait()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{BYTE sem\_xwait(sem\_t {*}s, int n, int wait);}]
+
+\item [Description:]\texttt{sem\_xwait()} is a non-portable extension to the
+POSIX semaphores that decreases the semaphore counter by \texttt{n}. If the
+counter is greater than or equal to \texttt{n} and there are no tasks blocked on
+semaphore \texttt{s}, the counter is decreased by \texttt{n} and
+\texttt{sem\_xwait} returns 0, otherwise the system call's behavior depends on
+the \texttt{b} parameter. If \texttt{wait} is \texttt{BLOCK}, the calling task
+blocks on the semaphore, if \texttt{wait} is \texttt{NON\_BLOCK}
+\texttt{sem\_xwait} returns -1, errno is set to EAGAIN and the calling task does
+not block. The semaphore queue is ordered using a FIFO strategy, in order to
+avoid starvation. Hard tasks should not use blocking system calls, so it is
+suggested to use \texttt{sem\_trywait()/xwait()} (only with \texttt{b =
+NON\_BLOCK}). \texttt{sem\_xwait} is a cancellation point.
+
+\item [\textbf{Return value:}] on successful completion, the function returns 0.
+Otherwise, it returns -1 and \texttt{errno} is set according to the POSIX
+standard.
+
+\item [\textbf{See also}:] sem\_wait(), sem\_trywait(), sem\_post().
+
+\end{description}
+
+\begin{description}
+\item [\textbf{Example:}]
+\end{description}
+
+\begin{verbatim}
+sem_t sync;
+
+TASK demo(void *arg) {
+ ...
+ /* The demo task synchronizes itself */
+ /* with the wake task, waiting */
+ /* for 5 signals on the sync semaphore */
+ sem_xwait(&sync, 5, BLOCK);
+ ...
+}
+
+TASK wake(void *arg) {
+ while (1) {
+ ...
+ sem_xsignal(sync, 1);
+ ...
+ task_endcycle();
+ }
+}
+
+void main(void) {
+ ...
+ sem_init(&sync, 0, 0);
+ ...
+}
+\end{verbatim}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+SEM\_POST\index{sem\_post()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int sem\_post(sem\_t {*}sem);}]
+
+\item [\textbf{Description:}]It unlocks the semaphore referenced by sem by
+performing the semaphore unlock operation on that semaphore. If the semaphore
+queue is not empty and the first task in the queue requests a feasible counter
+decrement, it can be awaken. The task is put in the ready queue and the
+scheduler is invoked: for this reason this system call can cause a preemption.
+The semaphore queue is a FIFO queue: tasks are awoken in a FIFO order according
+to resource availability.
+
+\item [\textbf{Return value:}] on successful completion, the function destroys
+the sem semaphore and returns 0. Otherwise, it returns -1 and \texttt{errno} is
+set according to the POSIX standard.
+
+\item [\textbf{See also}:] sem\_wait(), sem\_trywait().
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+SEM\_XPOST\index{sem\_xpost()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int sem\_xpost(sem\_t {*}s, int n);}]
+
+\item [\textbf{Description:}]\texttt{sem\_xpost()} is a non-portable extension
+to the POSIX semaphores that implements the classical signal primitive on
+semaphore \texttt{s}, increasing the counter by \texttt{n}. If the semaphore
+queue is not empty and the first task in the queue requests a feasible counter
+decrement, it can be awaken. The task is put in the \texttt{READY} queue and the
+scheduler is invoked: for this reason this system call can cause a preemption.
+The semaphore queue is a FIFO queue: tasks are awoken in a FIFO order according
+to resource availability.
+
+\item [\textbf{Return value:}] on successful completion, the function destroys
+the sem semaphore and returns 0. Otherwise, it returns -1 and \texttt{errno} is
+set according to the POSIX standard.
+
+\item [\textbf{See also}:] \texttt{sem\_init(), sem\_wait(), sem\_destroy()}.
+
+\item [Example:]see \texttt{sem\_wait()}.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+SEM\_GETVALUE\index{sem\_getvalue()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int sem\_getvalue(sem\_t {*}sem, int {*}sval);}]
+
+\item [\textbf{Description:}]\texttt{sem\_getvalue()} updates the location
+referenced by the sval argument to have the value of the semaphore referenced by
+sem without affecting the state of the semaphore. If sem is locked the value
+returned by sem\_getvalue is a negative number whose absolute value represents
+the number of processes waiting for the semaphore at some unspecified time
+during the call.
+
+\item [\textbf{Return value:}] on successful completion, the function destroys
+the sem semaphore and returns 0. Otherwise, it returns -1 and \texttt{errno} is
+set according to the POSIX standard.
+
+\item [\textbf{See also}:] \texttt{sem\_init(), sem\_wait(), sem\_destroy()}.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Internal Semaphores}
+%----------------------------------------------------------------------------
+
+When developing a complex driver of the kernel, a designer usually needs to
+manage a lot of shared resources that have to be accessed in mutual exclusion,
+and needs also a lot of synchronization points that are not cancellation points.
+For these pourposes the POSIX semaphores are not good because they are limited
+in number and they are cancellation points.
+
+For this pourpose the S.Ha.R.K. Kernel provides a sort of lightweight semaphores
+called \emph{internal} semaphores, that fulfill the designer needs \footnote{The
+existence of two type of semaphores is not new in Kernel development; For
+example, the Linux Kernel differentiate the semaphores used by the applications
+and the semaphors used by the Kernel.}: they are not cancellation points and
+there is no limit on the number of semaphores that can be created in a system
+\footnote{Only 8 bytes are taken for each internal semaphore. In some sense the
+internal semaphores are similar to the POSIX mutexes...}. The interface of the
+Internal semaphores is very similar to POSIX semaphore interface.
+
+To use the Internal Semaphores, you don't need to call any registration function
+at kernel startup time.
+
+%----------------------------------------------------------------------------
+\begin{intest}
+INTERNAL\_SEM\_INIT\index{internal\_sem\_init()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{void internal\_sem\_init(internal\_sem\_t {*}s, int value);}]
+
+\item [\textbf{Description:}]It initializes the internal semaphore \texttt{s}
+with a specified \texttt{value}.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+INTERNAL\_SEM\_WAIT\index{internal\_sem\_wait()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{void internal\_sem\_wait(internal\_sem\_t {*}s);}]
+
+\item [\textbf{Description:}]It implements a blocking wait. the semaphore
+counter is decremented by one.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+INTERNAL\_SEM\_TRYWAIT\index{internal\_sem\_trywait()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int internal\_sem\_trywait(internal\_sem\_t {*}s);}]
+
+\item [\textbf{Description:}]It implements a non-blocking wait. It returns 0 if
+the counter is decremented, -1 if not.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+INTERNAL\_SEM\_POST\index{internal\_sem\_post()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{void internal\_sem\_post(internal\_sem\_t {*}s);}]
+
+\item [\textbf{Description:}]It implements a post operation.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+INTERNAL\_SEM\_GETVALUE\index{internal\_sem\_getvalue()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int internal\_sem\_getvalue(internal\_sem\_t {*}s);}]
+
+\item [\textbf{Description:}]It returns a value greater or equal 0 if there are
+no tasks blocked on s, -1 otherwise.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Mutexes and Condition Variables}
+%----------------------------------------------------------------------------
+
+The primitives described in this section allows the user to define and use
+\emph{mutexes} and \emph{condition variables}. A mutex can be thought as a
+binary semaphore initialized to 1. In that way, a critical section can be
+specified using the \emph{mutex\_lock} and \emph{mutex\_unlock} primitives.
+Moreover, using condition variables a task can block itself waiting for an
+event.
+
+The provided implementation extends the POSIX standard mutex functions
+implementing protocols like Stack Resource Policy and Non Preemptive
+Protocol, that are not part of the standard. To do that, the mutex
+initialization interface is different from the standard to allow the
+specification of the various policies. In any case, the standard interface
+is provided based on the extended interface.
+
+%----------------------------------------------------------------------------
+\subsection{Mutex attributes}
+%----------------------------------------------------------------------------
+
+A mutex can be used to implement critical sections that uses different
+policies (for example, the Priority Inheritance, Priority Ceiling
+or Stack Resource Policy protocol). The S.Ha.R.K. Kernel provides
+a set of structures derived from the basic structure mutexattr\_t
+\footnote{Similar to the pthread\_mutexattr\_t structures of the POSIX
+standard.} that allow to handle the specification of different policies.
+
+The mutex attributes are different foe every policy, that is implemented
+by a Resouce Module. To see the the description of the mutex attributes
+for every policy, look at the S.Ha.R.K. Modules Manual.
+
+%----------------------------------------------------------------------------
+\subsection{Functions}
+%----------------------------------------------------------------------------
+
+This subsection describes the functions that handle mutexes and condition
+variables.
+
+%----------------------------------------------------------------------------
+\begin{intest}
+MUTEX\_INIT\index{mutex\_init()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int mutex\_init(mutex\_t {*}mutex, const mutexattr\_t {*}attr);}]
+
+\item [\textbf{Description:}]The mutex\_init function inituializes the mutex
+referenced by \emph{mutex} with attributes specified by \emph{attr}. \emph{attr}
+shall be not equal NULL. Upon successful initialization, the state
+of the mutex becomes initialized and unlocked.
+
+\item [\textbf{Return value:}] on successful completion the functions return
+0. Otherwise, they return -1 and \texttt{errno} is set according to
+the POSIX standard.
+
+\item [\textbf{See also}:] mutex\_destroy().
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+MUTEX\_DESTROY\index{mutex\_destroy()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int mutex\_destroy(mutex\_t {*}mutex);}]
+
+\item [\textbf{Description:}]The mutex\_destroy function destroys the mutex
+object
+referenced by mutex. It is safe to destroy an initialize mutex that
+is unlocked.
+
+\item [\textbf{Return value:}] on successful completion the functions return
+0. Otherwise, they return -1 and \texttt{errno} is set according to
+the POSIX standard.
+
+\item [\textbf{See also}:] mutex\_init().
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+MUTEX\_LOCK\index{mutex\_lock()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int mutex\_lock(mutex\_t {*}mutex);}]
+
+\item [\textbf{Description:}]The mutex\_lock function locks an unlocked mutex.
+If
+the mutex is already locked , the calling thread waits until the mutex
+becomes available. the behaviour of the function may change depending
+on the particular policy passed with the mutexattr\_t parameter at
+mutex initialization. The function is \emph{not} a cancellation point.
+
+\item [\textbf{Return value:}] on successful completion the functions return
+0. Otherwise, they return -1 and \texttt{errno} is set according to
+the POSIX standard.
+
+\end{description}
+
+\pagebreak
+
+%----------------------------------------------------------------------------
+\begin{intest}
+MUTEX\_TRYLOCK\index{mutex\_trylock()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int mutex\_lock(mutex\_t {*}mutex);}]
+
+\item [\textbf{Description:}]The mutex\_trylock function is identycal to
+mutex\_lock
+except that if the mutex us locked when the function is called, the
+calling task does not block but returns -1 and an errno value of EBUSY,
+as specified by the POSIX standard.
+
+\item [\textbf{Return value:}] on successful completion the functions return
+0. Otherwise, they return -1 and \texttt{errno} is set according to
+the POSIX standard.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+MUTEX\_UNLOCK\index{mutex\_unlock()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int mutex\_unlock(mutex\_t {*}mutex);}]
+
+\item [\textbf{Description:}]The mutex\_unlock function is called by the owner
+of
+the mutex object to release it. If there are thread blocked on the
+mutex object referenced by mutex when mutex\_lock is called, the mutex
+becomes available, and the task that will acquire the mutex depends
+on the policy with that the mutex was initialized.
+
+\item [\textbf{Return value:}] on successful completion the functions return
+0. Otherwise, they return -1 and \texttt{errno} is set according to
+the POSIX standard.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+COND\_INIT\index{cond\_init()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int cond\_init(cond\_t {*}cond);}]
+
+\item [\textbf{Description:}]The function initializes the condition variable
+referenced
+by cond.
+
+\item [\textbf{Return value:}] on successful completion the functions return
+0. Otherwise, they return -1 and \texttt{errno} is set according to
+the POSIX standard.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+COND\_DESTROY\index{cond\_destroy()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int cond\_destroy(cond\_t {*}cond);}]
+
+\item [\textbf{Description:}]The function destroys the given condition variable
+specified by cond.
+
+\item [\textbf{Return value:}] on successful completion the functions return
+0. Otherwise, they return -1 and \texttt{errno} is set according to
+the POSIX standard.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+COND\_SIGNAL\index{cond\_signal()} and COND\_BROADCAST\index{cond\_broadcast()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int cond\_signal(cond\_t {*}cond);}]
+
+\item [\textbf{int cond\_broadcast(cond\_t {*}cond);}]
+
+\item [\textbf{Description:}]The function cond\_signal unblocks at least one of
+the threads that are blocked on the specified condition variable cond.
+The function cond\_broadcast unblocks all threads currently blocked
+on the specified condition variable cond. These functions have no
+effect if there are no threads currently blocked on cond.
+
+\item [\textbf{Return value:}] on successful completion the functions return
+0. Otherwise, they return -1 and \texttt{errno} is set according to
+the POSIX standard.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+COND\_WAIT\index{cond\_wait()} and COND\_TIMEDWAIT\index{cond\_timedwait()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int cond\_wait(cond\_t {*}cond, mutex\_t {*}mutex);}]
+
+\item [\textbf{int cond\_timedwait(cond\_t {*}cond, mutex\_t {*}mutex,
+const struct timespec {*}abstime);}]
+
+\item [\textbf{Description:}]These functions are used to block on a condition
+variable.
+They shall be called with \emph{mutex} locked by the calling task.
+These functions release mutex and cause the calling task to block
+on the condition variable cond. Upon successful return, the mutex
+is locked and is owned by the calling task. When using condition variables,
+there is always a Boolean predicate involving shared variables associated
+with each condition wait that is true if the thread should proceed.
+Spurious wakeups from the \texttt{cond\_wait} or \texttt{cond\_timedwait}
+functions may occur. Since the return from \texttt{cond\_wait} or
+\texttt{cond\_timedwait} does not imply anything about the value of
+this predicate, the predicate should be re-evaluated upon each return.
+
+The \texttt{cond\_wait} and cond\_timedwait functions are cancellation
+points. When the cancelability enable state of a task is set to
+\texttt{TASK\_CANCEL\_DEFERRED},
+a side effect of acting upon a cancellation request while in a condition
+wait is that the mutex is (in effect) reaquired before calling the
+first cancellation cleanup handler. To ensure a correct cancellation,
+a cleanup function should be pushed before the \texttt{cond\_wait}
+call (in case of cancellation it simply unlock the mutex).
+
+The \texttt{cond\_timedwait} function is the same as the \texttt{cond\_wait}
+function except that an error is returned if the absolute time specified
+by abstime passes before the condition cond is signaled or broadcasted,
+or if the absolute time specified by abstime has already been passed
+at the time of the call.
+
+\item [\textbf{Return value:}] on successful completion the functions return
+0. Otherwise, they return -1 and \texttt{errno} is set according to
+the POSIX standard.
+
+\end{description}
+
+%
+% Tool: still in use?
+%
+
+% %----------------------------------------------------------------------------
+% \section{Communication Ports \footnote{The S.Ha.R.K. communication ports are
+% directly derived from the previous varsions of the Hartik Kernel.}}
+% %----------------------------------------------------------------------------
+%
+% S.Ha.R.K. communication ports allow tasks to exchange messages. Each
+% port is uniquely identified by a symbolic name (i.e., a string of
+% characters); a task willing to use this communication facility has
+% to open the channel using the \texttt{port\_create()} call, thus becoming
+% the owner of the resource. Any other task that wants to use this communication
+% end-point to send or receive data needs to connect to it by using
+% the \texttt{port\_connect()} primitive.
+%
+% S.Ha.R.K. offers three types of ports:
+%
+% \begin{itemize}
+%
+% \item \texttt{STREAM}: it is a one-to-one communication facility, which
+% can be opened either by the reader or by the writer task. The task
+% executing the \texttt{port\_create()} must specify the message size
+% and maximum number of messages in the queue. The task executing the
+%
+% \texttt{port\_connect()} must only specify the size of the messages
+% it wants to receive/send, which can be different from the one specified
+% by the owner. For example, a task may open a port for reading messages
+% of 4 bytes, while another task can connect to it to write one-byte
+% messages. This mechanism turns out to be useful for character oriented
+% device drivers which need to fill a given structure, before the message
+% can be processed further by a higher-level task.
+%
+% \item \texttt{MAILBOX}: it is a many-to-one communication facility, thought
+% for being used in classical client/server mechanisms. This kind of
+% port can only be opened by the reader task (the server) which wants
+% to receive data from writer tasks (the clients). Message size is fixed
+% and defined by the reader.
+%
+% \item \texttt{STICK}: it is a one-to-many communication facility intended
+% to be used for exchanging periodic state-messages, for which the most
+% recent information is relevant. It can be opened only by the (unique)
+% writer task and the reading tasks must connect to it. It contains
+% just one message and any new message posted by the writer will overwrite
+% the previous one. Messages are non-consumable: a reader task can perform
+% many readings of a given message until the writer posts a new one.
+% \end{itemize}
+%
+% The first two kinds of port implement the synchronous communication
+% paradigm, while \texttt{STICK} ports implement an asynchronous (state-message)
+% paradigm. It is worth noting that in order to protect the internal
+% data structures, \texttt{STREAM} ports use semaphores for synchronizing
+% the accesses, \texttt{STICK} ports just use a mutual exclusion semaphore,
+% and the \texttt{MAILBOX} ports use both kinds of semaphores.
+%
+% For this reason, \texttt{MAILBOX} and \texttt{STICK} ports should
+% not be used by critical tasks, whereas \texttt{STREAM} ports can be
+% used by any task requiring a state-message non-blocking semantics.
+% Moreover, the execution time of a transaction depends on the message
+% size (the message is copied in/from the buffer when a send/receive
+% is performed). The semantics associated with each port is graphically
+% illustrated in Figure \ref{fg:port-type}.
+%
+% An application that uses the communication ports, must register the
+% HARTPORT Module. Please see Volume III - S.Ha.R.K. Modules for details.
+%
+% \begin{figure}
+% \begin{center}\includegraphics[width=8cm]{port.eps}\end{center}
+% \caption{HARTIK ports.\label{fg:port-type}}
+% \end{figure}
+%
+% %----------------------------------------------------------------------------
+% \begin{intest}
+% PORT\_CREATE\index{port\_create()}
+% \end{intest}
+%
+% \begin{description}
+%
+% \item [\textbf{PORT port\_create(char {*}name, int dim, int num,
+% int type, int mode);}]
+%
+% \item [\textbf{Description:}]It opens the port identified by the string
+% \texttt{name}.
+% The argument \texttt{dim} specifies the message size in bytes, \texttt{num}
+% specifies the queue size, \texttt{type} the port type (\texttt{STREAM},
+% \texttt{MAILBOX}, or \texttt{STICK}), and \texttt{mode} the access
+% mode (\texttt{READ} or \texttt{WRITE}).
+%
+% \item [\textbf{Return Value:}] The primitive returns the port identifier,
+% which identifies the connection between the port and the task, and
+% not the port itself, which is identified through its name. A return
+% value -1 indicates that an error is occurred.
+%
+% \item [\textbf{See also}:] \texttt{port\_delete(), port\_connect(),
+% port\_disconnect(), port\_send(), port\_receive()}.
+%
+% \end{description}
+%
+% \begin{description}
+% \item [Example:\label{pg:port-ex}]
+% \item \texttt{TASK demo(void)} \{
+% \item \texttt{~~PORT p; }
+% \item \texttt{~~char msg{[}6{]}; }
+% \item \texttt{~~\ldots{}}
+% \item \texttt{~~/{*} Demo task, of NRT type, opens the \char`\"{}goofy\char`\"{}
+% port {*}/}
+% \item \texttt{~~/{*} and sends a message of 6 bytes. {*}/}
+% \item \texttt{~~p = port\_create(\char`\"{}goofy\char`\"{}, 6, 8, STREAM,
+% WRITE);}
+% \item \texttt{~~\ldots{}}
+% \item \texttt{~~port\_send(p, msg, BLOCK); }
+% \item \texttt{\}}
+% \item \texttt{~}
+% \item \texttt{TASK duro(void)} \{
+% \item \texttt{~~PORT q; }
+% \item \texttt{~~char msg{[}2{]}; }
+% \item \texttt{~~/{*} Duro task (HARD) connects to the \char`\"{}goofy\char`\"{}
+% {*}/}
+% \item \texttt{~~/{*} port and receives messages of 2 bytes {*}/ }
+% \item \texttt{~~q = port\_connect(\char`\"{}goofy\char`\"{}, 2, STREAM,
+% READ);}
+% \item \texttt{~~while (condition) \{}
+% \item \texttt{~~~~\ldots{}}
+% \item \texttt{~~~~if (port\_receive(q, msg, NON\textbackslash{}\_BLOCK) \{}
+% \item \texttt{~~~~~~<action 1>;~/{*} Ready Message! {*}/}
+% \item \texttt{~~~~\}}
+% \item \texttt{~~~~else \{}
+% \item \texttt{~~~~~~<action 2>;~/{*} Message not Ready! {*}/}
+% \item \texttt{~~~~\}}
+% \item \texttt{~~~~\ldots{}}
+% \item \texttt{~~~~task\_endcycle();}
+% \item \texttt{~~\}}
+% \item \texttt{\}}
+%
+% \end{description}
+%
+% %----------------------------------------------------------------------------
+% \begin{intest}
+% PORT\_DELETE\index{port\_delete()}
+% \end{intest}
+%
+% \begin{description}
+%
+% \item [\textbf{void port\_delete(PORT p)};]
+%
+% \item [\textbf{Description:}]It destroys the port identified by \texttt{p}.
+%
+% \item [\textbf{See also}:] \texttt{port\_create(), port\_connect(),
+% port\_disconnect(),
+% port\_send(), port\_receive()}.
+%
+% \item [\textbf{Example:}]see the example at page \pageref{pg:port-ex}.
+%
+% \end{description}
+%
+% %----------------------------------------------------------------------------
+% \begin{intest}
+% PORT\_CONNECT\index{port\_connect()}
+% \end{intest}
+%
+% \begin{description}
+%
+% \item [\textbf{PORT port\_connect(char {*}name, int dim, int type,
+% int mode);}]
+%
+% \item [\textbf{Description:}]It connects the calling task to the port identified
+% by \texttt{name}. The argument \texttt{dim} specifies the message
+% size in bytes, \texttt{type} the port type (\texttt{STREAM}, \texttt{MAILBOX},
+% or \texttt{STICK}), and \texttt{mode} the access mode (\texttt{READ}
+% or \texttt{WRITE}). If the port has not been opened by \texttt{port\_create()},
+% the task is blocked, waiting for port creation. To avoid synchronization
+% delays, connection should be established only \underbar{after} opening
+% the port.
+%
+% \item [\textbf{Return value:}] The function returns the port identification
+% number in the case of successful operation; else -1 is returned.
+%
+% \item [\textbf{See also}:] \texttt{port\_create(), port\_delete(),
+% port\_disconnect(), port\_send(), port\_receive()}.
+%
+% \end{description}
+%
+% %----------------------------------------------------------------------------
+% \begin{intest}
+% PORT\_DISCONNECT\index{port\_disconnect()}
+% \end{intest}
+%
+% \begin{description}
+%
+% \item [\textbf{void port\_disconnect(PORT p)};]
+%
+% \item [\textbf{Description:}]It closes the connection identified by \texttt{p}.
+%
+% \item [\textbf{See also}:] \texttt{port\_create(), port\_connect(),
+% port\_delete(), port\_send(), port\_receive()}.
+%
+% \end{description}
+%
+% %----------------------------------------------------------------------------
+% \begin{intest}
+% PORT\_SEND\index{port\_send()}
+% \end{intest}
+%
+% \begin{description}
+%
+% \item [\textbf{int port\_send(PORT p, char {*}msg, BYTE b);}]
+%
+% \item [\textbf{Description:}]It sends a message pointed by \texttt{msg} to the
+% port identified by \texttt{p}. Message dimension is defined through
+% \texttt{port\_create()}
+% or \texttt{port\_connect()} and cannot be dynamically changed. The
+% argument \texttt{b} can be \texttt{BLOCK} or \texttt{NON\_BLOCK}.
+% If \texttt{b = BLOCK} and the port queue is full, then the task is
+% blocked until the buffer is freed. If \texttt{b = NON\_BLOCK} and
+% the port queue is full, then the primitive returns 0 and the message
+% is not sent.
+%
+% \item [\textbf{Return value:}] 1 (TRUE) if the operation can be performed,
+% 0 otherwise.
+%
+% \item [\textbf{See also}:] \texttt{port\_create(), port\_connect(),
+% port\_disconnect(),
+% port\_send(), port\_receive()}.
+%
+% \item [\textbf{Example:}]see the example at page \pageref{pg:port-ex}.
+%
+% \end{description}
+%
+% %----------------------------------------------------------------------------
+% \begin{intest}
+% PORT\_RECEIVE\index{port\_receive()}
+% \end{intest}
+%
+% \begin{description}
+%
+% \item [\textbf{int port\_receive(PORT p, char {*}msg, BYTE b);}]
+%
+% \item [\textbf{Description:}]It receives a message from the port identified by
+% \texttt{p} and copies it in a memory buffer pointed by \texttt{msg}. Message
+% dimension is defined through \texttt{port\_create()} or \texttt{port\_connect()}
+% and cannot be dynamically changed. The argument \texttt{b} can be
+% \texttt{BLOCK} or \texttt{NON\_BLOCK}. If \texttt{b = BLOCK} and the
+% port queue is empty, then the task is blocked until a message is available.
+% If \texttt{b = NON\_BLOCK} and the port queue is empty, then the primitive
+% returns 0 and no message is received.
+%
+% \item [\textbf{Return value:}] 1 (TRUE) if the operation can be performed,
+% 0 otherwise.
+%
+% \item [\textbf{See also}:] \texttt{port\_create(), port\_connect(),
+% port\_disconnect(), port\_send(), port\_receive()}.
+%
+% \item [\textbf{Example:}]see the example at page \pageref{pg:port-ex}.
+%
+% \end{description}
+
+%----------------------------------------------------------------------------
+\section{Cyclical Asynchronous Buffers}
+%----------------------------------------------------------------------------
+
+\textbf{Cyclical Asynchronous Buffers} (or CABs) represent a particular
+mechanism purposely designed for the cooperation among periodic activities
+with different activation rates. See \cite{But97} for implementation
+details.
+
+A CAB provides a one-to-many communication channel, which at any instant
+contains the most recent message inserted into it. A message is not
+consumed (that is, extracted) by a receiving process but is maintained
+into the CAB structure until a new message is overwritten. As a consequence,
+once the first message is put in a CAB, a task can never be blocked
+during a receive operation. Similarly, since a new message overwrites
+the old one, a sender can never be blocked.
+
+Notice that, using such a semantics, a message can be read more than
+once if the receiver is faster than the sender, while messages can
+be lost if the sender is faster than the receiver. However, this is
+not a problem in many control applications, where tasks are interested
+only in fresh sensory data rather than in the complete message history
+produced by a sensory acquisition task.
+
+Notice that more tasks can simultaneously access the same buffer in
+a CAB for reading. Also, if a task $P$ reserves a CAB for writing
+while another task $Q$ is using that CAB, a new buffer is created,
+so that $P$ can write its message without interfering with $Q$.
+As $P$ finishes writing, its message becomes the most recent one
+in that CAB. The maximum number of buffers that can be created in
+a CAB is specified as a parameter in the \emph{cab\_create} primitive.
+To avoid blocking, this number must be equal to the number of tasks
+that use the CAB plus one.
+
+CABs can be created and initialized by the \emph{cab\_create} primitive,
+which requires the CAB name, the dimension of the message, and the
+number of messages that the CAB may contain simultaneously. The
+\emph{cab\_delete}
+primitive removes a CAB from the system and releases the memory space
+used by its data structures.
+
+To insert a message in a CAB, a task must first reserve a buffer from
+the CAB memory space, then copy the message into the buffer, and finally
+put the buffer into the CAB structure, where it becomes the most recent
+message. This is done according to the following scheme:
+
+\vspace{5mm} \begin{tt}
+\begin{tabbing}
+\={b}uf\_pointer = {\textbf{cab\_reserve}}(cab\_id);\\
+\>\(<\)copy message in *buf\_pointer\(>\)\\
+\>{\textbf{cab\_putmes}}(cab\_id, buf\_pointer);\\
+\end{tabbing}
+\end{tt}
+
+\noindent Similarly, to get a message from a CAB, a task has to get
+the pointer to the most recent message, use the data, and release
+the pointer. This is done according to the following scheme:
+
+\vspace{5mm} \begin{tt}
+\begin{tabbing}
+\={m}es\_pointer = {\textbf{cab\_getmes}}(cab\_id);\\
+\>\(<\)use message\(>\)\\
+\>{\textbf{cab\_unget}}(cab\_id, mes\_pointer);
+\end{tabbing}
+\end{tt} A simple example of CABs' usage is reported below.
+
+\label{pg:cab-ex} \begin{minipage}{\columnwidth}
+\begin{small}
+\begin{tt}
+\begin{verbatim}
+CAB cc;
+
+void main(void) {
+ SYS_PARMS parms = BASE_SYS;
+
+ /* global declaration */
+ sys_def_tick(parms, 1, mSec);
+ sys_init(&parms);
+
+ /* The CAB named cc contains a message of */
+ /* 5 floats and can be used by two tasks */
+ cc = cab_create("my_cab", 5 * sizeof(float), 3);
+ task_activate(task_create("ll", read, HARD, APERIODIC, 100, NULL));
+ task_activate(task_create("ss", write, HARD, PERIODIC, 333, NULL));
+ ...
+}
+
+/*---------------------------------------------------------------------*/
+TASK write(void) {
+ float msg[5];
+ char *pun;
+ ...
+
+ while (1) {
+
+ /* send a message to the `cc' cab */
+ pun = cab_reserve(cc); /* reserve a buffer */
+ memcpy(pun, msg, 5 * sizeof(float));
+ cab_putmes(cc, pun); /* release the buffer */
+ task_endcycle();
+ }
+}
+
+/*---------------------------------------------------------------------*/
+TASK read(void) {
+ float msg[5];
+ char *pun;
+ ...
+
+ while (1) {
+
+ /* get a message from the `cc' CAB */
+ pun = cab_getmes(cc); /* reserve a buffer */
+ memcpy(msg, pun, 5 * sizeof(float));
+ cab_unget(cc, pun); /* release the buffer */
+ task_endcycle();
+ }
+}
+\end{verbatim}
+\end{tt}
+\end{small}
+\end{minipage}
+
+%----------------------------------------------------------------------------
+\vspace{7mm} \begin{intest}
+CAB\_CREATE\index{cab\_create()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{CAB cab\_create(char {*}name, int dim\_mes, BYTE num\_mes)}]
+
+\item [\textbf{Description:}]It initializes a CAB. \texttt{name} is a pointer to
+an identification string (used only for debugging purposes); \texttt{dim}
+is the size of the messages contained in the CAB; \texttt{numbuf}
+is the number of buffers the CAB is composed of. Notice that such
+a number must be greater than or equal to the number of tasks that
+use the CAB plus one.
+
+\item [\textbf{Return value:}] It returns the index of the created CAB.
+
+\item [\textbf{See also}:] \texttt{cab\_delete(), cab\_reserve(), cab\_putmes(),
+cab\_getmes(), cab\_unget()}.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\vspace{7mm} \begin{intest}
+CAB\_DELETE\index{cab\_delete()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{void cab\_delete(CAB cc);}]
+
+\item [\textbf{Description:}]It removes the \texttt{cc} CAB from the system,
+deallocating
+its buffers and data structures.
+
+\item [\textbf{See also}:] \texttt{cab\_create(), cab\_reserve(), cab\_putmes(),
+cab\_getmes(), cab\_unget()}.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\vspace{7mm} \begin{intest}
+CAB\_RESERVE\index{cab\_reserve()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{char {*}cab\_reserve(CAB cc);}]
+
+\item [\textbf{Description:}]it reserves a buffer belonging to the \texttt{cc}
+CAB and returns a pointer to it. The primitive has to be used only by
+writers and \emph{never} by readers.
+
+\item [\textbf{Return value:}] it returns a pointer to the reserved buffer.
+
+\item [\textbf{See also}:] \texttt{cab\_delete(), cab\_create(), cab\_putmes(),
+cab\_getmes(), cab\_unget()}.
+
+\end{description}
+
+\pagebreak
+
+%----------------------------------------------------------------------------
+\begin{intest}
+CAB\_PUTMES\index{cab\_putmes()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{void cab\_putmes(CAB id, char {*}pun)}]
+
+\item [\textbf{Description:}]It inserts the message pointed by \texttt{pun} into
+the CAB identified by \texttt{id}. This primitive must be used \emph{only}
+by writing tasks.
+
+\item [\textbf{See also}:] \texttt{cab\_delete(), cab\_create(), cab\_reserve(),
+cab\_getmes(), cab\_unget()}.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\vspace{7mm} \begin{intest}
+CAB\_GETMES\index{cab\_getmes()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{char {*}cab\_getmes(CAB cc);}]
+
+\item [\textbf{Description:}]It returns a pointer to the latest message written
+into the \texttt{cc} CAB. This primitive must be used \emph{only}
+by reading tasks.
+
+\item [\textbf{Returned value:}] It returns a pointer to the most recent
+message contained in the CAB.
+
+\item [\textbf{See also}:] \texttt{cab\_delete(), cab\_create(), cab\_putmes(),
+cab\_reserve(), cab\_unget()}.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\vspace{7mm} \begin{intest}
+CAB\_UNGET\index{cab\_unget()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{void cab\_unget(CAB cc, char {*}pun);}]
+
+\item [\textbf{Description:}]it notifies the system that the buffer pointed by
+\texttt{pun} belonging to the \texttt{cc} CAB is no longer used by the calling
+task.
+
+\item [\textbf{See also}:] \texttt{cab\_delete(), cab\_create(), cab\_reserve(),
+cab\_getmes(), cab\_putmes()}.
+
+\end{description}
+
+\section{POSIX Message Queues}
+
+S.Ha.R.K. provides the message passing function defined in the POSIX
+standard. For more information, see Section 15 of the POSIX standard,
+Message Passing.
/branches/new_sharkdoc/vol1/semaf.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol1/port.eps
===================================================================
--- branches/new_sharkdoc/vol1/port.eps (nonexistent)
+++ branches/new_sharkdoc/vol1/port.eps (revision 1676)
@@ -0,0 +1,235 @@
+%!PS-Adobe-2.0 EPSF-2.0
+%%Title: port.fig
+%%Creator: fig2dev Version 3.2 Patchlevel 1
+%%CreationDate: Wed Jul 12 11:38:50 2000
+%%For: pj@galadriel (Paolo Gai)
+%%Orientation: Portrait
+%%BoundingBox: 0 0 314 197
+%%Pages: 0
+%%BeginSetup
+%%EndSetup
+%%Magnification: 1.0000
+%%EndComments
+/$F2psDict 200 dict def
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/col-1 {0 setgray} bind def
+/col0 {0.000 0.000 0.000 srgb} bind def
+/col1 {0.000 0.000 1.000 srgb} bind def
+/col2 {0.000 1.000 0.000 srgb} bind def
+/col3 {0.000 1.000 1.000 srgb} bind def
+/col4 {1.000 0.000 0.000 srgb} bind def
+/col5 {1.000 0.000 1.000 srgb} bind def
+/col6 {1.000 1.000 0.000 srgb} bind def
+/col7 {1.000 1.000 1.000 srgb} bind def
+/col8 {0.000 0.000 0.560 srgb} bind def
+/col9 {0.000 0.000 0.690 srgb} bind def
+/col10 {0.000 0.000 0.820 srgb} bind def
+/col11 {0.530 0.810 1.000 srgb} bind def
+/col12 {0.000 0.560 0.000 srgb} bind def
+/col13 {0.000 0.690 0.000 srgb} bind def
+/col14 {0.000 0.820 0.000 srgb} bind def
+/col15 {0.000 0.560 0.560 srgb} bind def
+/col16 {0.000 0.690 0.690 srgb} bind def
+/col17 {0.000 0.820 0.820 srgb} bind def
+/col18 {0.560 0.000 0.000 srgb} bind def
+/col19 {0.690 0.000 0.000 srgb} bind def
+/col20 {0.820 0.000 0.000 srgb} bind def
+/col21 {0.560 0.000 0.560 srgb} bind def
+/col22 {0.690 0.000 0.690 srgb} bind def
+/col23 {0.820 0.000 0.820 srgb} bind def
+/col24 {0.500 0.190 0.000 srgb} bind def
+/col25 {0.630 0.250 0.000 srgb} bind def
+/col26 {0.750 0.380 0.000 srgb} bind def
+/col27 {1.000 0.500 0.500 srgb} bind def
+/col28 {1.000 0.630 0.630 srgb} bind def
+/col29 {1.000 0.750 0.750 srgb} bind def
+/col30 {1.000 0.880 0.880 srgb} bind def
+/col31 {1.000 0.840 0.000 srgb} bind def
+
+end
+save
+-108.0 304.0 translate
+1 -1 scale
+
+/cp {closepath} bind def
+/ef {eofill} bind def
+/gr {grestore} bind def
+/gs {gsave} bind def
+/sa {save} bind def
+/rs {restore} bind def
+/l {lineto} bind def
+/m {moveto} bind def
+/rm {rmoveto} bind def
+/n {newpath} bind def
+/s {stroke} bind def
+/sh {show} bind def
+/slc {setlinecap} bind def
+/slj {setlinejoin} bind def
+/slw {setlinewidth} bind def
+/srgb {setrgbcolor} bind def
+/rot {rotate} bind def
+/sc {scale} bind def
+/sd {setdash} bind def
+/ff {findfont} bind def
+/sf {setfont} bind def
+/scf {scalefont} bind def
+/sw {stringwidth} bind def
+/tr {translate} bind def
+/tnt {dup dup currentrgbcolor
+ 4 -2 roll dup 1 exch sub 3 -1 roll mul add
+ 4 -2 roll dup 1 exch sub 3 -1 roll mul add
+ 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
+ bind def
+/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+ 4 -2 roll mul srgb} bind def
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+%%EndProlog
+
+$F2psBegin
+10 setmiterlimit
+n -1000 6052 m -1000 -1000 l 8026 -1000 l 8026 6052 l cp clip
+ 0.06000 0.06000 sc
+/Times-Roman ff 180.00 scf sf
+1800 3450 m
+gs 1 -1 sc (Clients) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+6150 3375 m
+gs 1 -1 sc (Server) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+6150 3600 m
+gs 1 -1 sc (\(Owner\)) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+1800 4725 m
+gs 1 -1 sc (Producers) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+1800 4950 m
+gs 1 -1 sc (\(Owner\)) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+6150 4725 m
+gs 1 -1 sc (Consumers) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+2100 2325 m
+gs 1 -1 sc (Writer) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+5850 2325 m
+gs 1 -1 sc (Reader) col0 sh gr
+% Polyline
+7.500 slw
+n 3375 3240 m 4950 3240 l 4950 3690 l 3375 3690 l gs col-1 s gr
+% Polyline
+n 4500 3240 m 4500 3690 l gs col-1 s gr
+% Polyline
+n 4275 3240 m 4275 3690 l gs col-1 s gr
+% Polyline
+n 4050 3240 m 4050 3690 l gs col-1 s gr
+% Polyline
+n 3825 3240 m 3825 3690 l gs col-1 s gr
+% Polyline
+n 4725 3240 m 4725 3690 l gs col-1 s gr
+% Polyline
+gs clippath
+5505 3435 m 5625 3465 l 5505 3495 l 5640 3495 l 5640 3435 l cp
+clip
+n 4950 3465 m 5625 3465 l gs col-1 s gr gr
+
+% arrowhead
+n 5505 3435 m 5625 3465 l 5505 3495 l col-1 s
+% Polyline
+gs clippath
+3255 3435 m 3375 3465 l 3255 3495 l 3390 3495 l 3390 3435 l cp
+clip
+n 2700 3465 m 3375 3465 l gs col-1 s gr gr
+
+% arrowhead
+n 3255 3435 m 3375 3465 l 3255 3495 l col-1 s
+% Polyline
+gs clippath
+3263 3322 m 3375 3375 l 3251 3381 l 3384 3407 l 3396 3349 l cp
+clip
+n 2700 3240 m 3375 3375 l gs col-1 s gr gr
+
+% arrowhead
+n 3263 3322 m 3375 3375 l 3251 3381 l col-1 s
+% Polyline
+gs clippath
+3251 3549 m 3375 3555 l 3263 3608 l 3396 3581 l 3384 3523 l cp
+clip
+n 2700 3690 m 3375 3555 l gs col-1 s gr gr
+
+% arrowhead
+n 3251 3549 m 3375 3555 l 3263 3608 l col-1 s
+/Times-Roman ff 150.00 scf sf
+3825 3060 m
+gs 1 -1 sc (MAILBOX) col-1 sh gr
+% Polyline
+n 4635 5040 m 4635 4410 l 3735 4410 l 3735 5040 l cp gs col-1 s gr
+% Polyline
+gs clippath
+3615 4695 m 3735 4725 l 3615 4755 l 3750 4755 l 3750 4695 l cp
+clip
+n 3060 4725 m 3735 4725 l gs col-1 s gr gr
+
+% arrowhead
+n 3615 4695 m 3735 4725 l 3615 4755 l col-1 s
+% Polyline
+gs clippath
+5190 4695 m 5310 4725 l 5190 4755 l 5325 4755 l 5325 4695 l cp
+clip
+n 4635 4725 m 5310 4725 l gs col-1 s gr gr
+
+% arrowhead
+n 5190 4695 m 5310 4725 l 5190 4755 l col-1 s
+% Polyline
+gs clippath
+5186 4494 m 5310 4500 l 5198 4553 l 5331 4526 l 5319 4468 l cp
+clip
+n 4635 4635 m 5310 4500 l gs col-1 s gr gr
+
+% arrowhead
+n 5186 4494 m 5310 4500 l 5198 4553 l col-1 s
+% Polyline
+gs clippath
+5198 4897 m 5310 4950 l 5186 4956 l 5319 4982 l 5331 4924 l cp
+clip
+n 4635 4815 m 5310 4950 l gs col-1 s gr gr
+
+% arrowhead
+n 5198 4897 m 5310 4950 l 5186 4956 l col-1 s
+/Times-Roman ff 150.00 scf sf
+4005 4230 m
+gs 1 -1 sc (STICK) col-1 sh gr
+% Polyline
+n 3375 2025 m 4950 2025 l 4950 2475 l 3375 2475 l gs col-1 s gr
+% Polyline
+n 4500 2025 m 4500 2475 l gs col-1 s gr
+% Polyline
+n 4275 2025 m 4275 2475 l gs col-1 s gr
+% Polyline
+n 4050 2025 m 4050 2475 l gs col-1 s gr
+% Polyline
+n 3825 2025 m 3825 2475 l gs col-1 s gr
+% Polyline
+n 4725 2025 m 4725 2475 l gs col-1 s gr
+% Polyline
+gs clippath
+5505 2220 m 5625 2250 l 5505 2280 l 5640 2280 l 5640 2220 l cp
+clip
+n 4950 2250 m 5625 2250 l gs col-1 s gr gr
+
+% arrowhead
+n 5505 2220 m 5625 2250 l 5505 2280 l col-1 s
+% Polyline
+gs clippath
+3255 2220 m 3375 2250 l 3255 2280 l 3390 2280 l 3390 2220 l cp
+clip
+n 2700 2250 m 3375 2250 l gs col-1 s gr gr
+
+% arrowhead
+n 3255 2220 m 3375 2250 l 3255 2280 l col-1 s
+/Times-Roman ff 150.00 scf sf
+3870 1890 m
+gs 1 -1 sc (STREAM) col-1 sh gr
+$F2psEnd
+rs
/branches/new_sharkdoc/vol1/port.eps
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol1/errors.tex
===================================================================
--- branches/new_sharkdoc/vol1/errors.tex (nonexistent)
+++ branches/new_sharkdoc/vol1/errors.tex (revision 1676)
@@ -0,0 +1,98 @@
+%----------------------------------------------------------------------------
+\chapter{Errors and Exceptions}
+\label{ch:Errors} \label{ch:Exceptions}
+%----------------------------------------------------------------------------
+
+This appendix describes the errors and exceptions codes that can be
+printed into the screen, returned by a functions into the the \texttt{errno}
+variables or that the kernel can raise. These error constants are
+included from the \texttt{errno.h} standard include file, and are
+contained into the \texttt{bits/errno.h} include file.
+
+%----------------------------------------------------------------------------
+\section{Abort codes}
+%----------------------------------------------------------------------------
+
+\begin{longtable}{|c|c|c|}
+\hline Name & N.& Description \\ \hline
+\hline none & 1 & Generic OSLib abortASIG\_DEFAULT\_ACTION \\
+\hline ASIG\_DEFAULT\_ACTION & 2& The default handler of a signal has been executed \\
+\hline ASIGINIT & 3 & Internal error in initializing signals (should never happens) \\
+\hline AHEXC & 4 & a set\_exchandler\_XXX function has been executed. \\
+\hline AARPFULL & 5 & ARP table full. \\
+\hline
+\end{longtable}
+
+%----------------------------------------------------------------------------
+\section{Exceptions posted with kern\_raise}
+%----------------------------------------------------------------------------
+
+\begin{longtable}{|l|c|p{8cm}|}
+\hline Name & N. & Description \\ \hline
+\hline XDOUBLE\_EXCEPTION & 1 & Two exceptions has been raised. Currently not used \\
+\hline XUNVALID\_KILL\_SHADOW & 2 & Called into the internal function task\_makefree because a task was killed while some other task shadow points to that task. \\
+\hline XNOMORE\_CLEANUPS & 3 & Too many cleanups handlers has been used. Currently not used. \\
+\hline XUNVALID\_TASK & 4 & The Registered Modules does not implement a primitive called by the task (usually happens when the user calls task\_delay or task\_sleep) \\
+\hline XUNVALID\_GUEST & 5 & The Registered Modules does not handle correctly the guest tasks. Check the initfile. \\
+\hline XNOMORE\_EVENTS & 6 & Too many OSLib events posted. The number of OSLib events posted is declared in \texttt{include/ll/sys/ll/event.h} into the constant \texttt{MAX\_EVENT}.\\
+\hline XDEADLINE\_MISS & 7 & A Task missed its deadline.\\
+\hline XWCET\_VIOLATION & 8 & A Task consumed more tha its declared WCET.\\
+\hline XACTIVATION & 9 & A Sporadic task has been activated more frequently than declared.\\
+\hline XMUTEX\_OWNER\_KILLED & 10 & A task is terminated while it owns a mutex.\\
+\hline XSRP\_UNVALID\_LOCK & 11 & A task tried to lock a SRP mutex with a wrong preemption level, or a task tries to lock a SRP mutex already locked, or a task tries to lock a SRP mutex without declaring its preemption level.\\
+\hline XUNVALID\_DUMMY\_OP & 12 & Someone tried to execute an operation on the dummy Scheduling Module.\\
+\hline XUNVALID\_SS\_REPLENISH & 13 & Error in the Sporadic Server replenishments. Please look at \texttt{kernel/modules/ss.c}.\\
+\hline XARP\_TABLE\_FULL & 14 & Arp table full. See \texttt{drivers/net/arp.c}.\\
+\hline XNETBUFF\_INIT\_EXC & 15 & Network buffers error. See \texttt{drivers/net/netbuff.}.\\
+\hline XNETBUFF\_GET\_EXC & 16 & Network buffers error. See \texttt{drivers/net/netbuff.}. \\
+\hline XNETBUFF\_ALREADYFREE\_EXC & 17 & Network buffers error. See \texttt{drivers/net/netbuff.}. \\
+\hline XNETBUFF\_RELEASE\_EXC & 18 & Network buffers error. See \texttt{drivers/net/netbuff.}. \\
+\hline XUDP\_BADCHK\_EXC & 19 & UDP CRC check failed. \\
+\hline
+\end{longtable}
+
+%----------------------------------------------------------------------------
+\section{POSIX error codes}
+%----------------------------------------------------------------------------
+
+The POSIX error codes have numbers form 1 to 125 and are listed into
+\texttt{include/errno.h}.
+
+%----------------------------------------------------------------------------
+\section{S.Ha.R.K. error codes}
+%----------------------------------------------------------------------------
+
+\begin{longtable}{|c|c|p{8cm}|}
+\hline Name & N. & Description\\ \hline
+\hline EWRONG\_INT\_NO & 126 & Wrong int number passed to handler-set or handler\_remove.\\
+\hline EUSED\_INT\_NO & 127 & Already used int number.\\
+\hline EUNUSED\_INT\_NO & 128 & Int number not used.\\
+\hline ETOOMUCH\_INITFUNC & 129 & Too much init functions posted. (Currently not used)\\
+\hline ETOOMUCH\_EXITFUNC & 130 & Too much exit functions posted.\\
+\hline ENO\_AVAIL\_TASK & 131 & Task limit reached. Up to TSSMax-1 tasks can be created. See include/ll/i386/tss-ctx.h and include/kernel/const.h\\
+\hline ENO\_AVAIL\_SCHEDLEVEL & 132 & The Task Model passed with task\_create cannot be accepted by any scheduling module.\\
+\hline ETASK\_CREATE & 133 & Error during task\_create.\\
+\hline ENO\_AVAIL\_RESLEVEL & 134 & A Resource Model passed with task\_create cannot be accepted by any resource module.\\
+\hline ENO\_GUARANTEE & 135 & The new task cannot be accepted by the Scheduling Modules\\
+\hline ENO\_AVAIL\_STACK\_MEM & 136 & No space left to allocate the task stack.\\
+\hline ENO\_AVAIL\_TSS & 137 & No TSS free. This error should never happen.\\
+\hline EUNVALID\_KILL & 138 & The PID you tried to kill is not a task or has the NO\_KILL flag set.\\
+\hline EUNVALID\_TASK\_ID & 139 & The PID passed to task\_activate is not correct.\\
+\hline EUNVALID\_GROUP & 140 & Group 0 is not a valid group.\\
+\hline EPORT\_NO\_MORE\_DESCR & 141 & HARTPORT: No more port descriptors available.\\
+\hline EPORT\_NO\_MORE\_INTERF & 142 & HARTPORT: No more free port interfaces.\\
+\hline EPORT\_INCOMPAT\_MESSAGE & 143 & HARTPORT: Incompatible message (Write on a read port or viceversa)\\
+\hline EPORT\_ALREADY\_OPEN & 144 & HARTPORT: The port is already open.\\
+\hline EPORT\_NO\_MORE\_HASHENTRY & 145 & HARTPORT: No more Hash entries to create a port.\\
+\hline EPORT\_2\_CONNECT & 146 & HARTPORT: Error creating the port.\\
+\hline EPORT\_UNSUPPORTED\_ACC & 147 & HARTPORT: Error in port\_connect.\\
+\hline EPORT\_WRONG\_OP & 148 & HARTPORT: Wrong operation.\\
+\hline EPORT\_WRONG\_TYPE & 149 & HARTPORT: Operation not supported by the port type.\\
+\hline EPORT\_UNVALID\_DESCR & 150 & HARTPORT: Invalid port descriptor.\\
+\hline ECAB\_UNVALID\_ID & 151 & CABS: Invalid CAB ID.\\
+\hline ECAB\_CLOSED & 152 & CABS: CAB Closed.\\
+\hline ECAB\_UNVALID\_MSG\_NUM & 153 & CABS: Invalid Message number.\\
+\hline ECAB\_NO\_MORE\_ENTRY & 154 & CABS: No more entries.\\
+\hline ECAB\_TOO\_MUCH\_MSG & 155 & CABS: Too much messages.\\
+\hline
+\end{longtable}
/branches/new_sharkdoc/vol1/errors.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol1/util.tex
===================================================================
--- branches/new_sharkdoc/vol1/util.tex (nonexistent)
+++ branches/new_sharkdoc/vol1/util.tex (revision 1676)
@@ -0,0 +1,441 @@
+%----------------------------------------------------------------------------
+\chapter{Utility functions}
+%----------------------------------------------------------------------------
+
+S.Ha.R.K. provides a set of utility functions aimed at getting information
+about the kernel state. Mainly, they allow a user to get the actual
+system time and some information concerning the tasks' state. Moreover,
+it allows to set exception handlers and to manage interrupts.
+
+%----------------------------------------------------------------------------
+\section{Reading time}
+%----------------------------------------------------------------------------
+
+The S.Ha.R.K. Kernel does not have the concept of tick. Every time
+interval and every absolute time in the system is measured usin the
+Real-Time Clock available on the PC. To read the current time you
+can use the following function:
+
+%----------------------------------------------------------------------------
+\begin{intest}
+SYS\_GETTIME\index{sys\_gettime()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{TIME sys\_gettime(struct timespec *t);}]
+\item [Description:]It returns the number of microseconds elapsed from
+system's initialization, that is from the end of the \texttt{\_\_kernel\_register\_levels\_\_}
+function. If the \texttt{t} value is not equal \texttt{NULL}, the
+function fills also the timespec structure passed as parameter.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Getting information on tasks}
+%----------------------------------------------------------------------------
+
+Since all the tasks are handled by a Module, it is a responsibility of each
+Module to hide or not hide informations about the tasks handled by the system.
+However, at the moment S.Ha.R.K. provides a function that simply prints the
+tasks state on the console \footnote{Old versions of the kernel supported a
+\texttt{void sys\_status(DWORD cw);} \index{sys\_status()}primitive. That
+primitive is currently unsupported.}.
+
+\pagebreak
+
+%----------------------------------------------------------------------------
+\begin{intest}
+PERROR\index{perror()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void perror (const char *s);}]
+\item [Description:]This is the POSIX \texttt{perror()} funcion, that prints
+on the console (using \texttt{kern\_printf}) a message that explain
+the meaning of the \texttt{errno} \index{errno} variable. Note that
+each task has its own \texttt{errno} variable, as specified by the
+\texttt{POSIX} standard.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+exec\_shadow\index{exec\_shadow}
+\end{intest}
+\begin{description}
+\item [\texttt{PID exec\_shadow;}]
+\item [Description:]This is the internal variable used by the Kernel to
+track the running task. You can read its value to know the PID of
+the current task. You CAN NOT modify this variable.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Printing messages on the console}
+%----------------------------------------------------------------------------
+
+To print a simple message on the console, please use the c* functions
+(cprintf\index{cprintf}, cputs\index{cputs}, \ldots{}) described
+in Volume II. If tou are debugging \emph{the kernel}, you can use
+kern\_printf \index{kern\_printf} to print very simple messages without
+floating point arithmetic.
+
+%----------------------------------------------------------------------------
+\chapter{Signals and Exception Handling}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\section{Signals}
+%----------------------------------------------------------------------------
+
+S.Ha.R.K. implements the specification of the signals and of the real-time
+signald provided by the standard IEEE 1003.13 POSIX PSE51/PSE52. In
+particular, you can use all the functions described into the IEEE
+1003.1\{a,b\} standards, except that:
+
+\begin{itemize}
+\item all the \texttt{pid\_t} parameters and in general all parameters related
+with processes should be ignored;
+\item when in POSIX a signal cause the termination of the process, it causes
+in S.Ha.R.K. the termination of the whole system (you can think S.Ha.R.K.
+as a single process multithread kernel);
+\item The \texttt{siginfo\_t} structure contains an additional parameter
+called \texttt{si\_task} of type \texttt{PID}. It contains the \texttt{PID}
+of the task that queued a particular real-time signal.
+\end{itemize}
+
+In particular, you can use these functions for signal handling: \texttt{kill},
+\texttt{sigemptyset}, \texttt{sigfillset}, \texttt{sigaddset},
+\texttt{sigdelset}, \texttt{sigismember}, \texttt{sigaction},
+\texttt{pthread\_sigmask} \footnote{If you are not using the POSIX scheduling
+modules please use \texttt{task\_sigmask}}, \texttt{sigprocmask},
+\texttt{sigpending}, \texttt{sigsuspend}, \texttt{sigwait},
+\texttt{sigwaitinfo}, \texttt{sigtimedwait}, \texttt{sigqueue},
+\texttt{pthread\_kill} \footnote{If you are not using the POSIX scheduling
+modules please use \texttt{task\_signal} (Note that \texttt{task\_kill} does not
+send any signal, but issue a cancellation request on a task!)}, \texttt{alarm},
+\texttt{pause}, \texttt{sleep} (note the difference between \texttt{sleep},
+\texttt{task\_sleep} and \texttt{nanosleep}!), \texttt{raise}, \texttt{signal}.
+
+%----------------------------------------------------------------------------
+\section{Exception handling\label{ch:except}}
+%----------------------------------------------------------------------------
+
+S.Ha.R.K. provides a flexible mechanism to handle the exceptions of the Kernel.
+The mechanism is based on the POSIX signals. In fact, S.Ha.R.K. exceptions are
+remapped on the real-time signal \texttt{SIGHEXC} \footnote{see
+\texttt{include/signal.h}.} (9). Every time something goes wrong, the system
+calls the primitive \texttt{kern\_raise}, that simply queue a real-time signal
+of number SIGHEXC.
+
+The user can define its own exception handler simply remapping the SIGHEXC
+signal using the POSIX primitive \texttt{sigaction}. To fullfil the typical
+usage of an exception handler (exit the system after printing a message), the
+default behavior of the signal handler has been redefined to print a text
+message on system shutdown. \footnote{Older versions of the Kernel supported two
+functions to be used for standard redefinition of the kernel signal handler.
+These functions, called SET\_EXCHANDLER\_TXT\index{set\_exchandler\_txt()} and
+SET\_EXCHANDLER\_GRX\index{set\_exchandler\_grx()}, are no more supported, and
+can be removed from your code without problems.}
+
+Here is a sample code that explain how to redefine a signal handler:
+
+\begin{verbatim}
+#include <kernel/kern.h>
+
+void thehandler(int signo, siginfo_t *info, void *extra) {
+
+ /* the signal handler:
+ info.sivalue.sival_int contains the exception number
+ (see include/bits/errno.h)
+
+ info.si_task is the task that raised the exception
+ extra is not used
+ */
+ ...
+}
+
+...
+
+int myfunc(...) {
+ struct sigaction action;
+ ...
+
+ action.sa_flags = SA_SIGINFO;
+ action.sa_sigaction = thehandler;
+ action.sa_handler = 0;
+ sigfillset(&action.sa_mask);
+ sigaction(SIGHEXC, &action, NULL);
+
+ ...
+}
+\end{verbatim}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+KERN\_RAISE\index{kern\_raise()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void kern\_raise(int n, PID p);}]
+\item [Description:]This function uses the POSIX function sigqueue to put
+a signal SIGHEXC into the signal queue. The parameter n is used as
+the exception number, and it is passed into the siginfo\_t parameter
+(into the sivalue.sival\_int field). The signal appears to be queued
+by the task p (the p value is stored into the si\_task field of the
+siginfo\_t structure passed as parameter).
+\end{description}
+
+%----------------------------------------------------------------------------
+\chapter{Interrupt and HW Ports handling}
+\label{ch:interr}
+%----------------------------------------------------------------------------
+
+Generally speaking, I/O to and from an external peripheral device
+can be handled in three different ways depending on the peripheral
+type and on the application:
+
+\begin{itemize}
+\item \textbf{Polling}: the program cyclically checks the status of the
+I/O port, waiting for a input data to be ready or an output data to
+be transmittable;
+\item \textbf{Interrupt}: the program enables the I/O interface to send
+a hardware interrupt every time an input data is available or an output
+data is transmittable;
+\item \textbf{DMA}: the program enables the interface to use DMA mechaninsm
+for directly transferring data to/from memory.
+\end{itemize}
+\noindent In this chapter we will analyse the support that the S.Ha.R.K.
+kernel provides for using the second method (interrupt).
+
+When an interrupt arrives, a code for the hand-shake with the interface
+and for transferring data has to be executed. This code can run in
+two different modes:
+
+\begin{itemize}
+\item it can be entirely encapsulated in a function to be executed immediately
+on the interrupt arrival, in the context of the executing task (\textit{fast
+handler});
+\item it can be entirely encapsulated in a task (\textit{safe handler})
+which is activated on the interrupt arrival and scheduled with its
+own priority together with the other tasks.
+\end{itemize}
+\noindent The first method is appropriate when the interrupt needs
+a fast response time. Its potential drawback is that if its computation
+time is not low, the overall schedulabuility can be severly affected.
+This is because the guarantee algorithm does not take into account
+the execution time of the interrupt handlers. The second method, on
+the contrary, is perfectly integrated with the kernel's scheduling
+mechanism, but can cause considerable delays in transferring data.
+
+S.Ha.R.K. provides great flexibility in interrupt handling, since
+it allows each interrupt to be associated with a \textit{fast handler},
+a \texttt{safe handler}, or both.
+
+On an interrupt's arrival the following operations are performed by
+the kernel:
+
+\begin{itemize}
+\item The system checks whether a fast handler is associated with the interrupt.
+If so, the interrupts are enabled and the handler is invoked. This
+method allows a handler to be interrupted by a higher priority handler.
+As an example, the keyboard handler (interrupt 1) can be interrupted
+be the timer handler (interrupt 0).
+\item The system checks whether a sporadic task (\emph{safe handler}) is
+associated with the interrupt. If so, the task is activated and is
+eligible to run with enabled interrupts.
+\end{itemize}
+\noindent The system provides a set of functions for accessing the
+hardaware interfaces' ports. In the drivers directory you can find
+examples of a S.Ha.R.K. device driver.
+
+%----------------------------------------------------------------------------
+\section{Setting an interrupt handler}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\begin{intest}
+HANDLER\_SET\index{handler\_set()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int handler\_set(int no, void (*fast)(int), PID
+pi, BYTE lock);}]
+\item [Description:]It installs function \texttt{fast} (fast handler) and
+the sporadic task \texttt{p} (safe handler) on the interrupt identified
+by \texttt{no}. The \texttt{no} parameter must belong to the range
+1\ldots{}15 (interrupt 0 is associated to the timer and cannot be
+intercepted). On the interrupt's arrival, function \texttt{fast} is
+invoked and runs. Depending on the \texttt{lock} flag, the interrupts
+are disabled (\texttt{lock} = TRUE) or enabled (\texttt{lock} = FALSE)
+during handler execution. Furthermore, on the interrupt's arrival,
+task \texttt{p} is activated.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+HANDLER\_REMOVE\index{handler\_remove()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void handler\_remove(int no);}]
+\item [Description:]It removes the handler of the interrupt number \texttt{intno};
+the interrupt is masked.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Reading and writing from I/O ports}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\begin{intest}
+INP, INPW, INPD \index{inp()} \index{inpw()} \index{inpd()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{unsigned char inp(unsigned short \_port);}]
+\item [\texttt{unsigned short inpw (unsigned short \_port);}]
+\item [\texttt{unsigned long inpd(unsigned short \_port);}]
+\item [Description:]They return the data read on port \texttt{\_port}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+OUTP, OUTPW, OUTPD \index{outp()} \index{outpw()} \index{outpd()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void outp(unsigned short \_port, unsigned char \_data);}]
+\item [\texttt{void outpw(unsigned short \_port, unsigned short \_data);}]
+\item [\texttt{void outpd(unsigned short \_port, unsigned long \_data)}]
+\item [Description:]It writes the data \texttt{\_data} into the port \texttt{\_port}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Disabling/Enabling interrupts}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\begin{intest}
+KERN\_CLI\index{kern\_cli()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void kern\_cli(void);}]
+\item [Description:]It disables interrupts (as the x86 \texttt{cli} instruction).
+\end{description}
+%----------------------------------------------------------------------------
+
+\begin{intest}
+KERN\_STI\index{kern\_sti()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void kern\_sti(void);}]
+\item [Description:]It enables interrupts (as the x86 \texttt{sti} instruction).
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Saving/Restoring interrupts}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\begin{intest}
+KERN\_FSAVE\index{kern\_fsave()}\index{SYS\_FLAGS}
+\end{intest}
+
+\begin{description}
+\item [\texttt{SYS\_FLAGS kern\_fsave(void);}]
+\item [Description:]It disables interrupts (as the x86 \texttt{cli} instruction).
+The CPU flags are returned by the function; in that way they can be
+restored using kern\_frestore
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+KERN\_FRESTORE\index{kern\_frestore()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void kern\_frestore(SYS\_FLAGS f);}]
+\item [Description:]It restores the interrupt state as it was when the
+correspondent \texttt{kern\_fsave} was called.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Masking/Unmasking PIC interrupts}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\begin{intest}
+IRQ\_MASK\index{irq\_mask()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void irq\_mask(WORD irqno);}]
+\item [Description:]It mask the interrupt number \texttt{irqno} on the
+PC PIC. \texttt{irqno} must be in the interval {[}1..15{]}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+IRQ\_UNMASK\index{irq\_unmask()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void irq\_unmask(WORD irqno);}]
+\item [Description:]It unmask the interrupt number \texttt{irqno} on the
+PC PIC. \texttt{irqno} must be in the interval {[}1..15{]}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\chapter{Memory Management Functions}
+%----------------------------------------------------------------------------
+
+The S.Ha.R.K. Kernel provides the standard set of memory allocations
+functions provided by the Standard C libraries. In particular, the
+functions listed in figure \ref{fig:malloc} can be used.
+
+\begin{figure}
+\begin{center} \fbox{\tt{ \begin{minipage}{6cm} \begin{tabbing}
+123\=123\=123\=\kill
+\#include <stdlib.h>\\
+void *calloc(size\_t nmemb, size\_t size);\\
+void *malloc(size\_t size);\\
+void free(void *ptr);\\
+void *realloc(void *ptr, size\_t size);\\
+\end{tabbing} \end{minipage} }} \end{center}
+\caption{\label{fig:malloc}Memory allocation functions.}
+\end{figure}
+In particular \footnote{These descriptions came directly from the Linux man pages...}:
+
+\begin{itemize}
+\item calloc() allocates memory for an array of nmemb elements of size bytes
+each and returns a pointer to the allocated memory. The memory is
+set to zero. The value returned is a pointer to the allocated memory,
+which is suitably aligned for any kind of variable, or NULL if the
+request fails.
+\item malloc() allocates size bytes and returns a pointer to the allocated
+memory. The memory is not cleared. The value returned is a pointer
+to the allocated memory, which is suitably aligned for any kind of
+variable, or NULL if the request fails.
+\item free() frees the memory space pointed to by ptr, which must have been
+returned by a previous call to malloc(), calloc() or realloc(). Otherwise,
+or if free(ptr) has already been called before, undefined behaviour
+occurs. If ptr is NULL, no operation is performed.
+\item realloc() changes the size of the memory block pointed to by ptr to
+size bytes. The contents will be unchanged to the minimum of the old
+and new sizes; newly allocated memory will be uninitialized. If ptr
+is NULL, the call is equivalent to malloc(size); if size is equal
+to zero, the call is equivalent to free(ptr). Unless ptr is NULL,
+it must have been returned by an earlier call to malloc(), calloc()
+or realloc(). It returns a pointer to the newly allocated memory,
+which is suitably aligned for any kind of variable and may be different
+from ptr, or NULL if the request fails or if size was equal to 0.
+If realloc() fails the original block is left untouched - it is not
+freed or moved.
+\end{itemize}
+
+The S.Ha.R.K. Kernel also provides a set of low-level memory management
+functions that can be used to allocate memory with particular requirements
+(for example, they are useful for getting memory blocks aligned to
+a page (4 Kb) boundary or with addresses under 1/16 Mb). Description
+of these functions is given in Chapter 3 of the S.Ha.R.K. Architecture
+Manual.
/branches/new_sharkdoc/vol1/util.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol1/makefile
===================================================================
--- branches/new_sharkdoc/vol1/makefile (nonexistent)
+++ branches/new_sharkdoc/vol1/makefile (revision 1676)
@@ -0,0 +1,4 @@
+MAIN = vol1
+MAIN_NAME = vol1
+
+include ../common/manual.mk
/branches/new_sharkdoc/vol1/makefile
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol1/sys.tex
===================================================================
--- branches/new_sharkdoc/vol1/sys.tex (nonexistent)
+++ branches/new_sharkdoc/vol1/sys.tex (revision 1676)
@@ -0,0 +1,1192 @@
+%----------------------------------------------------------------------------
+\chapter{System Start-up and Termination}
+%----------------------------------------------------------------------------
+
+Each S.Ha.R.K. application starts as a sequential C program, with
+the classical main funcion. The multitasking environment \index{system initialization}
+is already initialized when the application starts. From the main
+task you can call any system primitive.
+
+The system finishes when a sys\_end or sys\_abort function is called,
+or when the last user task is terminated. For more information, see
+\emph{The Generic Kernel Internals} chapter of the S.Ha.R.K. Kernel
+Architecture Manual.
+
+The \texttt{sys\_atrunlevel()} primitive\index{sys\_atexit()} allows
+to post some handlers, which are automatically executed by the kernel
+when it changes runlevel. Such functions can be issued either in the
+target execution environment (generally MS-DOS) or just before terminating
+the S.Ha.R.K. kernel, depending on the third argument of the primitive.
+The handlers posted through \texttt{sys\_atrunlevel()} may also be
+called on a kernel abort due to fatal errors.
+
+%----------------------------------------------------------------------------
+\section{Initialization File\label{sec:InitFile}}
+%----------------------------------------------------------------------------
+
+When the system starts, one of the things to be done before going
+in multitasking mode is to initialize the devices, the resources and
+the schedulers which will be used by the application. To do that,
+the Kernel calls the \_\_kernel\_register\_levels\_\_ function, that
+usually registers the following modules (see the S.Ha.R.K. Kernel
+architecture Manual for more details):
+
+\begin{description}
+\item [Scheduling~Modules]A scheduling module implements a particular
+Scheduling Algorithm (for example EDF, RM, Round Robin, and so on).
+\item [Resource~Modules]A resource module implements a shared resource
+access protocol (for example the semaphores, the mutexes, and so on).
+\item [Other~devices]Such for example the File System, and other devices
+that need to be initialized when the Multitasking Mode is not started
+yet.
+\end{description}
+
+The function returns a TICK value (in microseconds) that is the time
+that will be used for programming the periodic timer interrupt of
+the PC. If a value of 0 is returned, the one-shot timer is used instead
+(see the OSLib documentation for more informations). Typical return
+values range from 250 to 2000 microseconds.
+
+Here is a typical initialization function:
+
+\begin{verbatim}
+TIME __kernel_register_levels__(void *arg) {
+ struct multiboot_info *mb = (struct multiboot_info *)arg;
+ LEVEL EDF_level;
+
+ EDF_level = EDF_register_level(EDF_ENABLE_ALL);
+ RR_register_level(RRTICK, RR_MAIN_YES, mb);
+ CBS_register_level(CBS_ENABLE_ALL, EDF_level);
+ dummy_register_level();
+
+ SEM_register_module();
+ CABS_register_module();
+
+ return 1000;
+}
+\end{verbatim}
+
+As you can see, the system initialization function registers an EDF,
+a Round Robin and a CBS module. Then, It register a dummy Module (that
+usually is the last of the Scheduling Modules). For more informations
+about the Scheduling policies, see Section \ref{sec:sched}. Finally,
+Semaphores and CABS are registered, and a value of 1 ms Tick time
+is returned to initialize the PC's real-time clock.
+
+For a survey of the architecture of the Scheduling Modules and the
+Resource Modules see theKernel Overview Chapter of the S.Ha.R.K. Kernel
+Architecture Manual. A set of Initialization functions can be found
+on the kernel/init directory of the S.Ha.R.K. source tree. An explanation
+of each registration function for each Module can be found in the
+S.Ha.R.K. Module Repository Manual.
+
+After the registration of the modules in the system, the Kernel switch
+in Multitasking mode, and starts the execution of the handlers that
+the modules have posted with the \texttt{sys\_atrunlevel} primitive.
+Usually at least one Module will create and activate a task (for example,
+the Round Robin Scheduling Module does that) that will start when
+all the handlers will be processed. The body of that task is usually
+called \_\_init\_\_() and provides an initialization for the most
+commonly used devices (such the keyboard, and so on) and modules.
+As the last thing, the function simply call the main() function, that
+is, the user application starts. A sample of a typical \_\_init\_\_()
+function is showed below:
+
+\begin{verbatim}
+TASK __init__(void *arg) {
+ struct multiboot_info *mb = (struct multiboot_info *)arg;
+
+ HARTPORT_init();
+ __call_main__(mb);
+ return (void *)0;
+}
+\end{verbatim}
+
+The source code of the \_\_init\_\_() function is usually inserted
+in the initialization file after the \_\_kernel\_register\_levels\_\_
+function. For more information on \_\_call\_main\_\_ see the \texttt{include/kernel/func.h}
+include file.
+
+Using the new driver layer the \_\_init()\_\_ function slightly change.
+First is executed the HARTPORT\_init function that initialize the
+Hartik Port layer (if required), then a task that close all drivers
+is created. The next step is the initialization of all used drivers,
+followed by the registration of the shutdown task that will be executed
+during the system shutdown procedure. At the end the function 'main'
+is executed. A tipical example with the new \_\_init()\_\_ function
+is:
+
+\begin{verbatim}
+TASK __init__(void *arg) {
+ struct multiboot_info *mb = (struct multiboot_info *)arg;
+
+ HARTPORT_init();
+
+ /* Create the shutdown task. */
+ /* It will be activated at RUNLEVEL SHUTDOWN */
+ set_shutdown_task();
+
+ /* Init the drivers */
+ device_drivers_init();
+
+ /* Set the shutdown task activation */
+ sys_atrunlevel(call_shutdown_task, NULL, RUNLEVEL_SHUTDOWN);
+ __call_main__(mb);
+
+ return (void *)0;
+}
+ \end{verbatim}
+
+ATTENTION! In some initialization files the function that activate
+the shutdown task is in the form:
+
+\begin{verbatim}
+#define SHUTDOWN_TIMEOUT_SEC 3
+
+void call_shutdown_task(void *arg) {
+ struct timespec t;
+
+ sys_gettime(&t);
+ t.tv_sec += SHUTDOWN_TIMEOUT_SEC;
+
+ /* Emergency timeout to exit from RUNLEVEL_SHUTDOWN
+ kern_event_post(&t,(void *)((void *)sys_abort_shutdown), (void *)0);
+
+ task_activate(shutdown_task_PID);
+}
+\end{verbatim}
+
+This implementation say that the task has 3 seconds to perform drivers
+stop. After that interval the system is forced to close even is some
+drivers are not closed. If a longer time is needed a greater value
+for \texttt{SHUTDOWN\_TIMEOUT\_SEC} constant must be used. If a shutdown
+without the timer is preferred the function could be in the simpler
+form:
+
+\begin{verbatim}
+void call_shutdown_task(void *arg) {
+ task_activate(shutdown_task_PID);
+}
+\end{verbatim}
+
+%----------------------------------------------------------------------------
+\subsection{Information about the dependencies among modules}
+%----------------------------------------------------------------------------
+
+Some modules, drivers and ports need to use the semaphores managed
+by specific resource sharing modules. In that case, the modules, drivers
+and ports expect the semaphores to be initialized by the application
+into the initialization file. Here there is a brief list of the modules
+which require other module initialization \footnote{All those dependancies wish to be removed.}.
+
+The HARTIK ports (module HARTPORT) use the semaphores, so you must
+include and initialize the semaphores if your application or a module
+used by your application uses the HARTIK ports.
+
+The HARTIK ports are used by the following modules:
+
+\begin{itemize}
+\item ports/first
+\item drivers/net
+\item drivers/input
+\item drivers/oldchar
+\end{itemize}
+The semaphores are also used by:
+
+\begin{itemize}
+\item ports/tftp
+\item drivers/oldsnd.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\section{System primitives}
+%----------------------------------------------------------------------------
+
+Here is a list of primitives whose use is related to the system initialization.
+
+%----------------------------------------------------------------------------
+\begin{intest}
+SYS\_ATRUNLEVEL\index{SYS\_ATRUNLEVEL}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int}]\texttt{sys\_atrunlevel(void (*func\_code)(void *),void
+*parm, BYTE when);}
+\item [Description:]The Generic Kernel supports the specification of the
+functions to be called at system initialization and termination. These
+functions can be registered through this system primitive; the parameters
+for that function are:
+\item [\texttt{f}]the function to be registered;
+\item [\texttt{p}]the parameter to be passed to function \texttt{f} when
+the function will be called;
+\item [\texttt{when}]is the situation in witch that function will be called.
+The correct values are the following:
+
+\begin{description}
+\item [\texttt{RUNLEVEL\_INIT}]Used when programming Modules;
+\item [\texttt{RUNLEVEL\_SHUTDOWN}]The function will be called after a
+call to \texttt{sys\_abort} or \texttt{sys\_end}; The system is still
+in multitasking mode;
+\item [\texttt{RUNLEVEL\_BEFORE\_EXIT}]The function will be called when
+the Kernel exits from multitasking mode;
+\item [\texttt{RUNLEVEL\_AFTER\_EXIT}]The function is called before the
+system hangs (or returns to the host OS, if the proprietary extender
+is used).
+
+\end{description}
+
+It is also possible to specify with an OR operator a flag \texttt{NO\_AT\_ABORT}
+that disables the call to the functions if the system is exiting with
+a \texttt{sys\_abort} function.
+
+\end{description}
+
+You can post at most \texttt{MAX\_RUNLEVEL\_FUNC} functions. See the
+S.Ha.R.K. Kernel Architecture Manual for more details.
+
+\begin{description}
+\item [See]\textbf{also}: \texttt{sys\_init()}, \texttt{sys\_end()}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+EXIT\index{exit}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void exit(int status);}]
+\item [Description:]This function call terminates the Kernel. In this phase,
+the Kernel tries to correctly close all the initialized modules and
+drivers. The functions eventually posted with the \texttt{sys\_at\_runlevel}
+call are also executed.
+
+If called inside an event or inside an ISR, it does return to the
+caller. The system shutdown will start when all the current interrupts
+have been serviced, and the system has been rescheduled. Otherwise,
+this function follows the POSIX specification.
+\item [See]\textbf{also}: \texttt{\_exit()}, \texttt{sys\_panic()}, \texttt{sys\_atrunlevel()}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+\_EXIT\index{\_exit}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void \_exit(int status);}]
+\item [Description:]Same as \texttt{exit()}. functions posted through \texttt{sys\_at\_runlevel}
+with \texttt{NO\_AT\_ABORT} set or functions posted with \texttt{atexit()}
+are not executed.
+\item [See]\textbf{also}: \texttt{exit()}, \texttt{atexit()}, \texttt{sys\_panic()},
+\texttt{sys\_atrunlevel()}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+SYS\_PANIC\index{sys\_end}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void sys\_panic(const char * fmt, ...);}]
+\item [Description:]This function call print a message then call sys\_abort(333).
+\item [See]\textbf{also}: \texttt{sys\_abort()}, \texttt{sys\_end()}, \texttt{sys\_atrunlevel()}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+SYS\_SHUTDOWN\_MESSAGE\index{sys\_\_shutdown\_message}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int sys\_shutdown\_message(char *fmt,...);}]
+\item [Description:]This function call saves a message in a reserved area,
+that will be printed at system shutdown. It does not end the system.
+\item [See]\textbf{also}: \texttt{sys\_panic()}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+SYS\_ABORT\_SHUTDOWN\index{sys\_abort\_shutdown}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int sys\_abort\_shutdown(int err);}]
+\item [Description:]This function will force the system to end the \texttt{SHUTDOWN}
+runlevel if there are system tasks which cannot be stopped. If called
+when the system is still in the \texttt{RUNLEVEL\_RUNNING} runlevel,
+the function behaves like \texttt{exit()}. If called inside an OSLib
+event or inside an IRQ,it does return to the caller. The system shutdown
+will start when all the current interrupts have been serviced, and
+the system has been rescheduled. Otherwise, this function does not
+return.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+SYS\_SET\_REBOOT\index{sys\_set\_reboot}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int sys\_set\_reboot(int mode);}]
+\item [Description:]This function sets the reboot \texttt{mode}, which
+specifies what will happen after the system end. \texttt{mode} options
+are:
+\item [EXIT\_MODE\_HALT:]the system will call the halt (\texttt{HLT}) instruction.
+\item [EXIT\_MODE\_COLD:]the system will perform the cold reboot (slow
+reboot).
+\item [EXIT\_MODE\_WARM:]the system will perform the warm reboot (fast
+reboot).
+\item [EXIT\_MODE\_REAL:]the system will return to the real mode (\textbf{default
+selection}).
+\end{description}
+
+%----------------------------------------------------------------------------
+\chapter{Task Management}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\section{Task Model}
+%----------------------------------------------------------------------------
+
+S.Ha.R.K. tasks are defined using standard C functions which return
+a \texttt{void *} type \footnote{for readability, that type has been called TASK.} and can have one void * argument, which is passed when the task
+is created. A task is identified by a system-wide unique process identifier
+(\texttt{PID}) and a consecutive number \footnote{a task with PID p has a consecutive number that is proc\_table{[}p{]}.task\_ID.}.
+
+A task has tipically a set of Quality of Service requirements that
+need to be fullfilled by the Kernel. The kernel uses its registered
+Scheduling Modules to meet the QoS required by a specified task. The
+QoS reuired is specified at creation time through a Task Model, that
+is passed to the task creation primitives.
+
+A Task, can be \textit{Periodic} or \textit{Aperiodic}. Periodic tasks
+are automatically activated by the kernel with a desired period, whereas
+aperiodic tasks can either be activated by an explicit system call
+or upon the occurrence of a desired event.
+
+The typical task code consists of an optional initialization of local
+variables and resources, followed by a (finite or infinite) loop,
+representing the task's body. The last instruction of such a loop
+must be the primitive \texttt{task\_endcycle()}\index{task\_endcycle()}
+or the primitive \texttt{task\_sleep()} \index{task\_sleep()} which
+signals the end of a generic job.
+
+The task can access a local and a global context by following the
+C scoping rules; the local context is defined by the local variables
+and the single optional input argument. The following example shows
+a typical task code fragment:
+
+\begin{verbatim}
+void *my_task(void *par) {
+
+ /* Local Context*/
+ int a, b, c;
+
+ /* Initialization */
+ b = c = (int)par + 1;
+ a = (int)par / 2;
+ ...
+
+ while (1) {
+
+ /* Body here!*/
+ ...
+
+ task_endcycle();
+ }
+}
+\end{verbatim}
+
+\noindent \texttt{my\_task()} has just one integer input argument
+(passed through the void * parameter) and three local variables\index{local task context}.
+The life-cycle of the local variables is the same as the task one,
+since they are allocated on the task's stack. Obviously they retain
+their values between two consecutive jobs.
+
+\noindent One of the most important parameters for a real-time task
+$\tau_{i}$ is the \emph{deadline}, defined as the maximum time allowed
+for a task job to terminate. More precisely, we distinguish between
+the \emph{absolute deadline} (denoted by $d_{i}$) specified with
+respect to time 0, and the \emph{Relative Deadline} (denoted by $D_{i}$)
+specified with respect to the activation time $r_{i,k}$ of the $k$-th
+job of task $\tau_{i}$. We have that:
+\[
+d_{i}=r_{i,k}+D_{i}.
+\]
+
+\noindent Tasks can also have different level of criticality, for
+example:
+
+\begin{itemize}
+\item \texttt{HARD}\index{HARD} tasks are the most critical in the system.
+For this reason, they are subjected to a guarantee algorithm at creation
+time. The system enforces a strict compliance to the deadline constraint
+for this kind of tasks%
+\footnote{The guarantee algorithm tries to verify that both the newly activated
+hard task and the previously existing ones will finish within their
+deadlines%
+}. If a hard deadline is missed, the system raises an exception which,
+by default, results in the program termination. Recovery actions can
+be programmed for this kind of exception (as shown below).
+\item \texttt{SOFT}\index{SOFT} tasks can miss some deadline, and are scheduled
+in order not to jeopardize HARD tasks' schedulability. This is done
+through a service mechanism (see \ref{sec:sched}) which guarantees
+each soft task a predefined bandwidth (i.e., a fraction of processor
+utilization) while preserving the guarantee performed on hard tasks.
+\item \texttt{NRT}\index{NRT} (Non Real-Time) tasks are scheduled in background
+according to their relative fixed priority. Typically, they are used
+for monitoring or debugging purposes.
+\end{itemize}
+The Task criticality, periodicity and the deadlines are coded into
+the Task Model that is passed to the creation primitive. Each new
+Scheduling Module can use its own Task Model to include the specific
+task QoS requirements.
+
+Each task can be in one of a set of states; the states that a task
+can be in depend on each particular Module. For example, typical Task
+states can be:
+
+\begin{itemize}
+\item \texttt{\textbf{EXE}}\index{EXE}: at any time, in the system there
+is only one task in the EXE state, and it is the task actually executing.
+\item \texttt{\textbf{READY}}\index{READY}: it includes all active tasks
+ready to execute, except for the currently running task.
+\item \texttt{\textbf{SLEEP}}\index{SLEEP}: it includes all aperiodic tasks
+which terminated a job and are waiting for the next activation. Moreover,
+each created task (periodic or aperiodic) that has not been activated
+is put in the SLEEP state.
+\item \texttt{\textbf{IDLE}}\index{IDLE}: is the state of those periodic
+tasks which terminated a job and are waiting for the next activation.
+\item \texttt{\textbf{BLOCKED}}\index{BLOCKED}: it includes all the tasks
+blocked on a semaphore.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\section{The scheduling policy%
+\footnote{This section is derived from the Kernel overview chapter of the S.Ha.R.K.
+Architecture Manual.%
+}\label{sec:sched} }
+%----------------------------------------------------------------------------
+
+The S.Ha.R.K. scheduling architecture is based on a \emph{Generic
+Kernel}, which does not implement any particular scheduling algorithm,
+but postpones scheduling decisions to external entities, the \emph{scheduling
+modules}. External modules can implement periodic scheduling algorithms,
+soft task management through real-time servers, semaphore protocols,
+and resource management policies.
+
+The Generic Kernel provides the mechanisms used by the modules to
+perform scheduling and resource management thus allowing the system
+to abstract from the specific algorithms that can be implemented.
+The Generic Kernel simply provides the primitives without specifying
+any algorithm, whose implementation resides in external modules, configured
+at run-time with the Initialization function.
+
+Scheduling Modules are used by the Generic Kernel to schedule tasks,
+or serve aperiodic requests using an aperiodic server. The Scheduling
+Modules are organized into levels, one Module for each level. These
+levels can be thought as priority scheduling levels (their priority
+correspond to the order which they appear in the Initialization function).
+When the Generic Kernel has to perform a scheduling decision, it asks
+the modules for the task to schedule, according to fixed priorities:
+first, it invokes a scheduling decision to the highest priority module,
+then (if the module does not manage any task ready to run), it asks
+the next high priority module, and so on. The Generic Kernel schedules
+the first task of the highest priority non empty module's queue.
+
+In this way, the Scheduling policy can be tuned simply modifying the
+Initialization function. The standard distribution of the S.Ha.R.K.
+Kernel includes a set of predefined Initialization functions that
+can be used when developing a new application. For more informations
+see the S.Ha.R.K. Module Manual, where each Scheduling Modules and
+each predefined initialization functioon are described in detail.
+
+%----------------------------------------------------------------------------
+\section{Task Creation\index{task creation}}
+%----------------------------------------------------------------------------
+
+In order to run a S.Ha.R.K. task, three steps have to be performed:
+parameters definition, creation, and activation. To improve the system
+flexibility, each task can be characterized by a large number of parameters,
+most of which are optional. For this reason, a set of structures derived
+from \texttt{TASK\_MODEL}\index{MODEL} structure have been introduced
+to simplify the parameters' definition phase. The first thing to do
+in order to define a task is to declare a Model variable and initialize
+it using the pmacro provided (see the S.Ha.R.K. Module Manual for
+more informations).
+
+\noindent Once the task's parameters have been set, the task can be
+created using the \texttt{task\_create} or the \texttt{task\_createn}
+system call.
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_CREATEN\index{task\_createn()} and TASK\_CREATE\index{task\_create()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{PID task\_createn(char *name, TASK (*body)(),
+TASK\_MODEL *m, ...);}]
+\item [\texttt{PID task\_create(char *name, TASK (*body)(),
+TASK\_MODEL *m, RES\_MODEL *r);}]
+\item [Description:]\texttt{task\_createn} creates a new task. \texttt{name}
+is a pointer to a string representing the task name; \texttt{body()}
+is a pointer to the task body (i.e. the name of the C function containing
+the task code); \texttt{m} specifies the Model that contain the QoS
+specification of the task (the value can not be equal to NULL). Then,
+follow a list of Resource Models terminated with NULL (see the S.Ha.R.K.
+Module Manual for the available Task Models and Resource Models).
+\texttt{task\_create} is a redefinition of \texttt{task\_createn}
+that can be used when there is at least one Resource Model to be passed
+to the creation primitive.
+\item [Return]\textbf{value}: The function returns the identifier of the
+newly created task, or -1 if the task creation fails (in this case
+the \texttt{errno()} system call can be used to determine the error's
+cause).
+\item [See]\textbf{also}: \texttt{task\_activate()}, \texttt{task\_kill()}.
+\item [Example]~
+\end{description}
+
+\begin{verbatim}
+int main(int argc, char **argv) {
+ HARD_TASK_MODEL m;
+ hard_task_default_model(m);
+ hard_task_def_wcet(m,ASTER_WCET);
+ hard_task_def_mit(m,10000);
+ hard_task_def_group(m,1);
+ hard_task_def_ctrl_jet(m);
+
+ p1 = task_create("Aster", aster, &m, NULL);
+ if (p1 == -1) {
+ perror("Error: Could not create task <aster> ...");
+ exit(1);
+ }
+}
+\end{verbatim}
+
+
+%----------------------------------------------------------------------------
+\section{Group Creation}
+%----------------------------------------------------------------------------
+
+Group creation is a feature provided by S.Ha.R.K. that allows a user
+to create a set of tasks. The group creation differs from the creation
+made by the task\_create and task\_createn primitives because in group
+creation the acceptance test is done for the whole set of task (and
+not for every task in sequence) only when every task which belong
+to the set has been initialized in the system. After the acceptance
+test, the user have to inquire the Scheduling Module to see the tasks
+that have been accepted and successfully created in the system.
+
+The primitives provided by S.Ha.R.K. to support group creation are:
+
+\begin{itemize}
+\item group\_create
+\item group\_create\_accept
+\item group\_create\_reject
+\end{itemize}
+The documentation about group creation can be found in the \emph{Group
+creation HOWTO} available on the S.Ha.R.K. website.
+
+%----------------------------------------------------------------------------
+\section{Task Activation and Termination}
+%----------------------------------------------------------------------------
+
+When a task is created, it is put in the \texttt{SLEEP} state, where
+it is kept until activation, which can be triggered by an external
+interrupt or by an explicit \texttt{task\_activate()} primitive).
+Periodic jobs that complete execution are handled by the registered
+Scheduling Modules (usually they are put in an \texttt{IDLE} state
+or similar), from which they will be automatically re-activated by
+the system timer. Aperiodic jobs that complete execution return to
+the \texttt{SLEEP} state, where they wait for an explicit re-activation.
+
+Some scheduling models (such as the EDF and RM modules) support release
+offsets. In an offset is given in the task model, the \texttt{task\_activate()}
+will put the task in the \texttt{IDLE} state, waiting for the first
+release to occur.
+
+A task can be destroyed using the \texttt{task\_kill()} system call,
+that frees its descriptor. A task can kill itself using the \texttt{task\_abort()}
+system call.
+
+In S.Ha.R.K., tasks can be members of groups to allow simultaneous
+activation or termination. A task can be put in a group through a
+macro that works on the task model passed at task creation. The name
+of the macro depends on the name of the Task Model used; usually its
+name is like \texttt{XXX\_task\_def\_group(group\_number)}, where
+XXX is the name of the task Model; the group\_number 0 indicates that
+a task belongs to no groups.
+
+Task cancellation, join, the cleanup handlers and the task specific
+data works as the POSIX standard; only the name of the primitives
+are changed from \texttt{pthread\_XXX} to \texttt{task\_XXX}. In any
+case, the \texttt{pthread\_XXX} versions are available for POSIX compatibility.
+
+\textbf{Warning}: \texttt{task\_kill()} kills a task only if the cancellation
+type of the task is set to asynchronous. If the cancellation type
+is set to deferred, the task will terminate only when it reach a cancellation
+point.
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_ACTIVATE\index{task\_activate()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int task\_activate(PID p);}]
+\item [Description:]It activates task \texttt{p}. Usually the activation
+will insert the task into the ready queue. (If the task has an offset,
+the task will be put in the ready queue after the offset.) Returns
+0 in case of success or -1 in case of error; the \texttt{errno} variable
+is set to \texttt{EUNVALID\_TASK\_ID}.
+\item [See]\textbf{also}: \texttt{task\_create(), task\_kill(), group\_activate()}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_KILL\index{task\_kill()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int task\_kill(PID p);}]
+\item [Description:]It asks for a cancellation of the task p. It returns
+-1 in case of error, 0 otherwise. If an error occurred, the errno
+variable is set to \texttt{EINVALID\_KILL}. A task which has the NO\_KILL
+flag set can not be killed. If the task has already been killed but
+it is not died yet, the primitive does nothing. A task that has the
+cancellation type set to asynchronous will die just when it will be
+scheduled again by the system; instead, if the cancellation type is
+set to deferred, the task will die only at the reaching of a cancellation
+point. This function is the correspondent of the \texttt{pthread\_cancel()}
+primitive.
+\item [See]\textbf{also}: \texttt{task\_create(), task\_activate(), group\_kill()}.
+\end{description}
+\pagebreak
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_ABORT\index{task\_abort()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void task\_abort(void *returnvalue);}]
+\item [Description:]It aborts the calling task, removing it from the system.
+If the task is joinable, the return value will be stored by the kernel
+and given to any task that calls a task\_join primitive on the died
+task.
+\item [See]\textbf{also}: \texttt{task\_create(), task\_activate(), task\_kill()}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_BLOCK\_ACTIVATION\index{task\_block\_activation()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int task\_block\_activation(PID p);}]
+\item [Description:]It blocks all explicit activation of a task made with
+\texttt{task\_activate} and \texttt{group\_activate}. The activations
+made after this call are buffered (counted) in an internal counter.
+It returns 0 in case of success or -1 in case of error. In the latter
+case, \texttt{errno} is set to \texttt{EUNVALID\_TASK\_ID}. If the
+activations were already blocked, it does nothing.
+\item [See]\textbf{also}: \texttt{task\_unblock\_activation(), task\_activate()}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_UNBLOCK\_ACTIVATION\index{task\_unblock\_activation()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int task\_unblock\_activation(PID p);}]
+\item [Description:]It unblocks the activations of a task after a call
+to task\_block\_activation. After this call, the task can be explicitly
+activated. It returns the number of buffered activations, or -1 if
+an error occurred. If an error occurred, the errno variable is set
+to EUNVALID\_TASK\_ID. If the activations were not blocked, it simply
+returns 0. Note that the primitive simply returns the number of buffered
+activations, \emph{without} activating the task.
+\item [See]\textbf{also}: \texttt{task\_block\_activation(), task\_activate()}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+GROUP\_ACTIVATE\index{group\_activate()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int group\_activate(WORD g);}]
+\item [Description:]It activates all tasks belonging to group \texttt{g}.
+Returns 0 in case of success or -1 in case of error; the \texttt{errno}
+variable is set to \texttt{EUNVALID\_GROUP}.
+\item [See]\textbf{also}: \texttt{task\_create(), task\_activate(), group\_kill()}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+GROUP\_KILL\index{group\_kill()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void group\_kill(WORD g);}]
+\item [Descrizione:]It kills all tasks belonging to group \texttt{g}. It
+returns -1 in case of error, 0 otherwise. If an error occurred, the
+errno variable is set to \texttt{EUNVALID\_GROUP}. The kill request
+to a single task that belong to a group is done in a way similar to
+that done in the primitive \texttt{task\_kill()}.
+\item [See]\textbf{also}: \texttt{task\_create(), task\_activate(), group\_activate()},
+\texttt{task\_kill()}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Task Instances}
+%----------------------------------------------------------------------------
+
+S.Ha.R.K. supports the concept of instance for its task. A typical
+task function is composed by an initialization part and a body part
+that does the work for that the task was created; for example:
+
+\begin{verbatim}
+void *mytask(void *arg) {
+ /* initialization part */
+
+ for (;;) {
+ /* body */
+ ...
+
+ task_endcycle();
+ }
+}
+\end{verbatim}
+
+In the example, the task will never terminate, and it also calls the
+\texttt{task\_endcycle} primitive to say to the Kernel that the current instance
+is terminated \footnote{The concept of instance is introduced into S.Ha.R.K.
+because in that way the Kernel can directly support task Quality Of Service
+parameters like deadlines, periods and so on in a native way. Note that the
+concept of instance is not covered by the POSIX standard, that only support a
+fixed priority scheduler. In POSIX, a periodic task can only be implemented
+using the Real-Time extensions and in particular using the Timer feature.
+S.Ha.R.K. implements also that approach, however the native primitives are
+better in terms of efficiency.}.
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_ENDCYCLE\index{task\_endcycle()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void task\_endcycle(void);}]
+\item [Description:]It terminates the currently executing job of the calling
+task. The behaviour of this primitive may sligtly change depending
+on the Scheduling Module registered at initialization time. Tipically,
+the \texttt{task\_endcycle} primitive suspends the task until an automatic
+reactivation that is made internally by the Kernel. Moreover, the
+\texttt{task\_endcycle()} primitive usually keeps track of pending
+activations \footnote{There is a pending activation when a task is activated before the
+current instance has finished. In this case, if the \texttt{task\_endcycle()}
+primitive is called and there is a pending activation, it simply does
+nothing.}. Previous versions of the kernel supported a \texttt{task\_sleep()}\index{task\_sleep()}
+primitive with similar behavior. That function is currently unsupported.
+The primitive is a cancellation point.
+\item [Implementation:]This primitive is implemented as task\_message(NULL, 1);
+\footnote{Note on the implementation: this primitive is implemented as
+\texttt{task\_message(NULL, 1);}}
+\item [See]\textbf{also:} \texttt{task\_activate}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Task (thread) specific data}
+%----------------------------------------------------------------------------
+
+These functions works in a way equal to their POSIX counterparts.
+These primitives are used for managing task specific data, that are
+a few data variables that can be referred in a common way independently
+from the task that asks for it. The system also ensures a proper cleanup
+when the task is killed. As an example, the \texttt{errno} variable
+can be thought as a task specific data. In this manual only their
+interfaces are described; for more informations, see the POSIX standard.
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_KEY\_CREATE\index{task\_key\_create()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int task\_key\_create(task\_key\_t *key, void
+(*destructor)(void *));}]
+\item [Description:]It creates a task key that can be used to refer a task\_specific
+data. The name of the POSIX counterpart is \texttt{pthread\_key\_create}.
+\end{description}
+\pagebreak
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_GETSPECIFIC\index{task\_getspecific()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void *task\_getspecific(task\_key\_t key);}]
+\item [Description:]It gets the current value for the key (note that the
+value of the key vary from task to task). The name of the POSIX counterpart
+is \texttt{pthread\_getspecific}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_SETSPECIFIC\index{task\_setspecific()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int task\_setspecific(task\_key\_t key, const void
+*value); }]
+\item [Description:]It sets the current value for the key. The name of
+the POSIX counterpart is \texttt{pthread\_setspecific}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_KEY\_DELETE\index{task\_key\_delete()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int task\_key\_delete(task\_key\_t key);}]
+\item [Description:]It deletes the current key. The name of the POSIX counterpart
+is \texttt{pthread\_key\_delete}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Task cancellation}
+%----------------------------------------------------------------------------
+
+These primitives are used when managing task cancellation. They are
+directly derived from the POSIX standard. Nothe that the POSIX interface
+is also available.
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_CLEANUP\_PUSH\index{task\_cleanup\_push()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void task\_cleanup\_push(void (*routine)(void
+*), void *arg);}]
+\item [Description:]It pushes the specified cancellation cleanup handler
+routine onto the cancellation cleanup stack. The name of the POSIX
+counterpart is \texttt{pthread\_cleanup\_push}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_CLEANUP\_POP\index{task\_cleanup\_pop()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void task\_cleanup\_pop(int execute);}]
+\item [Description:]It removes the routine at the top of the cancellation
+cleanup stack of the calling thread. If \texttt{execute} is not equal
+0, the routine previously pushed is called. The name of the POSIX
+counterpart is \texttt{pthread\_cleanup\_pop}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_TESTCANCEL\index{task\_testcancel()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void task\_testcancel(void);}]
+\item [Description:]creates a cancellation point in the calling task. The
+primitive has no effect if cancelability is disabled. The name of
+the POSIX counterpart is \texttt{pthread\_testcancel}.
+\end{description}
+
+\pagebreak
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_SETCANCELSTATE\index{task\_setcancelstate()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int task\_setcancelstate(int state, int *oldstate);}]
+\item [Description:]This primitive sets the cancelability state of the
+calling thread to the indicate \emph{state} \emph{and} returns the
+previous cancelability state at the location referenced by \emph{oldstate}.
+Legal values for state are \texttt{TASK\_CANCEL\_ENABLE} and \texttt{TASK\_CANCEL\_DISABLE}.
+\texttt{pthread\_setcancelstate} is the name of the POSIX counterpart.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_SETCANCELTYPE\index{task\_setcanceltype()}
+\end{intest}
+
+\begin{description}
+\item [int task\_setcanceltype(int type, int *oldtype);]
+\item [Description:]This primitive sets the cancelability type of the calling
+thread to the indicate \emph{type} and returns the previous cancelability
+type at the location referenced by \emph{oldtype}. Legal values for
+state are \texttt{TASK\_CANCEL\_DEFERRED} and \texttt{TASK\_CANCEL\_ASINCHRONOUS}.
+The name of the POSIX counterpart is \texttt{pthread\_setcanceltype}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Join}
+%----------------------------------------------------------------------------
+
+The join primitives allow a task to wait for the termination of another task
+\footnote{not of an instance of a task!}. The return value of the terminated
+task is passed to the join primitive and the caller can use the value. These
+primitives are directly derived from the POSIX standard. It means that a join
+can be done only on a joinable task. But note that when a task created with the
+creation primitives \footnote{\texttt{task\_create}, \texttt{task\_createn},
+\texttt{group\_create}} starts it is \emph{not} in the joinable state
+\footnote{this is done to remain similar to the previous versions of the Hartik
+Kernel...}. This behaviour differs from the standard behavior of the POSIX
+standard, which specifies that every new task shall be in the joinable state.
+However, S.Ha.R.K. provides also the \texttt{pthread\_create} primitive that is
+\emph{fully compliant} with the standard. Finally, a S.Ha.R.K. task can switch
+between the jonable and non-joinable state using the primitives
+\texttt{task\_joinable} and \texttt{task\_unjoinable} \footnote{In the POSIX
+standard, only the \texttt{pthread\_detach} primitive is available.}.
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_JOIN\index{task\_join()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int task\_join(PID p, void **value);}]
+\item [Description:]The primitive suspends the execution of the calling
+task until the task p terminates, unless the task p has already terminated.
+On return from a successful \texttt{task\_join} call with a non-\texttt{NULL}
+\emph{value} argument, the value returned by the thread through a
+task\_abort shall be made available in the location referenced by
+\emph{value}. When the primitive returns successfully the target task
+has been terminated. The primitive returns 0 in case of success, otherwise
+it returns \texttt{EINVAL} if the value \texttt{p} does not refer
+to a task that can be joined, \texttt{ESRCH} if the value \texttt{p}
+does not refer to a valid task, and \texttt{EDEADLK} if a deadlock
+was detected. The name of the POSIX counterpart is \texttt{pthread\_join}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_JOINABLE\index{task\_joinable()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int task\_joinable(PID p);}]
+\item [Description:]This function set the detach state of a task p to joinable.
+This function is not present in Posix standard. It returns ESRCH if
+p is non a valid task.
+\end{description}
+\pagebreak
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_UNJOINABLE\index{task\_unjoinable()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int task\_unjoinable(PID p);}]
+\item [Description:]This function sets the detach state of a task to detached.
+The name of the POSIX counterpart is \texttt{pthread\_detach}. The
+function returns \texttt{EINVAL} if \texttt{p} can not be joined (or
+currently a task has done a join on it), or \texttt{ESRCH} if \texttt{p}
+is not correct.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Preemption control}
+%----------------------------------------------------------------------------
+
+S.Ha.R.K. provides two primitives that set the preemptability of a
+task. A non-preemptive task can not be preempted by another task;
+interrupts are handled in the usual way. These primitives can be used
+to implement short critical sections. Note the difference between
+this kind of non -preemption and the interrupt disabling done using
+kern\_cli and kern\_sti: in the latter case, interrupt can not preempt
+the critical sections. A new task usually starts in a preemptive state.
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_NOPREEMPT\index{task\_nopreempt()}
+\end{intest}
+
+\begin{description}
+\item [void task\_nopreempt(void);]
+\item [Description:]After the call of this primitive, the task is non-preemptive.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_PREEMPT\index{task\_preempt()}
+\end{intest}
+
+\begin{description}
+\item [void task\_nopreempt(void);]
+\item [Description:]After the call of this primitive, the task become again
+preemptive.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Suspending a task}
+%----------------------------------------------------------------------------
+
+The following system calls can be used by a task to suspend itself
+for a known or unknown time. (Note: it is dangerous to use these system
+calls in a hard real-time task.)
+
+%----------------------------------------------------------------------------
+\begin{intest}
+TASK\_DELAY\index{task\_delay()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void task\_delay(DWORD t);}]
+\item [Description:]It causes the calling task to be blocked for at least
+\texttt{t} microseconds. Note that \texttt{t} is the \emph{minimum}
+delay time. In facts, after \texttt{t} microseconds the task is inserted
+in the ready queue and can be delayed by higher priority tasks. This
+function was inherited from the previous versions of Hartik. Please,
+use the POSIX counterpart \texttt{nanosleep} instead!
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Job ExecutionTime (JET) estimation}
+%----------------------------------------------------------------------------
+
+S.Ha.R.K. provides a set of primitives that allows to precisely estimate
+the system load. These primitives can be used to tune the parameters
+that are given at task creation, and to get statistics about the system
+load.
+
+The execution time estimation is done on a task basis. That is, S.Ha.R.K.
+provides three primitives that allows the user to estimate the JET
+of every task. For every task, it is possible to know the mean execution
+time, the maximum execution time, the time consumed by the current
+instance and the time consumed by the last \texttt{JET\_TABLE\_DIM}
+instances.
+
+The user have to explicitly enable the Kernel to record the JET informations
+for a specific task. This is done at task creation time; usually a
+macro that enable the JET is provided in the definition of every task
+model (see the S.Ha.R.K. Module Manual).
+
+Here is an example of the use of the JET functions:
+
+\begin{verbatim}
+/* The Goofy Task */
+void *goofy(void *arg) {
+ int i;
+ for (;;) {
+ for (i = 0; i < 100; i++)
+ kern_printf("Yuk!");
+ task_endcycle();
+ }
+}
+
+PID goofy_PID;
+
+/* a NRT task that never finish */
+
+void *jetcontrol(void *arg) {
+ TIME sum, max, curr, last[5];
+ int nact;
+
+ for (;;) {
+ if (jet_getstat(p, &sum, &max, &nact, &curr) == -1)
+ continue;
+ for (j = 0; j < 5; j++) last[j] = 0;
+ jet_gettable(p, &last[0], 5);
+ printf_xy(1, 20, WHITE,"goofy_PID=%d mean=%d max=%d nact=%d",
+ goofy_PID, sum / (nact == 0 ? 1 : nact), max, nact);
+ printf_xy(1, 21, WHITE, "L1=%d L2=%d L3=%d L4=%d L5=%d",
+ last[0], last[1], last[2], last[3], last[4]);
+ }
+}
+
+*int main(int argc, char **argv) {
+ ...
+
+ /* The task goofy is created, specifying that the Kernel
+ should take care of the JET data */
+
+ HARD_TASK_MODEL m;
+
+ hard_task_default_model(m);
+
+ /* ... other hard_task_XXX macros */
+ hard_task_def_ctrl_jet(m); /* JET enabling */
+ goofy_PID = task_create("Goofy", goofy, &m, NULL);
+
+ /* ... creation of the JET control task, and so on */
+}
+\end{verbatim}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+JET\_GETSTAT\index{jet\_getstat()}
+\end{intest}
+
+\begin{description}
+\item [int jet\_getstat(PID p, TIME *sum, TIME *max, int *n, TIME
+*curr);]
+\item [Description:]This primitive returns some JET informations about
+the task p. The informations retrieved are stored into the following
+parameters:
+
+\begin{description}
+\item [\texttt{sum}]is the task total execution time since it was created
+or since the last call to the \texttt{jet\_delstat} function;
+\item [\texttt{max}]is the maximum time used by a task instance since it
+was created or since the last call to the \texttt{jet\_delstat} function;
+\item [\texttt{n}]is the number of terminated instances which sum and max
+refers to;
+\item [\texttt{curr}]is the total execution time of the current instance.
+\end{description}
+
+If a parameter is passed as \texttt{NULL} the information is not returned.
+The function returns 0 if the \texttt{PID} passed is correct, \texttt{-1}
+if the PID passed does not correspond to a valid PID or the task does
+not have the \texttt{JET\_ENABLE} bit set.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+JET\_DELSTAT\index{jet\_delstat()}
+\end{intest}
+
+\begin{description}
+\item [int jet\_delstat(PID p);]
+\item [Description:]The primitive voids the actual task execution time
+data mantained by the Generic Kernel. The function returns 0 if the
+PID passed is correct, \texttt{-1} if the PID passed does not correspond
+to a valid PID or the task does not have the \texttt{JET\_ENABLE}
+bit set.
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+JET\_GETTABLE\index{jet\_gettable()}
+\end{intest}
+
+\begin{description}
+\item [int jet\_gettable(PID p, TIME *table, int n);]
+\item [Description:]The primitive returns the last \texttt{n} execution
+times of the task \texttt{p}. If the parameter n is less than 0, it
+returns only the last values stored since the last call to \texttt{jet\_gettable}
+(up to a maximum of \texttt{JET\_TABLE\_DIM} values). If the value
+is greater than 0, the function returns the last \texttt{min(n,~JET\_TABLE\_DIM)}
+values registered. The return value is \texttt{-1} if the task passed
+as parameter does not exist or the task does not have the \texttt{JET\_ENABLE}
+bit set, otherwise the number of values stored into the array is returned.
+The table passed as parameter should store at least \texttt{JET\_TABLE\_DIM}
+elements.
+\end{description}
+
/branches/new_sharkdoc/vol1/sys.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol1/introd.tex
===================================================================
--- branches/new_sharkdoc/vol1/introd.tex (nonexistent)
+++ branches/new_sharkdoc/vol1/introd.tex (revision 1676)
@@ -0,0 +1,361 @@
+%----------------------------------------------------------------------------
+\chapter{Introduction}
+%----------------------------------------------------------------------------
+
+Real-time computing is required in many application domains, ranging
+from embedded process control to multimedia systems. Each application
+has peculiar characteristics in terms of timing constraints and computational
+requirements (such as periodicity, criticality of the deadlines, tolerance
+to jitter, and so on). For this reason, a lot of different scheduling
+algorithms and resource allocation protocols have been proposed to
+conform to such different application demands, from the classical
+fixed or dynamic priority allocation schemes to adaptive or feedback-based
+systems.
+
+However, most of the new approaches have been only theoretically analyzed,
+and sometimes evaluated using a scheduling simulator. In this case,
+the algorithm performance is not evaluated on real examples, but only
+on a synthetic workload. This choice is often dictated from the fact
+that writing a kernel from scratch every time a new scheduling algorithm
+is proposed would be unrealistic and would not offer the availability
+of meaningful applications. A more effective approach is to modify
+an existing kernel (such as Linux), since most of the existing applications
+and device drivers written for the host OS can be used in a straightforward
+fashion. On the other hand, a general purpose kernel is designed aiming
+at specific goals and generally its architecture is not modular enough
+for replacing or modifying the scheduling policy. Moreover, classical
+OSs do not allow to easily define a scheduling policy for resources
+other than the CPU and this poses a further limitation for testing
+novel research solutions. This is mainly due to the fact that the
+classical OS structure does not permit a precise \emph{device scheduling}
+(due to problems involving resource contention, priority inversion,
+interrupt accounting, long non-preemptive sections, and so on). A
+small kernel providing short non-preemptable sections, aperiodic real-time
+threads for handling interrupts, and a distinction between \emph{device
+drivers} accessing the hardware and \emph{device managers} implementing
+the \emph{device scheduling} algorithms would help the progress in
+this research field. The problems explained above emerge both in the
+educational and research environments, when the focus is oriented
+in developing and testing new scheduling algorithms rather than hacking
+the code of a complex system.
+
+S.Ha.R.K. (Soft and Hard Real-time Kernel), is a research kernel purposely
+designed to help the implementation and testing of new scheduling
+algorithms, both for the CPU and for other resources. The kernel can
+be used to perform early validation of the scheduling algorithms produced
+in the research labs, and to show the application of real-time scheduling
+in real-time systems courses. These goals are fulfilled by making
+a trade off between simplicity and flexibility of the programming
+interface on one hand and efficiency on the other. This approach allows
+a developer to focus his/her attention on the real algorithmic issues,
+thus saving significant time in the implementation of new solutions.
+Another important design guideline is the use of standard naming conventions
+for the support libraries in order to ease the porting of meaningful
+applications written for other platforms. The results have been satisfactory
+for applications such as an MPEG player, a set of network drivers
+and a FFT library.
+
+The kernel provides the basic mechanisms for queue management and
+dispatching and uses one or more external configurable modules to
+perform scheduling decisions. These external modules can implement
+periodic scheduling algorithms, soft task management through real-time
+servers, semaphore protocols, and resource management policies. The
+modules implementing the most common algorithms (such as RM, EDF,
+Round Robin, and so on) are already provided, and it is easy to develop
+new modules. Each new module can be created as a set of functions
+that \emph{abstract} from the implementation of the other scheduling
+modules and from the resource handling functions. Also the applications
+can be developed independently from a particular system configuration,
+so that new modules can be added or replaced to evaluate the effects
+of specific scheduling policies in terms of predictability, overhead,
+and performance. Low-level drivers for the most typical hardware resources
+(like network cards, graphic cards, and hard disks) are also provided,
+without imposing any form of device scheduling. In this way, device
+scheduling can be implemented by the user to test new solutions. To
+avoid the implementation of a new non-standard programming interface,
+which would discourage people from using the kernel, S.Ha.R.K. implements
+the standard POSIX 1003.13 PSE52 interface
+%
+% Tool: no such reference!
+%
+% \cite{POSIX1003.1,POSIX1003.13}
+.
+
+This manual was derived from the Hartik User Manual release 3.3.1.
+
+%----------------------------------------------------------------------------
+\section{General Description}
+%----------------------------------------------------------------------------
+
+S.Ha.R.K. has been designed as a library of functions which extends
+the classical C library, by providing a multiprogramming environment
+with an explicit management of time. From a logical point of view,
+the system is based on a \emph{Host} computer where the application
+is developed and on a \emph{Target} computer where the application
+executes. Development tools are located on the host system, where
+a general purpose operating system is used. After its compilation,
+the application is loaded on the target system using the appropriate
+\emph{loader}. This separation, typical of many hard real-time development
+systems, enables the final application to run on a variety of target
+systems, ranging from typical PC to embedded micro-controllers. From
+a practical point of view, host and target may be the same computer
+and in the rest of this manual we will not further distinguish between
+them.
+
+S.Ha.R.K. has been developed focusing on modularity of the kernel
+source code. S.Ha.R.K. is fundamentally a set of routines that runs
+on top of a library for OS development called OSLib (see http://oslib.sourceforge.net)
+that has these requirements:
+
+\begin{description}
+
+\item [Operating~System~(OS)]You can compile OSLib/S.Ha.R.K. programs
+using some different host OS. In theory, any OS supporting gcc can
+be used; in practice, we successfully compiled OSLib/S.Ha.R.K. from
+Linux, DOS and Cygwin.
+
+\item [Compiler]The used compiler is gcc. You can use the gcc version that
+you prefer (we tested gcc 3.3.3 and older version), the important
+thing is that the linker must produce ELF binaries (in order to be
+MultiBoot compliant and to avoid problems with the Linux source code
+inside S.Ha.R.K.). An ELF cross-compile version of gcc is included
+inside the DJGPP distribution on the S.Ha.R.K. website, so you can
+easily compile OSLib/S.Ha.R.K. programs inside a standard DOS environment.
+To compile under Cygwin, it is required to build an ELF cross-compile
+gcc/linker couple.
+
+\item [Other~utilities]GNU Make \index{Make}, uname, pwd, cp, rm, X (these
+utilities can be found in the utility package on the S.Ha.R.K. web
+site).
+
+\item [Target~Requirements]The target have to be at least a PC based on
+Intel 80486 (or compatible) - SMP is not supported - with at least
+4Mb of RAM. In order to load OSLib/S.Ha.R.K. programs (MultiBoot compliant),
+the target must have GRUB installed, or it must run a real mode operating
+system (such as MS-DOS or FreeDOS). If you intend to boot OSLib/S.Ha.R.K.
+programs from DOS, you also have to download our DOS eXtender X.
+
+\end{description}
+
+Compilation and application linking can be done using the \emph{make}\index{make}
+utility, available in any of the development environments mentioned
+above. In this case, a {}``makefile''\index{makefile} containing
+the names of all of the .C files composing the application and the
+directives to link the needed libraries have to be written. For more
+information, you can look at the installation txt file from the website
+download page.
+
+%----------------------------------------------------------------------------
+\section{SHARK.CFG}
+%----------------------------------------------------------------------------
+
+Inside \texttt{shark.cfg} you can find the main parameters for S.Ha.R.K.
+configuration. All the stettings inside this file will be crucial
+to run correctly S.Ha.R.K. and to get the maximum performaces on a
+x86 machines. The most important options related to the Real-Time
+behaviour are:
+
+\begin{description}
+\item MEM\_START = [number]
+\end{description}
+
+\begin{itemize}
+\item Kernel image start point. The kernel image file will be loaded starting
+from this physical memory address. Default value is 0x220000, but DOS users,
+should set an high address (like 0x1720000) if Smartdrive or other tools which
+require Extended Memory are used.
+\end{itemize}
+
+\begin{description}
+\item TSC = [TRUE,FLASE]
+\end{description}
+
+\begin{itemize}
+\item This option enables the Time Step Counter inside the CPU (Pentium
+or higher). Kern\_gettime function will use the TSC register which
+is faster and more precise than the external PIT. The default value
+is TRUE. If the system cannot find the TSC, this feature will be disabled
+and PIT will be used to get the system time.
+\end{itemize}
+
+\begin{description}
+\item APIC = [TRUE,FALSE]
+\end{description}
+
+\begin{itemize}
+\item This option enables the APIC (Pentium Pro or higher). As TSC, APIC
+is faster and more precise than the standard PIT. It will be used
+to generate the timer interrupts. The default value is TRUE. If the
+system cannot find the APIC, the feature will be disabled. On some
+embedded systems or old PC, the APIC check could hang the system,
+so you must disable it manually. APIC requires the TSC.
+\end{itemize}
+
+\begin{description}
+\item TIMER\_OPT = [1000,2000,4000,8000]
+\end{description}
+
+\begin{itemize}
+\item Enable TSC read timer optimization. The 4 values are suggested for
+different CPU speeds, allowing different wraparound performance: TIMER\_OPT =
+1000 for CPU < 1 GHz, wraparound of 585 years; TIMER\_OPT = 2000 for 1 GHz <
+CPU < 2 GHz, wraparound of 146 years; TIMER\_OPT = 4000 for 2 GHz < CPU < 4 GHz,
+wraparound of36 years; TIMER\_OPT = 8000 for CPU < 8 GHz, wraparound of 292
+years.
+\end{itemize}
+
+\begin{description}
+\item TRACER = [NO,OLD,NEW]
+\end{description}
+
+\begin{itemize}
+\item Select the tracer to be used for tracing events. While TRACER = OLD is for
+backward compatibility, TRACER = NEW should be the preferred option when event
+tracing is required. The event tracer can be disabled by selecting TRACER = NO.
+\end{itemize}
+
+\begin{description}
+\item BIOS = [X,VM86]
+\end{description}
+
+\begin{itemize}
+\item Select the BIOS interrupt access mode. BIOS = X means that you must use
+x.exe as shark loader if shark needs to call BIOS interrupt (Ex. to enable
+graphics); BIOS = VM86 means that shark call the BIOS interrupts as Virtual
+Machine 86, and you can load a graphical demo also through GRUB.
+\item Notice that VM86 MODE IS NOT COMPATIBLE WITH SOME VGA CARDS (like MATROX).
+\end{itemize}
+
+\begin{description}
+\item FB = [VESA,FINDPCI,VGA16]
+\end{description}
+
+\begin{itemize}
+\item Select the FrameBuffer configuration. It can use the VBE interrupts to
+enable the selected video mode (VESA), or enable the VGA16 (4 bit per plane)
+video mode (VGA16). Using FINDPCI, the FrameBuffer driver will try to find a
+PCI/AGP graphical card. If a card is found, FB will use a specific driver to
+enable it; however, few graphic adapters are currently supported with specific
+drivers. Since almost all adapters support the VESA standard, FB = VESA is
+usually the best choice.
+\end{itemize}
+
+\begin{description}
+\item FG = [NORMAL,FORCE\_PXC]
+\end{description}
+
+\begin{itemize}
+\item Select the FrameGrabber configuration. FORCE\_PXC forces the frame grabber to init a PXC200 card, and should be used carefully.
+\end{itemize}
+
+\begin{description}
+\item SHARK\_FS = [YES,NO]
+\end{description}
+
+\begin{itemize}
+\item Select the S.Ha.R.K. file system support. SHARK\_FS = YES makes the kernel
+to include the File System library, which supports the FAT16 filesystem only. If
+you don't have a FAT16 filesystem, set SHARK\_FS = NO.
+\end{itemize}
+
+\begin{description}
+\item [{\Large NOTE:}]{\Large You must recompile S.Ha.R.K. if you modify}
+\texttt{\Large shark.cfg}{\Large \par}
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Predefined Types and Constants}
+%----------------------------------------------------------------------------
+
+Tables~\ref{t:types}, \ref{t:task}, \ref{t:stati}, \ref{t:limits}
+show a subset of the predefined data types in S.Ha.R.K., a subset
+of the possible task states and Models and the system basic constants.
+
+\begin{table}
+\begin{center}\begin{tabular}{|l|l|}
+\hline
+\emph{Type} & \emph{Description} \\
+\hline
+BYTE & unsigned char, {[}0, 255{]} \\
+WORD & unsigned int, {[}0, 65535{]} \\
+DWORD & unsigned long, {[}0, 0xFFFFFFFF{]} \\
+TIME & unsigned long, {[}0, 0xFFFFFFFF{]} \\
+PID & Task identifier \\
+TASK & task \\
+PORT & communication endpoints \\
+CAB & cyclic asynchronous buffers \\
+\hline
+\end{tabular}\end{center}
+\caption{\label{t:types}Predefined types.}
+\end{table}
+
+\begin{table}
+\begin{center}\begin{tabular}{|l|c|}
+\hline
+\emph{Identifier} & \emph{Value}\\
+\hline
+FREE & 0 \\
+EXE & 1 \\
+SLEEP & 2 \\
+WAIT\_JOIN & 3 \\
+WAIT\_COND & 4 \\
+WAIT\_SIG & 5 \\
+WAIT\_SEM & 6 \\
+WAIT\_NANOSLEEP & 7\\
+WAIT\_SIGSUSPEND & 8 \\
+WAIT\_MQSEND & 9\\
+WAIT\_MQRECEIVE & 10 \\
+\hline
+\end{tabular}\end{center}
+
+\caption{\label{t:stati}Task states. (Note that a scheduling module can add
+its private task states.)}
+\end{table}
+
+\begin{table}
+\begin{center}\begin{tabular}{|l|c|}
+\hline
+\emph{Identifier} & Class \\
+\hline
+HARD\_TASK\_MODEL & Periodic and sporadic hard tasks \\
+SOFT\_TASK\_MODEL & Periodic and aperiodic soft tasks\\
+NRT\_TASK\_MODEL & Non-real-time tasks \\
+JOB\_TASK\_MODEL & A task instance (job) that can be inserted into another module \\
+DUMMY\_TASK\_MODEL & Model used for the Dummy Task \\
+ELASTIC\_TASK\_MODEL & Elastic task, used with the Elastic Module \\
+\hline
+\end{tabular}\end{center}
+
+\caption{\label{t:task}Basic Task Models included with the default distribution
+(see include/kernel/model.h).}
+\end{table}
+
+\begin{table}
+\begin{center}\begin{tabular}{|l|c|}
+\hline
+\emph{Identifier} & \emph{Value} \\
+\hline
+MAX\_PROC & 66 \\
+MAX\_RUNLEVEL\_FUNC & 40 \\
+JET\_TABLE\_DIM & 20 \\
+MAX\_CANCPOINTS & 20 \\
+MAX\_SIGINTPOINTS & 20 \\
+MAX\_SCHED\_LEVEL & 16 \\
+MAX\_RES\_LEVEL & 8 \\
+MAX\_LEVELNAME & 20 \\
+MAX\_MODULENAME & 20 \\
+MAX\_TASKNAME & 20 \\
+NIL & -1 \\
+RUNLEVEL\_STARTUP & 0 \\
+RUNLEVEL\_INIT & 1 \\
+RUNLEVEL\_RUNNING & 3 \\
+RUNLEVEL\_SHUTDOWN & 2 \\
+RUNLEVEL\_BEFORE\_EXIT & 4 \\
+RUNLEVEL\_AFTER\_EXIT & 5 \\
+NO\_AT\_ABORT & 8 \\
+\hline
+\end{tabular}\end{center}
+
+\caption{\label{t:limits}System constants (see include/kernel/const.h).}
+\end{table}
+
/branches/new_sharkdoc/vol1/introd.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/graph.tex
===================================================================
--- branches/new_sharkdoc/vol2/graph.tex (nonexistent)
+++ branches/new_sharkdoc/vol2/graph.tex (revision 1676)
@@ -0,0 +1,241 @@
+%----------------------------------------------------------------------------
+\chapter{The Frame Buffer Library}
+%----------------------------------------------------------------------------
+
+The S.Ha.R.K. system provides support for all modern SVGA cards through the
+Linux Frame Buffer driver. Using the \texttt{grx} graphic library upon it is
+possible to draw points, lines, rectangles, boxes, circles, and text on 16 bit
+per plane (bpp) SVGA graphic modes.
+
+In order to use graphics, a program must include the
+\texttt{drivers/shark\_fb26.h} header file. Then, it must initialize the Frame
+Buffer using \texttt{FB26\_init()}. At this point the drawing library must be
+connected to the frame buffer with the function \texttt{FB26\_use\_grx()}. Now a
+graphic mode can be opened using \texttt{FB26\_setmode()}, and then the drawing
+functions can be used. The \emph{num number}, needed as a parameter indicate
+which frame buffer is used. At the end, the program can switch back to text mode
+through \texttt{FB26\_close()}.
+
+\vspace{7mm}
+
+\begin{intest}
+FB26\_INIT \index{FB26\_init()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FB26\_init(void);}]
+\item [\textbf{Description:}] It initializes the rame buffer and internal data structures
+to access the hardware. The function returns -1 on error, 0 otherwise. In order
+to use the graphic primitives, a program must call this function.
+\end{description}
+
+\begin{intest}
+FB26\_OPEN\index{fb26\_open()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FB26\_open(int num);}]
+\item [\textbf{Description:}] Open the frame buffer number \texttt{num}. The function
+returns -1 on error, 0 otherwise. The frame buffer must be already initialized
+with \texttt{FB26\_init}.
+\end{description}
+
+\begin{intest}
+FB26\_SETMODE\index{FB26\_setmode()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int grx\_setmode(int num, unsigned chat *mode);}]
+\item [\textbf{Description:}] It opens the graphic mode identified by the \texttt{mode}
+parameter. The mode number can be obtained using \texttt{grx\_getmode()}. The
+parameter \texttt{mode} is a string in the format
+``\texttt{widthxheight-bpp}'' (ex. ``\texttt{640x480-16}''). If the mode is
+supported and can be opened, the function returns 1, otherwise it returns -1.
+\end{description}
+
+\begin{intest}
+FB26\_CLOSE\index{FB26\_close()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FB26\_close(int num);}]
+\item [\textbf{Description:}] It closes the frame buffer \texttt{num} returning to text
+mode.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{The Frame Buffer graphics functions}
+%----------------------------------------------------------------------------
+
+The GRX library allows to use graphics with 16 bpp; the number of bits per
+pixel, the graphic depth, determines the number of colors that can be
+simultaneously displayed on a single screen. In 16 bpp modes, each pixel is
+represented by two bytes. Since 16 is not divisible by 3, a component (the green
+one) is described by 6 bits, whereas the other two are described by 5 bits. The
+\texttt{RGB16()} macros help to code RGB values in a pixel value for all these
+graph functions.
+
+\vspace{7mm}
+
+\begin{intest}
+RGB16\index{rgb16()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{WORD rgb16(WORD r, WORD g, WORD b);}]
+\item [\textbf{Description:}] It returns the color value defined by the 3 parameters
+(\texttt{red}, \texttt{green} and \texttt{blue}) in the format required by
+drawing function.
+\end{description}
+
+\begin{intest}
+GRX\_CLEAR\index{grx\_clear()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void grx\_clear(DWORD color);}]
+\item [\textbf{Description:}] It clears the graphic screen by filling it with the color
+specified in the parameter \texttt{color}.
+\end{description}
+
+\begin{intest}
+GRX\_PLOT\index{grx\_plot()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void grx\_plot(WORD x, WORD y, DWORD col);}]
+\item [\textbf{Description:}] It draws a pixel of color \texttt{c} at coordinates
+(\texttt{x},\texttt{y}) on the screen. For efficiency reasons no checks are
+performed on \texttt{x} and \texttt{y}. Only the \texttt{bpp} less significative
+bits of \texttt{col} are used (where \texttt{bpp} is the number of bits per
+plane in the current graphic mode).
+\end{description}
+
+\begin{intest}
+GRX\_GETPIXEL\index{grx\_getpixel()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{DWORD grx\_getpixel(WORD x, WORD y);}]
+\item [\textbf{Description:}] It returns the color of pixel at coordinates
+(\texttt{x}, \texttt{y}) on the screen. For efficiency reasons no checks are
+performed on \texttt{x} and \texttt{y}. Only the \texttt{bpp} less significative
+bits of the returned value are used (where \texttt{bpp} is the number of bits
+per plane in the current graphic mode).
+\end{description}
+
+\begin{intest}
+GRX\_PUTIMAGE\index{grx\_putimage()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void grx\_putimage(WORD x1, WORD y1, WORD x2, WORD y2, WORD *img);}]
+\item [\textbf{Description:}] It writes a rectangular bitmap from system memory to video
+memory. (\texttt{x1}, \texttt{y1}) is the top left corner, while
+(\texttt{x2},\texttt{y2}) is the right bottom corner. It fills the specified box
+with the data in the buffer pointed by \texttt{*img}. The memory buffer must
+contain the pixels in the same representation used in the video memory, starting
+at the top left corner, from left to right, and then, line by line, from up to
+down, without any gaps and interline spaces.
+\item [See also:] \texttt{grx\_getimage()}.
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+
+\begin{tt}
+\begin{verbatim}
+BYTE videobuff[200][200];
+...
+
+void *videotask(void *arg) {
+ int done = 0;
+ ...
+
+ while (!done) {
+ done = decodeframe(videobuff, 200, 200);
+ grx_put(X, Y, X + 200, Y + 200, videobuff);
+ task_endcycle();
+ }
+}
+\end{verbatim}
+\end{tt}
+
+\begin{intest}
+GRX\_GETIMAGE\index{grx\_getimage()}
+\end{intest}
+\begin{description}
+\item [\textbf{void grx\_getimage(WORD x1, WORD y1, WORD x2, WORD y2, WORD *img);}]
+\item [\textbf{Description:}] It reads a rectangular bitmap from video memory to system
+memory. (\texttt{x1}, \texttt{y1}) is the top left corner, while
+(\texttt{x2},\texttt{y2}) is the right bottom corner. It fills the specified
+buffer pointed by \texttt{*img} with the data contained in the selected video
+box. The memory buffer must be large enough to contain the box (in general, the
+correct buffer dimension is $(y2-y1+1)*(x2-x1+1)*bpp$).
+\item [See]\textbf{also}: \texttt{grx\_putimage()}.
+\end{description}
+
+\begin{intest}
+GRX\_RECT\index{grx\_rect()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int grx\_rect(WORD x1, WORD y1, WORD x2, WORD y2, DWORD col);}]
+\item [\textbf{Description:}] It draws an empty rectangle with top left corner at
+(\texttt{x1},\texttt{y1}) and bottom right corner at (\texttt{x2},\texttt{y2}).
+The rectangle is drawn with color \texttt{col}.
+\end{description}
+
+\begin{intest}
+GRX\_BOX\index{grx\_box()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int grx\_box(WORD x1, WORD y1, WORD x2, WORD y2, DWORD col);}]
+\item [\textbf{Description:}] It draws a filled rectangle with top left corner at
+(\texttt{x1},\texttt{y1}) and bottom right corner at (\texttt{x2},\texttt{y2}).
+The box is drawn with color \texttt{col}.
+\end{description}
+
+\begin{intest}
+GRX\_LINE\index{grx\_line()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void grx\_line(WORD x1, WORD y1, WORD x2, WORD y2, DWORD col);}]
+\item [\textbf{Description:}] It draws a line from (\texttt{x1}, \texttt{y1}) to
+(\texttt{x2},\texttt{y2}) using color \texttt{col}.
+\end{description}
+
+\begin{intest}
+GRX\_TEXT\index{grx\_text()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void grx\_text(char *text, WORD x, WORD y, DWORD fg, DWORD bg);}]
+\item [\textbf{Description:}] It writes a 0 terminated text string in graphic mode at
+position (\texttt{x},\texttt{y}). The string is pointed by \texttt{text},
+\texttt{fg} is the foreground color, and \texttt{bg} is the background color.
+\end{description}
+
+\begin{intest}
+GRX\_CIRCLE\index{grx\_circle()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void grx\_circle(WORD x, WORD y, WORD r, DWORD col);}]
+\item [\textbf{Description:}] It draws a circle of radius \texttt{r} and color
+\texttt{col}, centered at (\texttt{x}, \texttt{y}).
+\end{description}
+
+\begin{intest}
+GRX\_DISC\index{grx\_disc()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void grx\_disc(WORD x, WORD y, WORD r, DWORD col);}]
+\item [\textbf{Description:}] It draws a filled circle of radius \texttt{r} and color
+\texttt{col}, centered at (\texttt{x}, \texttt{y}).
+\end{description}
/branches/new_sharkdoc/vol2/graph.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/console.tex
===================================================================
--- branches/new_sharkdoc/vol2/console.tex (nonexistent)
+++ branches/new_sharkdoc/vol2/console.tex (revision 1676)
@@ -0,0 +1,123 @@
+%----------------------------------------------------------------------------
+\chapter{The Console Library}
+%----------------------------------------------------------------------------
+
+The output on the screen in text mode is supported by a group of functions that
+act on the whole screen and modify, each time, the cursor's position. Since such
+functions are not reentrant, they must be used in mutual exclusion.
+
+In order to use the library for displaying on the screen, the
+``\texttt{cons.h}'' file must be included. This file contains the values for
+the usable colors whose symbolic names are listed below: \texttt{BLACK, BLUE,
+GREEN, CYAN, RED, MAGENTA, BROWN, GRAY, LIGHTGRAY, LIGHTBLUE, LIGHTGREEN,
+LIGHTCYAN, LIGHTRED, LIGHTMAGENTA, YELLOW, WHITE}.
+
+Two global read-only variables \texttt{cons\_columns} and \texttt{cons\_rows}
+contain the number of screen columns and the number of screen rows,
+respectively. They can be used to write applications that are indipendent from
+the screen dimensions.
+
+\vspace{7mm}
+
+\begin{intest}
+CPUTC, CPUTS, CPRINTF \index{cputc()}\index{cputs()}\index{cprintf()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void cputc(char c); }]
+\item [\textbf{void cputs(char {*}s); }]
+\item [\textbf{int cprintf(char {*}fmt,... ); }]
+\item [\textbf{Description:}] \texttt{cputc}, \texttt{cupts} and \texttt{cprintf} are used
+to print on the screen a character, a string, or a formatted string,
+respectively. In the latter case, the standard C I/O formatting conventions are
+used.
+\item [\textbf{Warning:}]since these functions modify the cursor position, they are not
+reentrant, and must be used in a mutually exclusive fashion.
+\end{description}
+
+\begin{intest}
+PUTC\_XY, PUTS\_XY, PRINTF\_XY, GETC\_XY \index{putc\_xy()} \index{puts\_xy()}
+\index{printf\_xy()} \index{getc\_xy()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void putc\_xy(int x,int y,char attr,char c) }]
+\item [\textbf{void puts\_xy(int x,int y,char attr,char {*}s) }]
+\item [\textbf{int printf\_xy(int x,int y,char attr,char {*}fmt,...) }]
+\item [\textbf{char getc\_xy(int x,int y,char {*}attr,char {*}c) }]
+\item [\textbf{Description:}] These functions are similar to the previously defined ones;
+the only difference is that since they're reentrant can be used concurrently by
+multiple tasks (the others cannot be used for this purpose because they modify
+the cursor's state). \texttt{getc\_xy} is used to read the charcater and its
+attribute at a specific position on the screen.
+\end{description}
+
+\begin{intest}
+CLEAR, \_CLEAR, SCROLL, \_SCROLL \index{clear()} \index{\_clear()}
+\index{\_scroll()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void \_clear(char c,char attr,int x1,int y1,int x2,int y2) }]
+\item [\textbf{void clear(void) }]
+\item [\textbf{void \_scroll(char attr,int x1,int y1,int x2,int y2) }]
+\item [\textbf{void scroll(void) }]
+\item [\textbf{Description:}] the \texttt{clear} and \texttt{scroll} functions are used
+for clearing the screen and for scrolling it upwards. They are based on the
+\texttt{\_clear()} and \texttt{\_scroll()} functions used for clearing or
+scrolling a window (defined by \texttt{x1, y1, x2, y2}) by filling the area with
+\texttt{attr} color and, in the case of \texttt{\_clear}, with character
+\texttt{c} as well.
+\end{description}
+
+\begin{intest}
+SET\_ACTIVE\_PAGE, SET\_VISUAL\_PAGE,\\
+GET\_ACTIVE\_PAGE, GET\_VISUAL\_PAGE
+\index{set\_active\_page()} \index{set\_visual\_page()}
+\index{get\_active\_page()} \index{get\_visual\_page()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void set\_active\_page(int page) }]
+\item [\textbf{void set\_visual\_page(int page) }]
+\item [\textbf{int get\_active\_page(void) }]
+\item [\textbf{int get\_visual\_page(void) }]
+\item [\textbf{Description:}] The video cards working in text mode use the CGA hardware
+scheme. In this scheme, every screen occupies 4000 bytes (80 columns x 25 rows;
+each position is associated with two bytes, one for codifying the character and
+another for codifying the color). The video card memory is in general bigger,
+therefore multiple screen pages can be used simultaneously. The currently
+visualized screen is called the \texttt{visual page}, whereas the screen the
+output is directed to is called the \texttt{active page}. The cited functions
+are essentially used for handling, at a given instant, the visual page or the
+active page. SUGGESTION: if the active page or the visual page are modified,
+they should be restored to the original (0) value on exit; the same is true for
+the cursor.
+\end{description}
+
+\begin{intest}
+PLACE, CURSOR, CURSOR\_INFO
+\index{place()} \index{cursor()} \index{cursor\_info()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void place(int x, int y) }]
+\item [\textbf{void cursor(int start\_scanline, int end\_scanline) }]
+\item [\textbf{void cursor\_info(int {*}x, int {*}y) }]
+\item [\textbf{Description:}] These functions are used for handling the cursor. More
+specifically, \texttt{place} sets the cursor position (\texttt{x} belongs to the
+range 0\ldots{}79, \texttt{y} to 0\ldots{}24).
+\end{description}
+
+\begin{intest}
+CURSOR\_BLOB, CURSOR\_STD, CURSOR\_OFF
+\index{cursor\_blob()} \index{cursor\_std()} \index{cursor\_off()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void cursor\_blob(void) }]
+\item [\textbf{void cursor\_std(void) }]
+\item [\textbf{void cursor\_off(void) }]
+\item [\textbf{Description:}] These macros call the \texttt{cursor()} function to set the
+cursor shape to be a big rectangle, the standard underscore, or invisible.
+\end{description}
/branches/new_sharkdoc/vol2/console.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/vol2.tex
===================================================================
--- branches/new_sharkdoc/vol2/vol2.tex (nonexistent)
+++ branches/new_sharkdoc/vol2/vol2.tex (revision 1676)
@@ -0,0 +1,74 @@
+\documentclass[english]{report}
+\usepackage[T1]{fontenc}
+\usepackage[latin1]{inputenc}
+\usepackage{geometry}
+\geometry{verbose,a4paper}
+\usepackage{makeidx}
+\makeindex
+\usepackage{graphicx}
+
+\makeatletter
+
+\newenvironment{intest}{\noindent\large\bf\hspace*{1pt}}
+{\vspace*{-5pt}\\\line(1,0){433}}
+
+\topmargin=-0.2 truein
+\textheight=8.6 truein
+\textwidth=6.1 truein
+\oddsidemargin=1cm
+\headsep=1.3cm
+
+\usepackage{babel}
+\makeatother
+\begin{document}
+
+\thispagestyle{empty}
+
+\begin{center}{\LARGE S.Ha.R.K. User Manual}\end{center}{\LARGE \par}
+\vfill{}
+
+\begin{center}{\large Volume II}\end{center}
+
+\begin{center}{\large Programming Libraries}\end{center}{\large \par}
+\vfill{}
+
+\begin{center}Written by\end{center}
+\begin{center}Giorgio Buttazzo (giorgio at sssup.it)\end{center}
+\begin{center}Paolo Gai (pj at sssup.it)\end{center}
+\begin{center}Luigi Palopoli (luigi at gandalf.sssup.it)\end{center}
+\begin{center}Luca Abeni (luca at gandalf.sssup.it)\end{center}
+\begin{center}Giuseppe Lipari (lipari at gandalf.sssup.it)\end{center}
+\begin{center}Gerardo Lamastra (lamastra at sssup.it)\end{center}
+\begin{center}Antonino Casile (casile at sssup.it)\end{center}
+\begin{center}Massimiliano Giorgi (massy at gandalf.sssup.it)\end{center}
+\begin{center}Tullio Facchinetti (tullio.facchinetti at unipv.it)\end{center}
+\vfill{}
+
+\begin{center}\includegraphics[width=2cm]{../common/sssup.ps}\end{center}
+
+\begin{center}Scuola Superiore di Studi e Perfezionamento S. Anna\end{center}
+\begin{center}RETIS Lab\end{center}
+\begin{center}Via Carducci, 40 - 56100 Pisa\end{center}
+
+\pagebreak
+\tableofcontents{}
+
+\include{intro}
+\include{linuxc26}
+\include{input}
+\include{graph}
+\include{fg}
+\include{cpu}
+\include{netlib}
+\include{rtc}
+\include{soundlib}
+\include{console}
+\include{file}
+\include{snapshot}
+
+\printindex{}
+
+\bibliographystyle{alpha}
+\bibliography{../common/biblio}
+
+\end{document}
/branches/new_sharkdoc/vol2/vol2.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/images/driver1.dia
===================================================================
--- branches/new_sharkdoc/vol2/images/driver1.dia (nonexistent)
+++ branches/new_sharkdoc/vol2/images/driver1.dia (revision 1676)
@@ -0,0 +1,11 @@
+‹í[Ûrâ8}ÏW¸œW"$ù>2Åd²5©ÉÎT‘d/O”À
+xÇؔ-BxÙo_ÉfBð…‹²@U ì4ݖԧOwK|üô4ò•GÅ^´T ªÐ º^0h©÷w¿Ù꧋“®G>ð¿ADF
+ÿF‹«–:dlü¡ÙœN§ÀŸÅ„…𽠈ió_âû¤É…šêʼn¢¼TàFĽù]ÂXäõ&Œ*іÚ#ýŸƒ(œ®šJÍåú¡FÊ#ñ[êéCòR›s5Í%=+tÉ€ö"J~–«†üå8UTi”U;‡±ÇEØlœ)Ñ#Þ_ÈÌ¥b. .NÛúiúHó ]EZj„H4ð‚¼>7~:Øã_󰽉ž|¾|‘|^܇‹ˆÇòfzaèS¤–X4¡ÕíÄ}âs—Y5T]ûƒÇX¸æùˆo2€ôö3z¶Eâ òÜÕ@\’(Ñ2õ\6ì>Iš®TûL’öG/öz>-zz/`;S?ۍúìê$ÑxñõšÞj+ +÷®M +jlîÏ¥ñ7[–)Ñ4œ‹5×ÍzVnӉIoeÈ71ᓍæê?/hW™/ð<⼘…°÷í³ùðn \¹Ê™ò9|RYÏ!<·¥þ€ËӓWÆ#_n~Æá³Ù +#;Ü|°(SÝëe5GüÙI0ðiªÝŽÑÐùÛ¹46«fŽútÔí‡Q§÷]Œ&QŸDŒüˆžY×Ð=¤Þ`ÈʕkÕt{Ÿî2 H\B³š‰xN»ãzú,†zsáå¸ý}b~êú=r–DÇG0°Ñ0€Î?αίø%‡ƒSÑA™˜‡5Q=#S¶žIZ»$—É€oÁW:àP¾Q8¿$^A:eL°"Ãâ¾ò@Fž?ãÏG‚XUb6ё¯wúÕ¯Ô¤Ì듗A|û'ÈÁ°çõL,ûÝzß«b# øÒ2 Âz†x>;F´xÙh0¤"«’‘">ÝM (æG\ŸÙüh ~ÄXð#ÂÒ Ò‘GHß[‚½Ž—XÙ{‚Ôj$÷FÌìÐáe}âþ¦fq@€Âš…÷€&o®¿ßÿ¥``ž\ý~Ó¾»þñ]¹iÿ}Õyg|‰€!1sÎxdM‰¬©×gM¤É¦M'žëJdJçͪ:ðÊR´v¨q@Äiì ²”ÊšH–¨-y‰™—à¤iìGiùµÝùòg»su,)w^RÙñ•ØѬ!°&µ¨Äø¹ªœ³£ìª²ú€6aGk«JbTUiÕv}ò KÑo5@Hԕ60DÉQ€ÐPä—ëÎÕåÝIûòòêööݕ’šl¦,ôÀ#_î$jÜx-ˆví”ZO +ÉM« +DzÅ¥niç<¡Ö!Æ<ˆ@ £Š†ûatià&CÙr€…MŠ,Ë}¤?Κ/:G°¿n—DQ8Í*^¸¤VSsקÁ`UjQ×Ěä‚ +›Úb­¹GqǏsDñë?ʐCEÄV¤*,L¶'”Å V"§t7€tv@ãºÆÑÁ=Z2÷Q¹!èXzrp@‡œÌMà@l
+XÚْaY6ÌbV9¢óÀÐiþ?èDp{7X.Wê–Ó@8º.¨ۆ&RÚ²1™[!—Ú6Nö‘œÊÁéˆÉ7†IX̘ækaí¢ò•‹JniÐLaik Wjš•Áz +®\‡L!¢‘y È4%#³¸‹jŸð9C<›”™Ãž!фu€iœ›ÀðÄR»±u´Q?X†Ä–,ªŠƒMw,Mj>C: [ÿ¬ØA„•—u³œ Øüã\š‚÷¡!Û¹þãêAÒ÷,ó^w}Xøfû°¨ö¹“¯–X3]f¤0éØPv ÃóX@Óp»D–ä<¶hˆ…ç*çkÇ öf°(S\ê9ؼ•«mþ¦×ÉïÅ.N–~PvqòK iD>
\ No newline at end of file
/branches/new_sharkdoc/vol2/images/driver1.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/images/driver2.dia
===================================================================
--- branches/new_sharkdoc/vol2/images/driver2.dia (nonexistent)
+++ branches/new_sharkdoc/vol2/images/driver2.dia (revision 1676)
@@ -0,0 +1,27 @@
+‹í][SÛH~ϯP9/»Už¦ï—aÈa]*LÂr™Ý}J ¬íØk /ûÛ÷tˁ KÛÝÚ¨JT%”LÓ§O÷Ñ÷}§oüòë—Ù4ºMæ‹4ÏöáA”d—ù8Í&{ƒó³w?éÁ¯o^ý2NãŸáßdÏ"ølaŸöWEqýóÎÎÝÝšÞ/â"Ÿ£izƒÉÎãé4ށB;ƒ7¯¢èÛ
+ÆqÛϖŸÆE1O/nŠ$ÊâY²7¸ˆ/ÿ˜Ìó›l<(K-Ë]æÓ|ÝÆÓ½ÁëÏîk°³¬fçI=ÏÔ}O’‹yÿÑ\5†/c6©ú:™W«]ç‹Š÷×+Eê±ÿSfYj…²É›×ûüuÙ¤åuÕ5´ÑH1‹ç“4[µ}3-;‚"M)ýÚ뛸obÞÄ<¼‰tñé:Ÿó8-VÍ\äù4‰³ÒR1¿I6·³¸Œ§2ϹB6¯ýsZùwÚÿ9ž.^â@ùñÃÛ³î›8™§ãç_Ä'%j¹KÇÅÕ§/º«¬ý>Pí·é"½˜&u­O³Â[õ÷~ª¯ŽŽCãÇ_ß2ÊÚá~¬‘ˆõá~r“Ž“ÅwÂìi™†š®–Åv¾×ëÕr/í˜ò£
+ù:Óø>™/«ûH»Ñr€—ˆóM/äÿN.‹¥{§Eœãù8ú):K¾ƒG""ï +>â§ýSõjè[é ëü!Š8’CŠ”¨:½
+Mõ_\T«Ÿƒq6™&&2b—(Ć ÑÍl¶¾ؕ2M8í˜ýI¹Š8:üpþÏ*£?¥Ù͗ˆ"f7Ó¸€ÞŽì þ¹A&<ó.6{žu±ŸGŸãY:½‡6ÇÙb-Š{40úå¯þ-™Þ&EzÛë·à*I'WµmhËõM<Â—Eâ&vž‚Ñ3
+ãí ÕO²YR?tIv3+m½ÔJ-Ô4ÁåÎ#Rld[èPH 9¢!¡Ãš`ˆ‹]ƒ„5¦~|è8>8¤²Ç¿Ø°j=6xÁ ·¤è¶Ø ›Sý‹°A _¬ßw%"”
+3$1ŽÉf–/ó,û”dcçÊz֖QTØQ³Ys T.¯«­¨ËÆó \Ù÷‹Àá`­ì*D¬±`Õ«:ä"[xþ#Œ?ßvü5¶8 9üq@;LsÈ5À¨ÄðŠè| +ê\¬-5$ 2¡CƒhÛƒAF +R:d08# +9'Cš FtÓðkS<~ýããÉû^>ú•uA× È¤!=¨¹¡@B¦ +…¥µÃµPÄ晒sϒÊM1jÚ¨q².~¡BڂL Ù]-¡¶ .mOHd6F!ƀ%­¥162ŒÆj¨¬ž*xd4øYVˆÊNë
+íAWÂë
+Íè
+‚´ƒBw@V҃~N*€¨X‰¸^T„ ã%ùjŸ|p` +±KbÃIrwoíz×ñÁa”.¢,/¢yòŸ›tžŒ£»´¸Š~îGáè6'y4ËÇI¿"O©Äg)!)Ùz`jÀ<(¨€f§·Àã\î³ X A'
+,x`5Zëc}1פî&(„øˆaÊp8"8v£¢ +%Ì
+RH& +t?¼ÕLµ5^Ö$aSWòÿ’ž<_–AÿÁX/VèôëO¢+ˆŽ%·y Ñ㏟ÀØW¤ªÔêie~ëå·2;ш†¥eÄí<+GÂZT]:oÏÎ~ï"ßê¥6èzù”®˜¯ 5oqø 5
+’,1…í–Î5&C7%yKj+~Ö©pfW’¡¤QÐÁS#܃–‚÷Z†·Ø­Ñé%‘ÀíFÒ|p|þîdô÷žL¼“Imèõl”M„­e­êg*0›H¢œ%(m—g(cΰּ…íµn֑‰KlIJI‡ÉDz™|% I|öØC3·÷ƒ·¨ ‹4LJS1ê™$À¤j5îz" J$ÞÖùí+œHÑÜZ¢ŠpK$ŠQê,kÍZJKVü¬]緛ElÉn0ISphOŠ‰@BcxO±´[ÊÁ!jW!,WöY2BÛÙa¼âfÝ&c\ê(*©ì°Ê0ÛJâ® {.ÉZáÈX•]Â*éÄVÇçg}ºêÿ€RMØõ"#è%ìAd(wF@Ú Ì+2ÀãƞN ˜’!¥H`Lˌz?k‹
+Û*Þá+”xSŸvm+¼ú4Γv“)X:ÃBà¶6™®¸Y;áÕ]iA©§ÙpÕÎl¸,gé;¾¢»1þ~ô¯·½¶4®ú©ðö¶šRæ -Ì擏렅[u·žÒÙ]@‹ß>žŸŽz¸•Àëá"¨äôqHÚ¾Å&ði-©5£i9ÓI™Öά -¬™Ul^,ƒ*ª;œxXHµyÞ8{yVjˆµÃŒ.O¸A2¢#ó«ÖnÓ®…»^>¥~–O¡Z8¼Üárt=éFîñ×ýßFÇOú¹Í0 ¨ÕÈëõDPñ±€ª„}y + +|~ž:3Z¹KÚÊ£D Sš«îÕ+Šíºá‡`?Ç£)mã|4t¶; Í•n‚» Ëb§Ç£ý÷£“ž<‚œ’®^OAÑÂl)0‡W—Yô^àÒ
+Öå":<p ?>ZüåðdtpíŒNO{Äð}pMðõˆôŠGìaK–Ävî€Û‹ÖÂ_ûI­%¢…»ö“`ª† Ûsˆ"üž¬z?›nÅöR@Þ]éÉ|\
+ üŽ,kåaGéȎ¬ÓÑÉáþQÏ"ÞoŒ^ºžE‚²ˆ‡[£Ë¥´ã¨©…Åqk†öT­J«Fëà Òàcí¶^7ù-:>ù͘Q›_⺇H;.ö: +;}±ÅfŸVÏíŸìz Â"•¸ëY$(‹p/¹ˆt//Î"0LÉ"ܱˆ£ÝFRçc]Qc´‹bÜm~XDo>#½‹({Ûô×LÄØAê Ô#MhÏ!!8¤u=‡åéC´»<8‡h':8DÛm/­qHÕÇfÑ6CêðÙS¦¼†AF<0À Åü!2¶ˆh[‘Qu²92 ¤f^bgڋº€ñ!
+óàò f–úŒJº©Ñ¶c½À 0V¯W/ƒ‹òÙýÞ7¯žü!ß7¯þæàÄ;¼
\ No newline at end of file
/branches/new_sharkdoc/vol2/images/driver2.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/images/driver3.dia
===================================================================
--- branches/new_sharkdoc/vol2/images/driver3.dia (nonexistent)
+++ branches/new_sharkdoc/vol2/images/driver3.dia (revision 1676)
@@ -0,0 +1,10 @@
+‹í\]sÚ8}çWhܗÝ",5M:iCÛLi2¤»ûĬoÍØ" /ûÛW2Nˆ +FLiÍLB0â\I¾:÷\é†wïÇ>¸§Qì…Á™‚ ª CÇ Ü3å¶÷éÄRޟ×Þ9yË܈ŒÿD‹Wgʈ±ÉÛFãááú³˜°0‚¾7…1müG|Ÿ4x£†r^à%€C×Ò«„±ÈLÓ3e@†?Ü(œŽ2o•¶†~{âŸ)oÒHaœW°'Ä¥ƒˆ’ÅÐ*Øö.ÐåaǓ0öx6›,5)À¿_´I[żQàž¿¹h¾™w)½°ÀZÕÑB#lL"× –íð¹ñ灡…1~š‡íM ä›ð囈ä›ðâþ$ŒXD<¶lf†>%ÁÜ‹¦tw;ñøÜe^
+ÚýÎc,\Óÿ;âǛ `~ùyõl»ÝÈs^_ˆ™(žÃFýGIÓ5GŸIB¿÷boàÓU½÷¶7øÙ~àów'aãÅÇKzíî‹êTߞîÝ©çÐx›eÛ Òfu³žo·éÄÌ/å‚obÂ'3¥ða¤78eœ³þ¥C–¯ËHàÈ' G™²\DxΙr£fç'?"ŽÆ©oi‚&á³áz3?Þe¶(‚ òÈï< \Ÿ>¡k™š©Ÿ"ÄIÜàÖ ®b}7“LÌÁ×ε)bê$¶gÚåd@÷Ÿn¿u} n: õ÷U|¼h·[—Òà•õWDæaÀV™×Á{þŒ÷’±b6ŽÂïøü£_¨O™7$/ýyûŒ¨çŽVö¡€ ·7‘õ¼µÞ·‹‰,÷¼"8Uµœ!ÙÝ`LWß5LÇs[›ZYÉ,EìØXÃLÑöº‚)PY¦0êºD¦Ð¡­ÙšÉù!y>EDM]¯[°©ªÈÚÍò0 ‚> +œdmùmdÕwìwŒá$oxUß”¨O¢(|È/üP+‰Ü÷ià²ÑòM{¢eM$
+í5 ë"Ӗ £ „â² Ù»zÇF+ƒÃ›iŦ¢_ÇD;·×íÖ÷V»ßýrÛ»¼ù뺊ŸûŸY׫¨LžÐöÀ¶\ž° †-ÁÄ&Âujö1ð#ñ>2ïž0úG<š2'|úÉå‰çüù›Ñ†
+­‡]Çaˆ£Y>GÇRstU,t®,0ԍŸŸ/¾Ý¶{W½‹î׫ëÏàÛÍeëwÓËÏÌqŇÉÌõÒ¢Y×d
+ +ڦΩÁûxMNz]SáÎÈÆYyv\«ßW¢¼Üç÷w}V«ê%ÐÒ)NûñA2fcJËUÂIHÃ:Ä֑„´.eíVÌd©Ý*šHíšeÉA«#™GR>9“²ž¤P³ÚN«¶Ó–]¯â ™ª×*-",©Ûiº Õ¬[ÐÖ !|-¨ì¡Ùº&[úZÙý™å+¤U'R¿è‰”} !Ô¶>Õ Š,ž"êüùç¡ÕNr3W[#uÌ Ëe†fruŠTˆ0âá҄æQœA-Šâ}¤Ã)ã3jáx:Žâ8ªv.;Wß[.xáà¤V±ŠVÑ+V9PeØJÐ)¹6Ì*ÃXIm˜©ÙuŒ!ųƒ[)Õ1ª´ø/ªÅÞCžŠ¥îv›Ð65S¬Q%&ŠÄtnñØö´>´>ÝtZ}Ql]mkíyû;ëU4•Jåëĸj–ZPŠ8aX¦æ\ªóp*ìI¥X¥´÷NYo«ÈA*94÷¡&¤{ˆX1çl@KT‘bíHÈAàú|e.`#
+âYÌèø9¯¨C†®Ð*ê8uèû [2uXi"¨ÃàÔa[rñ©×êTYˆ$¶¨jε§WºFóÕ+õ_Ã4„´°õS.8šulî\¹ñV^nL«˜Õ^Þ¯º—Wº6 +kulÈ\_OÕ7â‡ÒãPß.>~½Ði]´û¿aëwÎýªº[Ì_'_År^Ë|WËyíÕZŸM
\ No newline at end of file
/branches/new_sharkdoc/vol2/images/driver3.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/cpu.tex
===================================================================
--- branches/new_sharkdoc/vol2/cpu.tex (nonexistent)
+++ branches/new_sharkdoc/vol2/cpu.tex (revision 1676)
@@ -0,0 +1,158 @@
+%----------------------------------------------------------------------------
+\chapter{The CPU frequency scaling library}
+%----------------------------------------------------------------------------
+
+This driver allow the application to change the CPU speed in order to reduce
+power consumption. After the driver initialization is possible to know the list
+of supported frequencies, the minimin and maximun allowed frequncy. Is possible
+to get and set the current frequecy and obtaind the deoretical value of the
+transition duration.
+
+%----------------------------------------------------------------------------
+\section{CPU Information utility}
+%----------------------------------------------------------------------------
+
+These functions allow the application to know informations about the CPU like
+manufacturer, model, capabilities, etc.
+
+\vspace{7mm}
+
+\begin{intest}
+CPU26\_INIT\index{CPU26\_init()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int CPU26\_init(void);}]
+\item [\textbf{Description:}] Initialize the driver and all internal structures. The
+function returns 0 if the procedure was succesfully, -1 otherwise.
+\end{description}
+
+\begin{intest}
+CPU26\_CLOSE\index{CPU26\_close()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int CPU26\_close(void);}]
+\item [\textbf{Description:}] It close the CPU driver.
+\item [\textbf{Return value:}] 0 if the operation is performed successfully; -1
+if the keyboard in not installed.
+\end{description}
+
+\begin{intest}
+CPU26\_INSTALLED\index{CPU26\_instaled()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int CPU26\_installed(void);}]
+\item [\textbf{Description:}] Return if the event debugger is actually installed.
+\item [\textbf{Return value:}] 0 if the module is installed; 1 otherwise.
+\end{description}
+
+\begin{intest}
+CPU26\_SHOWINFO\index{CPU26\_showinfo()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void CPU26\_installed(void);}]
+\item [\textbf{Description:}] Print the CPU informations retrived by the driver.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{CPU scaling functions}
+%----------------------------------------------------------------------------
+
+These functions allow to get/set parameter about the CPU frequency and its
+behavior. The low level must be initialized with the \texttt{CPU26\_init()}
+function before using scaling funtionalities.
+
+\vspace{7mm}
+
+\begin{intest}
+CPU26\_DVS\_INIT\index{CPU26\_DVS\_init()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int CPU26\_DVS\_init(void);}]
+\item [\textbf{Description:}] Initialize the driver and all internal structures. The
+function returns the CPU identifyer if that present DVS capabilities, -1
+otherwise.
+\end{description}
+
+\begin{intest}
+CPU26\_DVS\_CLOSE\index{CPU26\_DVS\_close()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int CPU26\_DVS\_close(void);}]
+\item [\textbf{Description:}] It close the CPU driver.
+\item [\textbf{Return value:}] 0 if the operation is performed successfully; -1
+if the driver in not installed.
+\end{description}
+
+\begin{intest}
+CPU26\_DVS\_INSTALLED\index{CPU26\_DVS\_instaled()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int CPU26\_DVS\_installed(void);}]
+\item [\textbf{Description:}] Return if the DVS driver is actually installed.
+\item [\textbf{Return value:}] The function returns the CPU identifyer if that
+present DVS capabilities, -1 otherwise.
+\end{description}
+
+\begin{intest}
+CPU26\_GET\_LATENCY\index{CPU26\_get\_latency()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int CPU26\_get\textbackslash{}\_latency(void);}]
+\item [\textbf{Description:}] Return the value of the latency time needed to change
+between two frequencies.
+\end{description}
+
+\begin{intest}
+CPU26\_GET\_MIN\_FREQUENCY,\index{CPU26\_get\_min\_frequency()}
+CPU26\_GET\_MAX\_FREQUENCY\index{CPU26\_get\_max\_frequency()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int CPU26\_get\_min\_frequency(void);}]
+\item [\textbf{int CPU26\_get\_max\_frequency(void);}]
+\item [\textbf{Description:}] Are used to obtain minumum and maximum allowed frequencies.
+\end{description}
+
+\begin{intest}
+CPU26\_GET\_CUR\_FREQUENCY\index{CPU26\_get\_cur\_frequency()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int CPU26\_get\_cur\_frequency(void);}]
+\item [\textbf{Description:}] Return the value of the actual frequency of the processor.
+\end{description}
+
+\begin{intest}
+CPU26\_SET\_FREQUENCY\index{CPU26\_set\_frequency()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int CPU26\_set\_frequency(int target, unsigned int relation);}]
+\item [\textbf{Description:}] Return
+\end{description}
+
+\begin{intest}
+CPU26\_GET\_FREQUENCIES\index{CPU26\_get\_frequencies()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int CPU26\_set\_frequency(int {*}freqs);}]
+\item [\textbf{Description:}] Return
+\end{description}
+
+\begin{intest}
+CPU26\_SHOW\_FREQUENCIES\index{CPU26\_show\_frequencies()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int CPU26\_show\_frequency(char {*}buff);}]
+\item [\textbf{Description:}] Return
+\end{description}
/branches/new_sharkdoc/vol2/cpu.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/rtc.tex
===================================================================
--- branches/new_sharkdoc/vol2/rtc.tex (nonexistent)
+++ branches/new_sharkdoc/vol2/rtc.tex (revision 1676)
@@ -0,0 +1,50 @@
+%----------------------------------------------------------------------------
+\chapter{The CMOS real-time clock}
+%----------------------------------------------------------------------------
+
+In all PCs there is a real-time clock (with a resolution of 1 second) that can
+be read or written. This clock usually has a drift of about some seconds in 24
+hours. The following functions (that can be found into \texttt{rtc.h}) can be
+used to set/get values; all values are passed using a \texttt{struct rtc\_time}
+that contains variables for seconds, minutes, hours, days, months and years.
+
+\vspace{7mm}
+
+\begin{intest}
+GET\_RTC\_TIME\index{get\_rtc\_time()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int get\_rtc\_time(struct rtc\_time {*}time);}]
+\item [\textbf{Description:}] The actual time is read from the CMOS real-time clock and
+written into the structure pointed by \texttt{time}. The function returns zero
+on success, other values on error.
+\end{description}
+
+\begin{intest}
+SET\_RTC\_TIME\index{set\_rtc\_time()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int set\_rtc\_time(struct rtc\_time {*}time);}]
+\item [\textbf{Description:}] The values contained in the structure pointed by
+\texttt{time} are converted in seconds and written into the CMOS real-time
+clock; the function returns zero on success, other values on error.
+\end{description}
+
+\begin{intest}
+RTC\_TIME\index{RTC\_TIME, structure}
+\end{intest}
+
+\begin{description}
+\item [\textbf{Description:}] it is a data structure containing the following fields:\\
+\textbf{tm\_sec} : seconds, from 0 to 59;\\
+\textbf{tm\_min}: minutes, from 0 to 59;\\
+\textbf{tm\_hour}: hours, from 0 to 23;\\
+\textbf{tm\_mday} : day, from 1 to 31;\\
+\textbf{tm\_mon} : month, from 1 to 12;\\
+\textbf{tm\_year} : year, is an integer number (no Y2K problem);\\
+\textbf{tm\_wday} : day of the week, from 1 to 7;\\
+\textbf{tm\_yday} : day of the year, from 1 to 365;\\
+\textbf{tm\_isdst} : 0 if legal hour, 1 if solar hour (not used yet);\\
+\end{description}
/branches/new_sharkdoc/vol2/rtc.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/linuxc26.tex
===================================================================
--- branches/new_sharkdoc/vol2/linuxc26.tex (nonexistent)
+++ branches/new_sharkdoc/vol2/linuxc26.tex (revision 1676)
@@ -0,0 +1,58 @@
+%----------------------------------------------------------------------------
+\chapter{The Linux Compatibility Layer}
+%----------------------------------------------------------------------------
+
+It is the glue code used for the interaction between the kernel and the linux
+code. It is the suggested option for using drivers ported from the Linux 2.6
+kernel tree.
+
+\vspace{7mm}
+
+\begin{intest}
+LINUXC26\_REGISTER\_MODULE\index{linuxc26\_register\_module(int use\_intdrive)}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void LINUXC26\_register\_module(int use\_intdrive);}]
+\item [\texttt{Description:}] It initializes the compatibility layer interface
+and the library's internal data structures.
+\item [\texttt{Parameters:}] TRUE indicates to use the IntDrive for managing
+interrupts; FALSE makes the glue layer to use the old interrupt management
+system.
+\item [\texttt{Return value:}] 0 if the module is installed; 1 otherwise.
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{verbatim}
+int device_drivers_init() {
+ int res;
+ KEYB_PARMS kparms = BASE_KEYB;
+
+ LINUXC26_register_module(TRUE);
+ PCI26_init();
+ INPUT26_init();
+
+ keyb_def_ctrlC(kparms, NULL);
+ KEYB26_init(&kparms);
+
+ FB26_init();
+ res = FB26_open(FRAME_BUFFER_DEVICE);
+ if (res) {
+ cprintf("Error: Cannot open graphical mode\n");
+ KEYB26_close();
+ INPUT26_close();
+ exit(1);
+ }
+ FB26_use_grx(FRAME_BUFFER_DEVICE);
+ FB26_setmode(FRAME_BUFFER_DEVICE,"640x480-16");
+
+ return 0;
+}
+\end{verbatim}
+
+
+
+
/branches/new_sharkdoc/vol2/linuxc26.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/intro.tex
===================================================================
--- branches/new_sharkdoc/vol2/intro.tex (nonexistent)
+++ branches/new_sharkdoc/vol2/intro.tex (revision 1676)
@@ -0,0 +1,143 @@
+%----------------------------------------------------------------------------
+\chapter{Introduction}
+%----------------------------------------------------------------------------
+
+Device drivers are a critical part of Real-Time Systems. Trying to fit an IRQ
+and a timer handler, coming from a device, inside a task context, it is a
+priority for OS like S.Ha.R.K. If we design these drivers considering possible
+preemptions, exectution times and other Real-Time contraints, a schedulability
+test can guarantie our system. Buf if we must reuse a source code from
+third-party drivers makers, without having no knowledge about the driver timing
+behaviour, with possible non-preemptable critical section, it is very difficult
+to impose contraints for a schedulability analisys.
+
+The S.Ha.R.K. drivers are mainly ported from Linux 2.6. We projected and tested
+a Linux 2.6 Emulation Layer. This Layer gives an indipendent environement, where
+it is possible to compile the original drivers without conflicts with S.Ha.R.K.
+and OSlib. An interface glue-code allows to access the drivers API.
+
+\vspace{10mm}
+
+\includegraphics[scale=0.3]{images/driver1.eps}
+
+\vspace{10mm}
+
+The Emulation Layer needs a specific kernel module to run. This module has two
+important objectives:
+
+\begin{itemize}
+\item To create an high priority execution context for the drivers IRQ and timer
+handlers.
+\item To maintain the drivers behaviour inside specific Real-Time constraints,
+avoiding that a possible malfuncition or resource abuse cause a system failure.
+\end{itemize}
+
+Both of these points are guaranteed through the INTDRIVE module. A description of
+the IntDrive technology is also available in \cite{Fac05}.
+
+As described inside the module documentation, IntDrive is an high priority
+module specifically designed to handle the drivers requests. Usign the
+hierarchial capabilities of S.Ha.R.K., the IntDrive module is indepented from
+the main system scheduler, so EDF, RM and all the other modules can be used to
+schedule the application tasks.
+
+To load the Emulation Layer, IntDrive must be present inside the system.
+
+\begin{verbatim}
+#define INTDRIVE_Q 1000
+#define INTDRIVE_U 0.1*MAX_BANDWIDTH
+#define INTDRIVE_FLAG 0
+
+TIME __kernel_register_levels__(void *arg) {
+ LEVEL EDF_level;
+
+ INTDRIVE_register_level(INTDRIVE_Q, INTDRIVE_Q, INTDRIVE_U, INTDRIVE_FLAG);
+ EDF_level = EDF_register_level(EDF_ENABLE_ALL);
+}
+\end{verbatim}
+
+After the IntDrive registration, the initialization procedure can begin.
+
+\section{Driver Initialization}
+
+The initialization of a drivers should be done inside the \texttt{initfile,}
+before entering inside the real-time application. During initialization the
+devices can lock the system for an unpredictable amount of time so any used
+device should be ready before the real-time tasks are scheduled.
+
+S.Ha.R.K. standard \texttt{initfile} suggests a possible implementation:
+
+\begin{verbatim}
+TASK __init__(void *arg) {
+ struct multiboot_info *mb = (struct multiboot_info *)arg;
+ set_shutdown_task();
+ device_drivers_init();
+ sys_atrunlevel(call_shutdown_task, NULL, RUNLEVEL_SHUTDOWN);
+ __call_main__(mb);
+
+ return NULL;
+}
+
+int device_drivers_init() {
+ KEYB_PARMS kparms = BASE_KEYB;
+
+ LINUXC26_register_module(TRUE);
+ PCI26_init();
+ INPUT26_init();
+ KEYB26_init(&kparms);
+
+ return 0;
+}
+\end{verbatim}
+
+The \textbf{device\_drivers\_init()} calls all the initialization functions.
+LINUXC26 is the Linux Emulation Layer and it must be loaded as first. The
+initialization order follows the driver dependence tree of Figure
+\ref{fg:deptree}. If this order is not respected, the initialization procedure
+fails.
+
+\vspace{10mm}
+
+\begin{figure} \includegraphics[scale=0.3]{images/driver2.eps}
+\caption{Drivers dependeces tree}
+\label{fg:deptree}
+\end{figure}
+
+\vspace{10mm}
+
+%----------------------------------------------------------------------------
+\section{Driver Shutdown}
+%----------------------------------------------------------------------------
+
+Another critical point is the shutdown sequence. When \texttt{} a \texttt{exit()}
+is called the system should close the device drivers as soon as possible.
+Unfortunately the driver shutdown must be executed when the kernel is still in
+multitasking mode.
+
+\begin{verbatim}
+int device_drivers_close() {
+ KEYB26_close();
+ INPUT26_close();
+
+ return 0;
+}
+\end{verbatim}
+
+The RUNLEVELS of S.Ha.R.K. gives the possibility to implement a safe and
+trasparent procedure to shutdown the system without compromise the drivers
+stability. As the initiliazation, the shutdown sequence must follow the
+dependence order.
+
+\begin{figure}
+\includegraphics[scale=0.5]{images/driver3.eps}
+\caption{Shutdown sequence}
+
+\label{fg:shutdown}
+\end{figure}
+
+The flow chart of Figure \ref{fg:shutdown} shows the steps to reach a safe exit.
+Anyway if the system is overloaded during the exit procedure, the shutdown task
+cannot be scheduled. A possible solution is to give high priority to the
+shutdown task, or to design an application that doesn't reach the CPU
+saturation. If the shutdown task doesn't execute a timeout (default 3 seconds)
+force the system exit.
/branches/new_sharkdoc/vol2/intro.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/fg.tex
===================================================================
--- branches/new_sharkdoc/vol2/fg.tex (nonexistent)
+++ branches/new_sharkdoc/vol2/fg.tex (revision 1676)
@@ -0,0 +1,193 @@
+%----------------------------------------------------------------------------
+\chapter{The Frame Grabber Library}
+%----------------------------------------------------------------------------
+
+The library is divided in 2 layers: the low level and the high level. The first
+one is in charge of the acquisition board hardware control and supplies a
+generic interface for the higher level. The second layer supplies some API
+function for a comunication between the application and a generir video device
+(framegrammer, webcam, etc.).
+
+%----------------------------------------------------------------------------
+\section{BTTV low lever driver}
+%----------------------------------------------------------------------------
+
+At the actual stage of developement is the only low lever driver ported from
+Linux to S.Ha.R.K. Support acquisition boards based on BookTree BT8x8 chips.
+Presents only 2 functions for opening and closing cards.
+
+\vspace{7mm}
+
+\begin{intest}
+BTTV26\_INIT\index{BTTV26\_init()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int BTTV26\_init(void);}]
+\item [\textbf{Description:}] It initializes the acquisition board interface and the
+library's internal data
+structures.
+\end{description}
+
+\begin{intest}
+BTTV26\_CLOSE\index{BTTV26\_close()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int BTTV26\_close(void);}]
+\item [\textbf{Description:}] It close the acquisition board interface.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{VideoDevice high lever interface}
+%----------------------------------------------------------------------------
+
+This library supplies an abstract layer created to obtain a common interface
+between different low level driver. The interaction with an application is quite
+simple and implies only 2 functions: the first one open the comunication between
+the application and the hardware through the low level driver, the second one
+send commands to the device.
+
+\vspace{7mm}
+
+\begin{intest}
+VIDEODEV26\_OPEN\index{VIDEODEV26\_open()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int VIDEODEV26\_open(int num);}]
+\item [\textbf{Description:}] It initializes the acquisition board interface and the
+library's internal data structures. The parametetr \texttt{num} define the
+device that must be opened. \item [Return]value: 0 if the module is installed; 1
+otherwise.
+\end{description}
+
+\begin{intest}
+VIDEODEV26\_IOCTL\index{VIDEODEV26\_ioctl()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int VIDEODEV26\_ioctl(int num, unsigned int cmd,
+unsigned long arg);}]
+\item [\textbf{Description:}] It send the command \texttt{cmd}, with argument
+\texttt{arg}, to the device number \texttt{num}. \item [Return]value: It depends
+from the command executed.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Video Devices Commands}
+%----------------------------------------------------------------------------
+
+This is a list of most commond videodev commands. Most of them are supported by
+the BTTV low lever driver. There is only a major change implemented during the
+porting phase: the VIDIOCSYNC function requires an aperiodic task PID as input.
+When the new frame is ready, the task is activated.
+
+\vspace{7mm}
+
+\begin{description}
+\item [The]full command list is:
+\end{description}
+
+VIDIOCSYNC - Synchronize with memory mapped capture.
+
+VIDIOCGCAP - Get video/radio device capabilities.
+
+VIDIOCGCHAN - Get source properties.
+
+VIDIOCSCHAN - Select source and set properties.
+
+VIDIOCGTUNER - Get tuner properties.
+
+VIDIOCSTUNER - Select tuner and set properties.
+
+VIDIOCGPICT - Get video image (picture) properties.
+
+VIDIOCSPICT - Set video image (picture) properties.
+
+VIDIOCCAPTURE - Enable or disable video capturing.
+
+VIDIOCGWIN - Get video output window properties.
+
+VIDIOCSWIN - Set video output properties.
+
+VIDIOCGFBUF - Get direct video output frame buffer properties.
+
+VIDIOCSFBUF - Set direct video output frame buffer properties.
+
+VIDIOCGFREQ - Get tuner frequency property.
+
+VIDIOCSFREQ - Set tuner frequency property (i.e., tune to new frequency).
+
+VIDIOCGAUDIO - Get audio properties.
+
+VIDIOCSAUDIO - Set audio properties.
+
+VIDIOCMCAPTURE - Initiate memory mapped capture.
+
+VIDIOCGMBUF - Get memory mapped buffer properties.
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{tt}
+\begin{verbatim}
+/* Init videodev driver */
+
+VIDEODEV26_open(FRAME_GRABBER_NUMBER);
+
+/* Select the input channel */
+
+res = VIDEODEV26_ioctl(FRAME_GRABBER_NUMBER,VIDIOCGCHAN,(unsigned long)&chan);
+
+chan.channel = channel;
+chan.type = VIDEO_VC_TUNER;
+chan.norm = VIDEO_TYPE_CAMERA;
+res = VIDEODEV26_ioctl(FRAME_GRABBER_NUMBER,VIDIOCSCHAN,(unsigned long)&chan);
+
+/* Enable the tuner */
+
+tuner.tuner = 0;
+tuner.mode = VIDEO_MODE_PAL;
+res = VIDEODEV26_ioctl(FRAME_GRABBER_NUMBER,VIDIOCSTUNER,(unsigned long)&tuner);
+
+/* Select palette and depth */
+
+res = VIDEODEV26_ioctl(FRAME_GRABBER_NUMBER,VIDIOCGPICT,(unsigned long)&vpic);
+
+#ifdef COLOR
+vpic.palette = VIDEO_PALETTE_RGB24;
+vpic.depth = 24;
+#else
+vpic.palette = VIDEO_PALETTE_GREY;
+vpic.depth = 8;
+#endif
+
+vpic.brightness = 35000;
+vpic.hue = 32000;
+vpic.contrast = 32000;
+vpic.colour = 32000;
+res = VIDEODEV26_ioctl(FRAME_GRABBER_NUMBER,VIDIOCSPICT,(unsigned long)&vpic);
+
+/* Set window dimensions */
+
+res = VIDEODEV26_ioctl(FRAME_GRABBER_NUMBER,VIDIOCGWIN,(unsigned long)&win);
+
+win.x = 0;
+win.y = 0;
+win.width = FG_W;
+win.height = FG_H;
+res = VIDEODEV26_ioctl(FRAME_GRABBER_NUMBER,VIDIOCSWIN,(unsigned long)&win);
+
+/* Set the buffer */
+
+res = VIDEODEV26_ioctl(FRAME_GRABBER_NUMBER,VIDIOCSFBUF,(unsigned long)(fbuf));
+
+/* IMPORTANT: Set the aperiodic elaboration task */
+
+/* When the new frame is ready, the task elaborate_PID (aperiodic), is activated.*/
+
+VIDEODEV26_ioctl(FRAME_GRABBER_NUMBER,VIDIOCSYNC,(unsigned long)(elaborate_PID));
+\end{verbatim}
+\end{tt}
/branches/new_sharkdoc/vol2/fg.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/netlib.tex
===================================================================
--- branches/new_sharkdoc/vol2/netlib.tex (nonexistent)
+++ branches/new_sharkdoc/vol2/netlib.tex (revision 1676)
@@ -0,0 +1,533 @@
+%----------------------------------------------------------------------------
+\chapter{The Network Library}
+%----------------------------------------------------------------------------
+
+To allow communication among different computers, S.Ha.R.K. provides a Network
+Library implementing the UDP/IP stack on an Ethernet network. The library is
+organized in three layers:
+
+\begin{itemize}
+\item low-level driver: this layer is hardware dependent, since it interacts
+with the network card;
+\item ethernet layer: this layer allows the upper layer to send and receive
+ethernet frames. It is not intended to be used by a user program, but only by
+the code implementing the network protocol;
+\item high-level layer: this layer implements the network (IP) and the transport
+(UDP) protocols. It provides the interface used by a user program to access the
+network through the UDP protocol.
+\end{itemize}
+
+The low-level driver is implemented in order to respect the system real-time
+requirements (avoiding unpredictable delays in sending/receiving frames). This
+result is achieved by solving two different problems: the interrupt handling (in
+the receive phase) and the mutual exclusion needed for accessing the network
+card (in the transmission phase). The first problem is solved by using a SOFT
+task to handle the network card interrupts: on a frame arrival, a task handling
+the reception is activated. Such a task is guaranteed along with all the other
+tasks in the system, thus it cannot jeopardize their schedulability. Since a
+minimum interarrival time for the frames cannot be predicted, the receiving task
+cannot be a sporadic (HARD) task; therefore the task uses a SOFT\_TASK\_MODEL,
+and we have used a Constant Bandwidth Server (CBS) to serve it.
+
+The second problem can be solved using two different methods. The first method
+adopts a shared memory programming paradigm: a task willing to transmit is
+allowed to access the network card; mutually exclusive accesses are guaranteed
+by semaphores. This solution is very simple and the introduced overhead is very
+low. The second soultion is based on the utilization of a server task devoted to
+send frames on the network on behalf of other tasks. Each task posts its frames
+in a mailbox, whence the sender task picks them up. At the moment, only the
+first solution is implemented, but in order to provide a good degree of
+flexibility, both approaches will be supported as soon as possible.
+
+The most diffused higher level protocols have been implemented upon the ethernet
+level. In order to use them within a S.Ha.R.K. application, the
+\texttt{drivers/udpip.h} file, containing the functions prototypes and the data
+structures, has to be included in the application program. As a first step, the
+network drivers have to be initialized. This is done by the \texttt{net\_init()}
+primitive that requires the machine's IP address. After initialization, the
+program has to bind itself to a port by a socket (in UNIX's fashion) by the
+\texttt{udp\_bind()} primitive. Afterwards, it is possible eihter to receive
+packets by using \texttt{udp\_recvfrom()}, or to send them by using
+\texttt{udp\_sendto()}.
+
+\vspace{10mm}
+
+\begin{intest}
+NET\_INIT\index{net\_init()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void net\_init(NET\_MODEL {*}m)}]
+\item [\textbf{Description:}] It is an interface function used for calling the different
+layers initializing functions. The \texttt{m} parameter specifies the protocols
+that are going to be activated along with the parameters to be passed to their
+initializing fucntions. The predefined \texttt{net\_base} value, if used as
+\texttt{net\_init} parameter, causes the ethernet level to be solely intialized
+by using a mutex semaphore for enforcing mutual exclusion. Moreover, the
+\texttt{net\_setudpip(m, addr)} macro is defined to select the UDP/IP protocols
+stack with local IP address \texttt{addr}, expressed in string format. The task
+used to handle network card interrupts has a SOFT\_TASK\_MODEL obtained
+initializing such a model with these arguments: \\
+\texttt{soft\_task\_default\_model(m);} \\
+\texttt{soft\_task\_def\_wcet(m, 1000);} \\
+\texttt{soft\_task\_def\_period(m,20000);} \\
+\texttt{soft\_task\_def\_met(m, 1000);} \\
+\texttt{soft\_task\_def\_aperiodic(m);} \\
+\texttt{soft\_task\_def\_system(m);} \\
+\texttt{soft\_task\_def\_nokill(m);}
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{tt}
+\begin{verbatim}
+int main(int argc, char **argvvoid) {
+ NET_MODEL m = net_base;
+ char talk_myipaddr[50];
+ ...
+ strcpy(talk_myipaddr, "193.205.82.47");
+ net_setudpip(m, talk_myipaddr);
+ net_init(&m);
+ ...
+\end{verbatim}
+\end{tt}
+
+\begin{intest}
+IP\_STR2ADDR\index{ip\_str2addr()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int ip\_srt2addr(char {*}str, IP\_ADDR {*}ip)}]
+\item [\textbf{Description:}] It converts the IP address, contained in the \texttt{str}
+string parameter, into \texttt{IP\_ADDR} format. The result is returned in the
+variable pointed by \texttt{ip}. The function returns \texttt{TRUE} if the
+operation has been succesful, \texttt{FALSE} otherwise.
+\end{description}
+
+\begin{intest}
+UDP\_BIND\index{udp\_bind()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int udp\_bind(UDP\_ADDR {*}a, IP\_ADDR {*}bindlist);}]
+\item [\textbf{Description:}] It binds the receiving program on the specified UDP port. A
+socket is created and its identifier is returned. Moreover the host addresses
+specified through the \texttt{bindlist} parameter are loaded into the ARP table.
+The port is identified by the \texttt{a} parameter which is composed of the
+fields named \texttt{s\_addr}, having \texttt{IP\_ADDR} type, and
+\texttt{s\_port}, having \texttt{WORD} type. The \texttt{s\_port} parameter is
+the most meaningful since it specifies the port the function binds to. Further
+details can be found in any UNIX manual. The possibility of specifying the hosts
+that will be accessed (through the \texttt{bindlist} parameter), permits to add
+ARP table entries in the network initialization phase. In this way, the timing
+impredictability introduced by ARP can be reduced. This possibility can be
+discarded by chosing a \texttt{NULL} value for the \texttt{bindlist} parameter.
+Otherwise such a parameter has to be a pointer to a \texttt{NULL} terminated
+\texttt{IP\_ADDR} array. As we said earlier, the returned socket identifier can
+be fed into the \texttt{udp\_sendto()} primitive.
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{tt}
+\begin{verbatim}
+void *txsessiontask(void *arg) {
+ UDP_ADDR local;
+ IP_ADDR bl[5];
+ int sock;
+
+ /* The periodic txsessiontask, upon its creation, */
+ /* creates a socket befor entering */
+ /* the infinite cycle typical of all */
+ /* periodic tasks */
+ local.s_port = 1030; /* local port */
+
+ /* It loads the eth address of the hosts */
+ /* the task will communicate with */
+ /* into the ARP table */
+ ip_str2addr("193.205.82.47", bl);
+
+ /* terminates bind list by NULL */
+ *((DWORD *)&bl[1]) = NULL;
+ sock = udp_bind(&local, bl);
+ ...
+}
+\end{verbatim}
+\end{tt}
+
+\begin{intest}
+UDP\_SENDTO\index{udp\_sendto()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int udp\_sendto(int s, char {*}buf, int nbytes, UDP\_ADDR {*}to);}]
+\item [\textbf{Description:}] It sends an UDP packet, with size \texttt{nbytes}, whose
+body is pointed by \texttt{buf} to an address specified by \texttt{to}. The last
+parameter has \texttt{UDP\_ADDR} type and identifier either the destination IP
+address or the port (see \texttt{udp\_bind} for further information on
+\texttt{UDP\_ADDR}). In order to send a packet a local socket has to be created,
+by calling the \texttt{udp\_bind()} primitive; its identifier shall be passed by
+the \texttt{s} parameter.
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{tt}
+\begin{verbatim}
+void *txsessiontask(void *arg) {
+ int sock;
+ UDP_ADDR local, to;
+ ...
+ /* socket creation */
+ ...
+
+ for (;;) {
+ ...
+
+ /* prepares the destination address */
+ to.s_port = 1030;
+ ip_str2Addr("127.0.0.1", &(to.s_addr));
+ udp_sendto(sock, msg, msglen, &to);
+ ...
+ task_endcycle();
+ }
+}
+\end{verbatim}
+\end{tt}
+
+\begin{intest}
+UDP\_RECVFROM\index{udp\_recvfrom()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int udp\_recvfrom(int s, char {*}buf, UDP\_ADDR {*}from);}]
+\item [\textbf{Description:}] It receives a UDP packet from the socket identified by
+\texttt{s}; the packet body is copied into the buffer pointed by \texttt{buf};
+the sender address (composed of the pair port-IPaddress) is copied into the
+variable pointed by \texttt{from}. The primitive returns the number of bytes
+composing the packet.
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{tt}
+\begin{verbatim}
+TASK rxsessiontask() {
+ int sock;
+ UDP_ADDR local, from;
+
+ /* The non real-time rxsessiontask */
+ /* creates a receiving socket and */
+ /* enters an infinite loop waiting */
+ /* for the incoming packets */
+ ...
+ /* During initialization the */
+ /* socket is created */
+ ...
+ for (;;) {
+ ...
+ udp_recvfrom(sock, inmsg, &from);
+ /* from contains the sender address */
+ ...
+ task_endcycle();
+ }
+}
+\end{verbatim}
+\end{tt}
+
+\begin{intest}
+UDP\_NOTIFY\index{udp\_notify()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int udp\_notify(int s, int({*}f)(int len, BYTE {*}buf, void {*}p))}]
+\item [Desription:]the notifying function \texttt{f} is associated with the
+\texttt{s} socket. When a packet addressed to the port the socket is bound to
+arrives, such a function is invoked. Upon its invocation, the function receives
+as arguments a pointer to the received packet (\texttt{buf}), the packet size
+(\texttt{len}), and a pointer specified along with the \texttt{udp\_notify()}
+call (\texttt{p}). The notifying function is executed within the context of the
+receiving task; therefore, it should not consume too much time.
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{tt}
+\begin{verbatim}
+int hrtp_recvfun(int len, BYTE *b, void *p) {
+ struct HRTP_SESSION *s;
+ struct HRTP_HDR *h;
+ ...
+
+ /* Notifying function used for receiving */
+ /* packets from a session level protocol */
+ ...
+ /* p is a pointer to the descriptor of */
+ /* the session involved in the transmission */
+ s = p;
+
+ /* the received packet is copied into a private */
+ /* buffer belonging to the session */
+ h = (struct HRTP_HDR *) & (s->b[s->recvd * instance_dim]);
+ memcpy(h, b, len);
+ ...
+
+ return 0;
+}
+...
+
+void hrtp_recv(struct HRTP_SESSION *s, void (*f)(void)) {
+ udp_notify(s->sock, hrtp_recvfun, (void *)s);
+ s->notifyparm = f;
+ s->active = HRTP_RCVIN;
+}
+...
+\end{verbatim}
+\end{tt}
+
+A programmer that wants to implement a new transport/network level stack
+different from UDP/IP needs to directly access the Ethernet services. This can
+be done using the Ethernet layer, accessible through the ``eth.h'' header
+file.
+
+In order to receive Ethernet frames, a callback function has to be associated to
+a frame type (the frame type is a field of a frame): each time that a frame of
+the specified type will arrive, the callback function will be called. A callback
+can be bound to a frame type using the \texttt{eth\_setHeader} library call.
+
+In order to transmit Ethernet frames, a transmission buffer must be allocated
+and filled: the header can be filled using \texttt{eth\_setHeader()}, while the
+body must be explicitly filled after obtaining a pointer to it through
+\texttt{eth\_getFDB()}. At this point the frame can be sent using
+\texttt{eth\_sendPKT()}. Transmission buffers can be allocated using the
+\texttt{netbuff} module: this module (usable including the ``netbuff.h''
+header file) permits to manage pools of pre-allocated buffers, in order to
+minimize the unpredictability due to dynamic allocation.
+
+\begin{intest}
+NETBUFF\_INIT\index{netbuff\_init()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void netbuff\_init(NETBUFF {*}netb, BYTE nbuffs, WORD buffdim);}]
+\item [\textbf{Description:}] It initializes a pool composed of \texttt{nbuffs} buffers,
+each of them have \texttt{buffdim} size. The pool is identified by the
+\texttt{netb} descriptor.
+\end{description}
+
+\begin{intest}
+NETBUFF\_GET\index{netbuff\_get()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void {*}netbuff\_get(NETBUFF {*}netb, BYTE flag);}]
+\item [\textbf{Description:}] It returns a pointer to the first free buffer in the pool
+identified by \texttt{netb}. The \texttt{flag} parameter, which can assume
+values \texttt{BLOCK} or \texttt{NON\_BLOCK}, indicates whether the operation is
+a blocking or non-blocking allocation. If a non-blocking \texttt{netbuff\_get()}
+is performed when the pool does not contain any free buffer, a NULL pointer is
+returned.
+\end{description}
+
+\begin{intest}
+NETBUFF\_RELEASE\index{netbuff\_release()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void netbuff\_release(NETBUFF {*}netb, void {*}buff);}]
+\item [\textbf{Description:}] It marks the buffer pointed by \texttt{buff} as free in the
+\texttt{netb} pool.
+\end{description}
+
+\begin{intest}
+ETH\_INIT\index{eth\_init()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void eth\_init(int mode, TASK\_MODEL {*}m);}]
+\item [\textbf{Description:}] It initializes the Ethernet layer, in order to transmit or
+receive ethernet frames. If the Ethernet layer has already been initialized, it
+does nothing.
+
+Each network level protocol that needs to access the network card must pass
+through the Ethernet layer, which must be initialized before receiving or
+sending anything. The Ethernet layer will search for a supported network card,
+enable it and initalize some internal structures.
+
+At the moment, the \texttt{mode} parameter is not used, in the future it will be
+used to select an operating mode (mutual exclusion on send operation through a
+dedicated server task or through mutexes).
+
+This library function is called by \texttt{net\_init()} in the standard UDP/IP
+configuration.
+
+The task model used for the task that handles the network card interrupts can be
+passed with the m parameter. If it is NULL, a SOFT\_TASK\_MODEL obtained
+initializing such a model with these arguments will be used: \\
+\texttt{soft\_task\_default\_model(m);}\\
+\texttt{soft\_task\_def\_wcet(m,1000);}\\
+\texttt{soft\_task\_def\_period(m,20000);}\\
+\texttt{soft\_task\_def\_met(m,1000);}\\
+\texttt{soft\_task\_def\_aperiodic(m);}\\
+\texttt{soft\_task\_def\_system(m);}\\
+\texttt{soft\_task\_def\_nokill(m);}
+\end{description}
+
+\begin{intest}
+HTONS \& NTOHS \index{htons()}\index{ntohs()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{WORD htons(WORD host);}]
+\item [\textbf{WORD ntohs(WORD net);}]
+\item [\textbf{Description:}] These two utility functions convert a WORD from the host
+format to the net format (\texttt{htons}) and vice-versa (\texttt{ntohs}).
+\end{description}
+
+\begin{intest}
+ETH\_GETADDRESS\index{eth\_getAddress()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void eth\_getAddress(ETH\_ADDR {*}eth);}]
+\item [\textbf{Description:}] It returns the net card Ethernet address in the
+\texttt{ETH\_ADDR} structure pointed by \texttt{eth}.
+\end{description}
+
+\begin{intest}
+ETH\_STR2ADDR\index{eth\_str2addr()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void eth\_str2addr(char {*}add, struct ETH\_ADDR {*}ds);}]
+\item [\textbf{Description:}] It converts an Ethernet address from the string format
+({}``xx:xx:xx:xx:xx:xx'') to the byte (\texttt{ETH\_ADDR}) format. The
+\texttt{add} string contains the address in text format, while \texttt{ds} is a
+pointer to the \texttt{ETH\_ADDR} structure where the output is placed.
+\end{description}
+
+\begin{intest}
+ETH\_SETPROTOCOL\index{eth\_setProtocol()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int eth\_setProtocol(WORD type, void ({*}recv)(void {*}frame))}]
+\item [\textbf{Description:}] It is used to specify the callback function \texttt{recv} to
+be called when a frame of type \texttt{type} is received. It returns
+\texttt{TRUE} in the case of success, \texttt{FALSE} otherwise. When the
+Ethernet layer will call the \texttt{recv} callback, it will pass to the
+function a pointer to the received frame.
+
+The callback function runs in the context of the driver task, served by a CBS.
+
+Each high-level protocol must use this library call to register itself in order
+to process incoming packets.
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{tt}
+\begin{verbatim}
+void ip_server_recv(void *pkt) {
+ IP_HEADER *iphd;
+ ...
+
+ /* This callback is invoked when an IP packet is received */
+ iphd = (IP_HEADER *)eth_getFDB(pkt);
+ ...
+}
+...
+
+void ip_init(char *localAddr) {
+ int i;
+
+ /* Initializes IP */
+ ...
+ /* Registers the protocol to the ethernet layer */
+ eth_setProtocol(ETH_IP_TYPE,ip_server_recv);
+ ...
+}
+\end{verbatim}
+\end{tt}
+
+\begin{intest}
+ETH\_SETHEADER\index{eth\_setHeader()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void {*}eth\_setHeader(void {*}b, ETH\_ADDR dest, WORD type);}]
+\item [\textbf{Description:}] It fills the header of the frame pointed by \texttt{b} with
+the destination address \texttt{dest} and the frame type \texttt{type}. It also
+returns a pointer to the body of the ethernet frame.
+\end{description}
+
+\begin{intest}
+ETH\_GETFDB\index{eth\_getFDB()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void {*}eth\_getFDB(void {*}p)}]
+\item [\textbf{Description:}] Get First Data Byte. It returns a pointer to the body of the
+frame pointed by the \texttt{p} parameter.
+\end{description}
+
+\begin{intest}
+ETH\_SENDPKT\index{eth\_sendPkt()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int eth\_sendPkt(void {*}p, int len);}]
+\item [\textbf{Description:}] It transmits the Ethernet frame pointed by \texttt{p},
+having lenght \texttt{len}. The destination and the frame type must be
+previously specified using \texttt{eth\_setHeader}.
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{tt}
+\begin{verbatim}
+void arp_sendRequest(int i) {
+ ARP_PKT *pkt;
+ ETH_ADDR broadcast, nulladdr;
+
+ eth_str2Addr("FF:FF:FF:FF:FF:FF", &broadcast);
+ eth_str2Addr("00:00:00:00:00:00", &nulladdr);
+ eth_setHeader(arpBuff, broadcast, ETH_ARP_TYPE);
+ pkt = (ARP_PKT *)eth_getFDB(arpBuff);
+ pkt->htype = htons(ARP_ETH_TYPE);
+ pkt->ptype = htons(ARP_IP_TYPE);
+ pkt->hlen = sizeof(ETH_ADDR);
+ pkt->plen = sizeof(IP_ADDR);
+ pkt->operation = htons(ARP_REQUEST);
+ setEthAddr(pkt->sha, myEthAddr);
+ setEthAddr(pkt->tha, nulladdr);
+ setIpAddr(pkt->sip, myIpAddr);
+ setIpAddr(pkt->tip, arpTable[i].ip);
+ eth_sendPkt(arpBuff, sizeof(ARP_PKT));
+}
+\end{verbatim}
+\end{tt}
+
+\begin{intest}
+ETH\_CLOSE\index{eth\_close()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int eth\_close(void);}]
+\item [\textbf{Description:}] It closes the Ethernet protocol. If it is not explicitly
+called by the user, it is automatically executed through \texttt{sys\_atexit}.
+\end{description}
/branches/new_sharkdoc/vol2/netlib.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/makefile
===================================================================
--- branches/new_sharkdoc/vol2/makefile (nonexistent)
+++ branches/new_sharkdoc/vol2/makefile (revision 1676)
@@ -0,0 +1,4 @@
+MAIN = vol2
+MAIN_NAME = vol2
+
+include ../common/manual.mk
/branches/new_sharkdoc/vol2/makefile
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/snapshot.tex
===================================================================
--- branches/new_sharkdoc/vol2/snapshot.tex (nonexistent)
+++ branches/new_sharkdoc/vol2/snapshot.tex (revision 1676)
@@ -0,0 +1,64 @@
+%----------------------------------------------------------------------------
+\chapter{The Snapshot Library}
+%----------------------------------------------------------------------------
+
+The library allow applications to save up to 16 screen snapshot to file. Before
+the grabbing is necessary to allocate the memory for a snapshot slot and files
+can be created only at the end of execution when the system return in real mode.
+
+\vspace{7mm}
+
+\begin{intest}
+SNAPSHOT\_GETSLOT \index{snapshot\_getslot()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void {*}snapshot\_getslot(int nbuff, int wx, int wy, int byesperpixel); }]
+\item [\textbf{Description:}] This function allocate the memory for a snapshot of given
+dimensions. The \texttt{nbuff} parameter indicate which slot must be allocated.
+\texttt{wx} and \texttt{wy} are width and height of the screen resolution while
+\texttt{bytesperpixel} is the depth of the screen.
+\end{description}
+
+\begin{intest}
+SNAPSHOT\_FREESLOT\index{snapshot\_freeslot()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void snapshot\_freeslot(int nbuff) }]
+\item [\textbf{Description:}] This function free the memory reserved for the slot
+indicated by the \texttt{nbuff} parameter.
+\end{description}
+
+\begin{intest}
+SNAPSHOT\_GRAB\index{snapshot\_grab()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void snapshot\_grab(int nbuff) }]
+\item [\textbf{Description:}] This function get a snap of the video memory and copy it
+inside the slot specified by the \texttt{nbuff} parameter.
+\end{description}
+
+\begin{intest}
+SNAPSHOT\_SAVEPGM\index{snapshot\_savepgm()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int snapshot\_savepgm(int nbuff, char {*}fname) }]
+\item [\textbf{Description:}] This function save the screen snapshot saved inside the
+nbuff slot to a PGM greyscale file. The filename passed to the function using
+the fname parameter.
+\end{description}
+
+\begin{intest}
+SNAPSHOT\_SAVEPPM\index{snapshot\_saveppm()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int snapshot\_saveppm(int nbuff, char {*}fname) }]
+\item [\textbf{Description:}] This function save the screen snapshot saved inside the
+nbuff slot to a PPM color file. The filename passed to the function using the
+fname parameter.
+\end{description}
+
/branches/new_sharkdoc/vol2/snapshot.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/soundlib.tex
===================================================================
--- branches/new_sharkdoc/vol2/soundlib.tex (nonexistent)
+++ branches/new_sharkdoc/vol2/soundlib.tex (revision 1676)
@@ -0,0 +1,302 @@
+%----------------------------------------------------------------------------
+\chapter{The Sound Library}
+%----------------------------------------------------------------------------
+
+If a SoundBlaster16 sound card is available, S.Ha.R.K. allows to sample and play
+sounds by using the functions provided by the sound library \footnote{Currently
+only the sound blaster 16 is supported; the code of the library is directly
+inherited from the Hartik 3.3.0 Kernel...}. The library currently supports
+either program or DMA controlled sampling an playing, according to 4 possible
+operating modes:
+
+\begin{itemize}
+\item PIO mode;
+\item DMA-Raw mode;
+\item DMA-Double-buffering mode;
+\item DMA-Self-buffering mode.
+\end{itemize}
+
+Working under PIO mode, sounds can be sampled and played only with 8 bit PCM.
+The frequence depends on the hardware speeds but cannot in any case overcome 10
+Khz. This mode is reserved for the pure classical hard real-time approach which
+refuses the usage of DMA controlled I/O.
+
+The DMA-Raw mode uses DMA controller to sample and play directly on a memory
+buffer. Owing to technical problems related to the structure of the PC DMA
+controller, the buffer's size can be no bigger than 64K. This mode is the one
+that minimizes the DMA operations' impact on CPU.
+
+The DMA Double-Buffering mode uses an internal buffer in order to overcome the
+64k limitation. The internal buffer is split into two parts: while the DMA
+tranfers data to one half, an ad-hoc task moves data between the second half and
+a user-provided external memory region. In this way, it is possible for a user
+to work on samples much bigger than 64K, paying the fee of a higher CPU load
+\footnote{This is possible only if the protected mode is used.}.
+
+The DMA-Self-Buffering mode allows the user to directly handle the internal
+buffer. The user specifies a function to be activated every time the DMA
+controller has finished transferring data on one half of the internal buyffer.
+In this mode, the user can obtain the data while they are being sampled; the
+time lag between sampling and data delivery is thus reduced. Such a feature
+makes this working mode interesting for real-time applications. Independently of
+the chosen working mode, an operation can be either synchronous or asynchronous.
+A synchronous operation provides the task invoking the operation with a
+synchronizing point located at its ending. In order to use the sound library
+functions, the files \texttt{drivers/sound.h} and \texttt{drivers/dma.h} must be
+included. The former contains the prototypes of the declared functions, the
+latter is necessary because the sound library uses DMA.
+
+The first step to be performed is initializing the audio drivers by the
+\texttt{sound\_init} function. Then, if one wishes to work in DMA-Raw mode, it
+is necessary to allocate a memory buffer and align it by calling
+\texttt{dma\_getpage()} (in the remaining modes no particular alignment is
+required for the buffer). If the DMA-Self-buffering mode is chosen, the
+programmer has to properly set the functions to be called every time the DMA
+finishes working on one half of the internal buffer; this can be done by calling
+the \texttt{sound\_setfun()} primitive. As soon as these operations have been
+performed, sampling or playing can be made through \texttt{sound\_sample()} and
+\texttt{sound\_play()}, respectively.
+
+\vspace{7mm}
+
+\begin{intest}
+SOUND\_INIT\index{sound\_init()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void sound\_init(WORD rawbufsize, WORD tick);}]
+\item [\textbf{Description:}] It initializes the audio driver by allocating the
+internal
+buffer for the DMA-Double-buffering and DMA-Self-Buffering modes. The
+\texttt{rawbufsize} parameter contains the dimension of this buffer. Higher
+values reduce the CPU load and are thus advised when using the
+DMA-Double-buffering mode. Lower values, on the contrary, can be used to shorten
+the latency between sampling and data delivering (particularly when using
+DMA-Self-buffering). The \texttt{tick} parameter contains the value of the
+system tick; its correctness is fundamental for the PIO mode.
+\end{description}
+
+\begin{intest}
+SOUND\_INFO\index{sound\_info()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void sound\_info(void);}]
+\item [\textbf{Description:}] It outputs on the screen some information concerning
+the soundcard and the drivers.
+\end{description}
+
+\begin{intest}
+SOUND\_SETFUN\index{sound\_setfun()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void sound\_setfun(int ({*}infun)(BYTE {*}rawbuff),}\\
+\texttt{int ({*}outfun)(BYTE {*}rawbuff));}]
+\item [\textbf{Description:}] It specifies the functions to be called when the DMA
+finishes working on one of the two internal buffer's halves when using
+DMA-Self-Buffering mode. The function pointed by \texttt{infun} is used when
+performing sampling operations, whereas \texttt{outfun} is used for playing
+operations. Both functions receive a pointer to the half-buffer not currently
+acted upon by the DMA (the half-buffer sizes are equal to one half of the
+\texttt{sound\_init()} parameter) and have to return 0 if the operation has not
+yet been finished, 1 if it is going to finish in the next DMA cycle, and 2 if it
+finishes immediately. Attention should be paid to the fact that these functions
+are periodically called with a frequency equal to the operation's frequency
+divided by the half-buffer's size; thus, they should be very short in order not
+to overload the system.
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{tt}
+\begin{verbatim}
+int osc_fun(BYTE *b) {
+ int i;
+ int sum = 0;
+ BYTE *p;
+
+ /* Averages the values read from the buffer */
+ /* and writes the result on a CAB shared */
+ /* with a task */
+ for (i = 0; i < (BUFFDIM >> 1); i++)
+ sum += b[i];
+ sum = (BUFFDIM >> 1);
+ p = cab_reserve(cc);
+ *p = (BYTE) sum;
+ cab_putmes(cc, p);
+ return 0;
+}
+...
+
+void *io_task(void *arg) {
+ int x, y;
+ BYTE *p;
+ BYTE page = 0;
+ char str[50];
+ short int talk, silencecount;
+
+ /* This task reads the value put on the CAB by */
+ /* the self-buffering function */
+ /* sets the self-buffering function */
+ sound_setfun(osc_infun, -1);
+
+ /* starts the sampling operation */
+ sound_sample(NULL, 20000, 0, DMA_OP | PCM8 | MYFUN);
+ cc = cab_create("osc_cab", sizeof(BYTE), 3);
+ for (;;) {
+ /* reads and proccesses */
+ /* the CAB's value */
+ ...
+ task_endcycle();
+ }
+ return 0;
+}
+\end{verbatim}
+\end{tt}
+
+\begin{intest}
+SOUND\_SAMPLE\index{sound\_sample()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void sound\_sample(BYTE {*}buf, DWORD sps, DWORD len, BYTE t);}]
+\item [\textbf{Description:}] It samples \texttt{len} bytes in the \texttt{buf}
+buffer at the frequency of \texttt{sps} samples per second with the mode
+expressed by \texttt{t}. The latter can be assigned one of the following
+constants:
+
+\begin{itemize}
+\item \texttt{PIO\_OP} operates using PIO mode: as said earlier, in this mode
+values for \texttt{sps} higher than 10000 make no sense. Moreover, for the
+sampling and playing to happen with the correct timing, it is necessary that the
+audio driver be initialized with the \texttt{tick} parameter set to the system
+tick expressed in microseconds (see \texttt{sound\_init()} for more details).
+\item \texttt{DMA\_OP} operates using one of the DMA modes (the default is
+DMA-Double-Buffering). The internal buffer size is specified in
+\texttt{sound\_init}.
+\item \texttt{PCM8} operates using 8 bit PCM format (it is the default). It is
+the only possible format in PIO mode.
+\item \texttt{PCM16} operates using 16 bit PCM format. This choice is
+meaningless in PIO mode.
+\item \texttt{SYNCH} synchronous operation: it is necessary to call
+\texttt{sound\_wait()} after \texttt{sound\_sample()}.
+\item \texttt{ASYNCH} asynchronous operation.
+\item \texttt{MYFUN} operates with DMA-Self-buffering mode; it makes sense only
+if \texttt{DMA\_OP} has been set.
+\item \texttt{NOBUFF} operates in DMA-Raw-Mode; it makes sense only if
+\texttt{DMA\_OP} has been set.
+\end{itemize}
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{tt}
+\begin{verbatim}
+BYTE buff[0xFFFFF]; /* buffer for sampling */
+
+void main() {
+ sys_init(\&s);
+ keyb_init(NULL);
+ clear();
+
+ sound_init(0x4000, TICK);
+ sound_info();
+
+ cprintf("Recording...");
+ sound_sample(buff, 44000, 0x8FFFF, DMA_OP | PCM8 | SYNCH);
+ ...
+}
+\end{verbatim}
+\end{tt}
+
+\begin{intest}
+SOUND\_PLAY\index{sound\_play()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void sound\_play(BYTE {*}buff, DWORD sps, DWORD len, BYTE t);}]
+\item [\textbf{Description:}] It plays \texttt{len} bytes taken from the \texttt{b}
+buffer
+at the frequency of \texttt{sps} samples per second with the mode expressed by
+\texttt{t}. As far as the values of \texttt{t} are concerned, the reader can
+refer to \texttt{sound\_sample}.
+\end{description}
+
+\begin{intest}
+DMA\_GETPAGE\index{dma\_getpage()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{BYTE {*}dma\_getpage(DWORD {*}dim);}]
+\item [\textbf{Description:}] It allocates a buffer having size \texttt{dim} fitting
+for
+use in DMA operations. Such a usage is possible only if the buffer does not
+contain bytes whose address differs in the Most Significant Bits. The best way
+to achieve this feature is to allocate buffers sized less than 64K starting from
+addresses having the LSB equal to 0. This job is performed by
+\texttt{dma\_getpage}. It should be noted that such a feature is necessary only
+using DMA-Raw-Mode, since the buffer allocation is automatically performed by
+\texttt{sound\_init} when using DMA-Double-Buffering and DMA-Self-Bufering
+modes.
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{tt} \begin{verbatim}
+void main(void) {
+ BYTE *p;
+ int i;
+
+ /* Monitors the time stolen by the DMA */
+ /* to the CPU during a 10 Khz sampling */
+ sys_init(&s);
+ keyb_init(NULL);
+ ...
+ clear();
+ p = dma_getpage(0xFFFF);
+ sound_init(0x200, TICK);
+ sound_info();
+
+ for (i = 0; i < 80; i++) cprintf("_");
+ cprintf("ref_time: %f ", myrif);
+ cprintf("Unloaded system: %f", load(&myrif));
+
+ cprintf("DMA Recording...");
+ sound_sample(p, 10000, 0xFFFF, DMA_OP | PCM8 | NOBUFF);
+ ...
+\end{verbatim}
+\end{tt}
+
+\begin{intest}
+SOUND\_WAIT\index{sound\_wait()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void sound\_wait(void);}]
+\item [\textbf{Description:}] It is the synchronization primitive for synchronous
+operations. The task calling \texttt{sound\_wait()} blocks itself until the
+synchronous operation is finished. The call to this function is mandatory for
+synchronous operations. On the other hand, using the function in conjunction
+with an asynchronous operation is an error.
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{tt}
+\begin{verbatim}
+ sound_sample(buff, 44000, 0x8FFFF, DMA_OP | PCM8 | SYNCH);
+ ...
+ /* waits until the sampling termination */
+ sound_wait();
+ ...
+\end{verbatim}
+\end{tt}
/branches/new_sharkdoc/vol2/soundlib.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/input.tex
===================================================================
--- branches/new_sharkdoc/vol2/input.tex (nonexistent)
+++ branches/new_sharkdoc/vol2/input.tex (revision 1676)
@@ -0,0 +1,1471 @@
+%----------------------------------------------------------------------------
+\chapter{The Input Library}
+%----------------------------------------------------------------------------
+
+This library allow the user to interact with applications. Is composed by a
+lower lever which must be initialized at the beginning. On top of this layer we
+can find different peripherals:
+
+\begin{itemize}
+\item Keyboard;
+\item Mouse;
+\item Joystick;
+\item Speaker;
+\item Event debugger.
+\end{itemize}
+
+Each one can work independently from the others. In order to use the low lever
+functions, the files \texttt{drivers/shark\_input26.h} must be included. It
+contains the prototypes of the declared functions. First of all, the keyboard
+needs be initialized by the calling \texttt{KEYB26\_init} primitive into the
+\texttt{\_\_init\_\_} function in the initialization file or in any other point
+of the application code.
+
+\vspace{7mm}
+
+\begin{intest}
+INPUT26\_INIT\index{INPUT26\_init()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int INPUT26\_init(void);}]
+\item [\textbf{Description:}]It initializes the low lever input interface and
+the library's internal data structures.
+\item [\textbf{Return value:}] 0 if the operation is performed successfully; a
+value less than 0, otherwise.
+\end{description}
+
+\vspace{7mm}
+
+The following code shows an example of input drivers initialization for the
+system:
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{verbatim}
+int res;
+KEYB_PARMS kparms = BASE_KEYB;
+MOUSE_PARMS mparms = BASE_MOUSE;
+
+LINUXC26_register_module(TRUE);
+INPUT26_init();
+
+keyb_def_map(kparms, KEYMAP_IT);
+
+keyb_def_ctrlC(kparms, NULL);
+
+KEYB26_init(&kparms);
+
+mouse_def_threshold(mparms, 5);
+mouse_def_xmin(mparms, 0);
+mouse_def_ymin(mparms, 0);
+mouse_def_xmax(mparms, 639);
+mouse_def_ymax(mparms, 479);
+MOUSE26_init(&mparms);
+
+SPEAK26_init();
+JOY26_init();
+...
+\end{verbatim}
+
+\vspace{7mm}
+
+The event debugger is used to have an output of the raw data coming from an
+input device for which a driver is not present. It can be stanter, stopper and
+is possible to control the actual status.
+
+\vspace{7mm}
+
+\begin{intest}
+EVBUG26\_INIT\index{EVBUG26\_init()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int EVBUG26\_init(void);}]
+\item [\textbf{Description:}]It initializes the event debugger interface and the
+library's internal data structures.
+\item [\textbf{Return value:}] 0 if the operation is performed successfully; a
+value less than 0, otherwise.
+\end{description}
+
+\begin{intest}
+EVBUG26\_CLOSE\index{EVBUG26\_close()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int EVBUG26\_close(void);}]
+\item [\textbf{Description:}]It close the event debugger interface.
+\item [\textbf{Return value:}] 0 if the operation is performed successfully; -1
+if the interface in not installed.
+\end{description}
+
+\begin{intest}
+EVBUG26\_INSTALLED\index{EVBUG26\_installed()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int EVBUG26\_installed(void);}]
+\item [\textbf{Description:}]Return if the event debugger is actually installed.
+\item [\textbf{Return value}:] 0 if the module is installed; 1 otherwise.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{The keyboard library}
+%----------------------------------------------------------------------------
+
+In order to use the keyboard handling functions, the
+\texttt{drivers/shark\_keyb26.h} header file, containing the interface
+functions' prototypes, has to be included in the application program.
+
+First of all, the keyboard needs be initialized by the calling
+\texttt{KEYB26\_init} primitive into the \texttt{\_\_init\_\_} function in the
+initialization file or in any other point of the application code and the input
+low level driver must be already installed. A programmer can either initialize
+the keyboard using the default settings or define his own parameters which are
+encapsulated into a structure having \texttt{KEY\_PARMS} type. The strucuture
+can be initialized with the default set of values by setting it equal to
+\texttt{BASE\_KEYB}; the \texttt{keyb\_def\_...} macros can be used before
+calling \texttt{KEYB26\_init} to modify each setting. Afterwards, it is possible
+to read the ASCII code of any stroken key by calling the \texttt{keyb\_getch()}
+function. This function requires a parameter which determines whether the task
+should block until a key is hit or not. In the latter case, if no key has been
+hit, the function returns 0 (behaving like \texttt{kbhit()}).
+
+If we are interested in the key's scan code, we can call the
+\texttt{keyb\_getcode()} function, which returns a struct containing either the
+scan code or the ascii code and a byte containing information on the ALT, SHIFT
+or CTRL key being pressed.
+
+The following code shows an example of usage for the function:
+
+\begin{verbatim}
+KEY_EVT k;
+...
+
+if (keyb_getcode(&k, NON_BLOCK) {
+ if (isRightCtrl(k) || isLeftCtrl(k)) && (k.ascii == 'x')) {
+
+ /* Ctrl + `x' has been pressed */
+ ...
+ }
+}
+...
+\end{verbatim}
+
+\noindent Finally, it is possible to define a function to be automatically
+called every time a specific key (or a specific combination of keys) is pressed.
+This is done by calling the \texttt{keyb\_hook()} function, which receives as
+arguments a data structure containing the required combination of keys and the
+function to be called.
+
+\vspace{7mm}
+
+\begin{intest}
+KEYB26\_INIT\index{KEYB26\_init()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int KEYB26\_init(KEYB\_PARMS {*}parms);}]
+\item [\textbf{Description:}]It initializes the keyboard interface and the
+library's internal data structures. It can be called using NULL as
+\texttt{parms} to initialize the keyboard interface to default values. \\ Note
+that to be proper initialized, you need also to initialize the HARTPORT
+modules.
+\item [\textbf{Return value:}] 0 if the operation is performed successfully; a
+value less than 0, otherwise.
+\end{description}
+
+\begin{intest}
+KEYB26\_CLOSE\index{KEYB26\_close()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int KEYB26\_close(void);}]
+\item [\textbf{Description:}]It close the keyboard interface.
+\item [\textbf{Return value:}] 0 if the operation is performed successfully; -1
+if the keyboard in not installed.
+\end{description}
+
+\begin{intest}
+KEYB26\_INSTALLED\index{KEYB26\_installed()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int KEYB26\_installed(void);}]
+\item [Description:]Return if the keyboard driver is actually installed.
+\item [\textbf{Return value:}] 0 if the keyboard is installed; 1 otherwise.
+\end{description}
+
+\begin{intest}
+KEYB\_DEFAULT\_PARM\index{keyb\_default\_parm()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void keyb\_default\_parm(KEYB\_PARMS parms);}]
+\item [\textbf{Description:}] It changes the values of parms to the same vales
+as the BASE\_KEYB default initializer.
+\end{description}
+
+\begin{intest}
+KEYB\_DEF\_MAP\index{keyb\_def\_map()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void keyb\_def\_map(KEYB\_PARMS parms, unsigned char map);}]
+\item [\textbf{Description:}]It changes the default map used for the keyboard:
+\texttt{map} can be \texttt{KEYMAP\_US} for an english keyboard or
+\texttt{KEYMAP\_IT} for an italian keyboard. The default is english keyboard
+layout.
+\end{description}
+
+\begin{intest}
+KEYB\_DEF\_CTRLC\index{keyb\_def\_ctrlC()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void keyb\_def\_ctrlC(KEYB\_PARMS parms, void
+({*}ctrlcfunc)(KEY\_EVT {*}k));}]
+\item [\textbf{Description:}] It enables the execution of a function when the
+{}``ctrl\-C'' combination is pressed. By default, if this macro is not used, the
+\texttt{ctrl\-C} combination results in calling \texttt{sys\_end()}. Note that a
+small message is printed also on the console. The message is only visible if the
+system is in text mode. If you are running a graphic application, remember to
+redefine the Ctrl-C Handler!
+\end{description}
+
+\begin{intest}
+KEYB\_DEF\_TASK\index{keyb\_def\_task()}
+\end{intest}
+\begin{description}
+\item [\textbf{void keyb\_def\_task(KEYB\_PARMS parms, TASK\_MODEL {*} m);}]
+\item [\textbf{Description:}] It specifies the parameters of the keyboard
+server. The \texttt{TASK\_MODEL} {*} should be a valid pointer to a Task Model,
+or \texttt{KEYB\_DEFAULT} if you want to specify the default behaviour. \\
+This macro should be used every time the default server Task Model does not
+adapt well to the configuration of the scheduling modules registered in the
+system. \\
+The default server Task Model is equivalent to this initialization:\\
+\texttt{soft\_task\_default\_model(base\_m);}\\
+\texttt{soft\_task\_def\_wcet(base\_m,2000);}\\
+\texttt{soft\_task\_def\_met(base\_m,800);}\\
+\texttt{soft\_task\_def\_period(base\_m,25000);}\\
+\texttt{soft\_task\_def\_system(base\_m);}\\
+\texttt{soft\_task\_def\_nokill(base\_m);}\\
+\texttt{soft\_task\_def\_aperiodic(base\_m);}
+\end{description}
+
+\begin{intest}
+KEYB\_GETCH, KEYB\_GETCHAR \index{keyb\_getch()} \index{keyb\_getchar()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int keyb\_getch(BYTE wait);}]
+\item [\textbf{int keyb\_getchar(void);}] (macro)
+\item [\textbf{Description:}]If the keyboard queue is not empty,
+\texttt{keyb\_getch()} returns the ASCII code of the pressed key. If the queue
+is empty, the function's behaviour depends on the value of the \texttt{wait}
+parameter: if it is \texttt{BLOCK}, then the calling task is blocked until a key
+is pressed; if it is \texttt{NON\_BLOCK}, the function returns 0.
+\texttt{keyb\_getchar()} is a macro for \texttt{keyb\_getch(BLOCK)}.
+\item [\textbf{Return value:}] the ASCII code of the pressed key, if the buffer
+is not empty; 0 otherwise.
+\end{description}
+
+\begin{intest}
+KEYB\_GETCODE\index{keyb\_getcode()}
+\end{intest}
+\begin{description}
+\item [\texttt{int}]\texttt{keyb\_getcode(KEY\_EVT
+{*}k,
+BYTE
+wait);}
+\item [\textbf{Description:}] It fetches the \texttt{KEY\_EVT} from the
+keyboard's queue and copies it into the structure pointed by \texttt{k}. If the
+queue is empty, the function behaves as \texttt{key\_getch()}.
+\item [\textbf{Return value:}] 1 if a key was pressed, 0 otherwise.
+\end{description}
+
+\begin{intest}
+KEYB\_HOOK\index{keyb\_hook()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void}]\texttt{keyb\_hook(KEY\_EVT key, void ({*}hook)(KEY\_EVT
+{*}keypressed), unsigned char lock);}
+\item [\textbf{Description:}] Whenever the key combination specified in
+\texttt{key} is pressed, the function \texttt{hook()} is invoked, getting
+\texttt{key} as input parameter. If lock is set to \texttt{FALSE} after
+executing the function \texttt{hook()}the key will be lost, otherwise it will be
+inserted in the queue.
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{verbatim}
+#include <drivers/shark_keyb26.h>
+
+void hook_func(KEY_EVT *keypressed) {
+ switch (keypressed->ascii) {
+ case 'w':
+ /* if 'CTRL-w' is pressed... */
+ ...
+ break;
+ case 'x':
+ if (isLeftAlt(keypressed) || isRightAlt(keypressed)) {
+ /* if 'ALT-x' is pressed... */
+ ...
+ } else {
+ /* if 'x' is pressed... */
+ ...
+ }
+ }
+}
+
+int main(int argc,char *argv[]) {
+ KEY_EVT key;
+
+ /* keyboard initialization */
+
+ /* to hook 'CTRL-w' key */
+
+ key.ascii = 'w';
+ key.scan = KEY_W;
+ key.status = KEY_PRESSED;
+ key.flag = CNTR_BIT;
+ keyb_hook(key,hook_func,FALSE);
+
+ /* to hook key 'x' */
+
+ key.ascii = 'x';
+ key.scan = KEY_X;
+ key.status = KEY_PRESSED;
+ key.flag = 0;
+ keyb_hook(key,hook_func, FALSE);
+
+ /* to hook 'ALT-x' key */
+
+ key.flag = ALTL_BIT | ALTR_BIT;
+ keyb_hook(key,hook_func, FALSE);
+ ...
+}
+\end{verbatim}
+
+\begin{intest}
+KEYB\_DISABLE\index{keyb\_disable()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void keyb\_disable(void);}]
+\item [\textbf{Description:}] Throw away the data arriving from the hardware
+instead of processing them inside the driver.
+\end{description}
+
+\begin{intest}
+KEYB\_ENABLE\index{keyb\_enable()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void keyb\_enable(void);}]
+\item [\textbf{Description:}] Allow the driver to receive data from the
+hardware.
+\end{description}
+
+\begin{intest}
+KEYB\_SET\_MAP\index{keyb\_set\_map()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int keyb\_set\_map(unsigned char map);}]
+\item [\textbf{Description:}] It changes the default map used for the keyboard:
+\texttt{map} can be \texttt{KEYMAP\_US} for an english keyboard or
+\texttt{KEYMAP\_IT} for an italian keyboard.
+\item [\textbf{Return value:}] the keyboard map identifier effectively applied.
+\end{description}
+
+\begin{intest}
+KEYB\_GET\_MAP\index{keyb\_get\_map()}
+\end{intest}
+\begin{description}
+\item [\texttt{int}]\texttt{keyb\_get\_map(void);}
+\item [\textbf{Description:}] Return the identifier of the keyboard map actually
+in use.
+\end{description}
+
+\begin{intest}
+KEY\_EVT\index{KEY\_EVT, structure}
+\end{intest}
+
+\begin{description}
+\item [\textbf{Description:}] it is a data structure containing the following
+fields:
+
+\begin{description}
+\item [ascii:]ascii code of the key;
+\item [scan:]scan code of the key;
+\item [status:]the key can be pressed, repeated or released. When used to set an
+hook more than one status can be selected. The \texttt{status} field can be
+accessed by one of the following macros, whose usage is self-explaining:
+
+\begin{itemize}
+\item isPressed(\&k)
+\item isRepeated(\&k)
+\item isReleased(\&k)
+\end{itemize}
+
+\item [flag:]codes of the ALT, SHIFT and CTRL keys. \\
+The \texttt{flag} field can be accessed by one of the following macros, whose
+usage is self-explaining:
+
+\begin{itemize}
+\item isScanCode(\&k), decides whether the hit key has an ASCII code or not;
+\item isLeftShift(\&k)
+\item isRightShift(\&k)
+\item isLeftAlt(\&k)
+\item isRightAlt(\&k)
+\item isLeftCtrl(\&k)
+\item isRightCtrl(\&k)
+\end{itemize}
+\end{description}
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{The mouse library}
+%----------------------------------------------------------------------------
+
+To use the mouse into an application program, the user must call the
+\texttt{MOUSE26\_init} function. Then, all mouse functions are available until a
+call to the \texttt{MOUSE26\_close} function. The initialization of the mouse
+library is performed by \texttt{MOUSE26\_init}, which requires a parameter of
+\texttt{MOUSE\_PARMS} type to initialize the mouse. The following example shows
+a possible mouse initialization:
+
+\begin{verbatim}
+int main(int argc,char *argv[]) {
+ int result;
+ MOUSE_PARMS params = BASE_MOUSE;
+
+ result = MOUSE26_init(&params);
+ if (result!=0) {
+ // the mouse can't be initialized
+ }
+ // other mouse functions
+ MOUSE26_close();
+}
+\end{verbatim}
+
+The \texttt{MOUSE26\_close} function is not required but can be used to release
+all the hardware resources that the library acquires. The NULL constant can be
+passed to the \texttt{MOUSE26\_init()} function for a default initialization.
+The \texttt{params} variable can be used to change the default setting of the
+initialization procedure using some macros, whose names start with
+\texttt{mouse\_def\_}. All the mouse functions can be found in the include file
+\texttt{drivers/shark\_mouse26.h}.
+
+\vspace{7mm}
+
+\begin{intest}
+MOUSE26\_INIT\index{MOUSE26\_init()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int}]\texttt{MOUSE26\_init(KEYB\_PARMS
+{*}parms);}
+\item [\textbf{Description:}] It initializes the mouse interface and the
+library's internal data structures. It can be called using NULL as
+\texttt{parms} to initialize the mouse interface to default values.
+\item [\textbf{Return value:}] 0 if the operation is performed successfully; a
+value less than 0, otherwise.
+\end{description}
+\begin{intest}
+MOUSE26\_CLOSE\index{MOUSE26\_close()}
+\end{intest}
+\begin{description}
+\item [\texttt{int}]\texttt{MOUSE26\_close(void);}
+\item [\textbf{Description:}] It
+close
+the
+mouse
+interface.
+\item [\textbf{Return value:}]
+0
+if
+the
+operation
+is
+performed
+successfully;
+-1
+if
+the
+mouse
+in
+not
+installed.
+\end{description}
+\begin{intest}
+MOUSE26\_INSTALLED\index{MOUSE26\_installed()}
+\end{intest}
+\begin{description}
+\item [\texttt{int}]\texttt{MOUSE26\_installed(void);}
+\item [\textbf{Description:}] Return
+if
+the
+mouse
+driver
+is
+actually
+installed.
+\item [\textbf{Return value:}]
+0
+if
+the
+mouse
+is
+installed;
+1
+otherwise.
+\end{description}
+\begin{intest}
+MOUSE\_DEFAULT\_PARM\index{mouse\_default\_parm()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_default\_parm(KEYB\_PARMS
+parms);}
+\item [\textbf{Description:}] It
+changes
+the
+values
+of
+parms
+to
+the
+same
+vales
+as
+the
+BASE\_MOUSE
+default
+initializer.
+\end{description}
+\begin{intest}
+MOUSE\_DEF\_THRESHOLD\index{mousedef\_def\_threshold()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_def\_threshold(MOUSE\_PARMS
+parms,
+int
+thr);}
+\item [\textbf{Description:}] It
+changes
+the
+default
+threshold
+(i.e.,
+the
+mouse
+sensitivity)
+value
+used
+in
+the
+mouse
+driver.
+Is
+a
+scaling
+factor
+between
+the
+hardware
+position
+increment
+and
+the
+logical
+increment
+in
+the
+mouse
+position.
+The
+higher
+the
+value,
+the
+lower
+the
+sensitivity.
+The
+default
+is
+10.
+\end{description}
+\begin{intest}
+MOUSE\_DEF\_X0,
+MOUSE\_DEF\_Y0,
+MOUSE\_DEF\_Z0\index{mousedef\_def\_x0()} \index{mousedef\_def\_y0()}
+\index{mousedef\_def\_z0()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_def\_x0(MOUSE\_PARMS
+parms,
+int
+xvalue);}
+\item [\texttt{void}]\texttt{mouse\_def\_y0(MOUSE\_PARMS
+parms,
+int
+yvalue);}
+\item [\texttt{void}]\texttt{mouse\_def\_z0(MOUSE\_PARMS
+parms,
+int
+zvalue);}
+\item [\textbf{Description:}] These
+functions
+change
+the
+initial
+value
+of
+the
+mouse
+position.
+The
+default
+vilue
+for
+each
+parameter
+is
+0
+if
+permitted
+by
+mouse
+position
+bounds.
+\end{description}
+\begin{intest}
+MOUSE\_DEF\_XMIN,
+MOUSE\_DEF\_XMAX\index{mousedef\_def\_xmin()} \index{mousedef\_def\_xmax()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_def\_xmin(MOUSE\_PARMS
+parms,
+int
+minvalue);}
+\item [\texttt{void}]\texttt{mouse\_def\_xmax(MOUSE\_PARMS
+parms,
+int
+maxvalue);}
+\item [\textbf{Description:}] It
+changes
+the
+minimum
+and
+maximum
+allowed
+value
+for
+the
+x
+coordinate.
+\end{description}
+\begin{intest}
+MOUSE\_DEF\_YMIN,
+MOUSE\_DEF\_YMAX\index{mousedef\_def\_ymin()} \index{mousedef\_def\_ymax()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_def\_ymin(MOUSE\_PARMS
+parms,
+int
+minvalue);}
+\item [\texttt{void}]\texttt{mouse\_def\_ymax(MOUSE\_PARMS
+parms,
+int
+maxvalue);}
+\item [\textbf{Description:}] It
+changes
+the
+minimum
+and
+maximum
+allowed
+value
+for
+the
+y
+coordinate.
+\end{description}
+\begin{intest}
+MOUSE\_DEF\_TASK\index{mouse\_def\_task()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_def\_task(MOUSE\_PARMS
+parms,
+TASK\_MODEL
+{*}
+m);}
+\item [\textbf{Description:}] This
+macro
+defines
+the
+parameters
+for
+the
+mouse
+handling
+task.
+The
+\texttt{TASK\_MODEL}
+{*}
+should
+be
+a
+valid
+pointer
+to
+a
+Task
+Model,
+or
+\texttt{MOUSE\_DEFAULT}
+if
+you
+want
+to
+specify
+the
+default
+behaviour.
+\\
+This
+macro
+should
+be
+used
+every
+time
+the
+default
+Task
+Model
+does
+not
+adapt
+well
+to
+the
+configuration
+of
+the
+scheduling
+modules
+registered
+in
+the
+system.
+\\
+The
+default
+Task
+Model
+is
+equivalent
+to
+this
+initialization:\\
+\texttt{soft\_task\_default\_model(base\_m);
+}~\\
+\texttt{soft\_task\_def\_wcet(base\_m,2000);
+}~\\
+\texttt{soft\_task\_def\_met(base\_m,500);
+}~\\
+\texttt{soft\_task\_def\_period(base\_m,8000);
+}~\\
+\texttt{soft\_task\_def\_system(base\_m);
+}~\\
+\texttt{soft\_task\_def\_nokill(base\_m);
+}~\\
+\texttt{soft\_task\_def\_aperiodic(base\_m);}
+\end{description}
+\begin{intest}
+MOUSE\_ENABLE\index{mouse\_enable()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_enable(void);}
+\item [\textbf{Description:}] Allow
+the
+driver
+to
+receive
+data
+from
+the
+hardware.
+\end{description}
+\begin{intest}
+MOUSE\_DISABLE\index{mouse\_disable()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_disable(void);}
+\item [\textbf{Description:}] This
+function
+disable
+the
+mouse;
+the
+driver
+stop
+to
+respond
+to
+the
+data
+arriving
+from
+the
+hardware.
+\end{description}
+\begin{intest}
+MOUSE\_SETPOSITION\index{mouse\_setstatus()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_setposition(int
+x,
+int
+y,
+int
+z);}
+\item [\textbf{Description:}] Set
+values
+for
+axes
+and
+wheel.
+Values
+for
+x
+and
+y
+axis
+are
+compared
+against
+bounds
+for
+the
+allowed
+zone.
+\end{description}
+\begin{intest}
+MOUSE\_GETPOSITION\index{mouse\_getstatus()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_getposition(int
+{*}x,
+int
+{*}y,
+int
+{*}z,
+unsigned
+long
+{*}buttons);}
+\item [\textbf{Description:}] Get
+values
+for
+axes,
+wheel
+and
+buttons.
+In
+the
+\texttt{buttons}
+variable
+each
+bit
+rappresent
+the
+status
+of
+a
+button.
+\end{description}
+\begin{intest}
+MOUSE\_SETLIMITS\index{mouse\_setlimits()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_setlimits(int
+xmin,
+int
+ymin,
+int
+xmax,
+int
+ymax);}
+\item [\textbf{Description:}] It
+changes
+the
+minimum
+and
+maximum
+allowed
+value
+for
+x
+and
+y
+coordinate.
+\end{description}
+\begin{intest}
+MOUSE\_GETLIMITS\index{mouse\_getlimits()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_getlimits(int
+{*}xmin,
+int
+{*}ymin,
+int
+{*}xmax,
+int
+{*}ymax);}
+\item [\textbf{Description:}] Allow
+to
+obtain
+the
+minimum
+and
+maximum
+permited
+value
+for
+x
+and
+y
+coordinate.
+\end{description}
+\begin{intest}
+MOUSE\_SETTHRESHOLD\index{mouse\_setthreshold()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_setthreshold(int
+th);}
+\item [\textbf{Description:}] It
+changes
+the
+threshold
+value
+used
+in
+the
+mouse
+driver.
+Is
+a
+scaling
+factor
+between
+the
+hardware
+position
+increment
+and
+the
+logical
+increment
+in
+the
+mouse
+position.
+The
+default
+is
+10.
+\end{description}
+\begin{intest}
+MOUSE\_GETTHRESHOLD\index{mouse\_getthreshold()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_getthreshold(int
+th);}
+\item [\textbf{Description:}] Return
+the
+threshold
+value
+used
+in
+the
+mouse
+driver.
+Is
+a
+scaling
+factor
+between
+the
+hardware
+position
+increment
+and
+the
+logical
+increment
+in
+the
+mouse
+position.
+The
+default
+is
+10.
+\end{description}
+\begin{intest}
+MOUSE\_HOOK\index{mouse\_hook()}
+\end{intest}
+\begin{description}
+\item [\texttt{void}]\texttt{mouse\_hook(MOUSE\_HANDLER
+hook);}
+\item [\textbf{Description:}] Whenever
+the
+driver
+receive
+data
+from
+the
+hardware
+the
+function
+\texttt{hook()}
+is
+invoked
+with
+a
+\texttt{MOUSE\_EVT}
+as
+parameter.
+To
+detach
+a
+previously
+defined
+hook
+with
+NULL
+as
+parameter.
+\end{description}
+
+\begin{intest}
+MOUSE\_EVT\index{MOUSE\_EVT, structure}
+\end{intest}
+
+\begin{description}
+\item [\textbf{Description:}] it is a data structure containing the following
+fields:
+
+\begin{description}
+\item [x,y,z:]actual mouse position;
+\item [dx,dy,dz:]increments from the last event;
+\item [buttons:]each bit in the parameter rappresent the status of one button of
+the mouse.
+\end{description}
+
+\item [The]following code shows an example of usage for the function
+\texttt{mouse\_hook} and the structure \texttt{MOUSE\_EVT}:
+\end{description}
+
+\begin{description}
+\item [Example:]
+\end{description}
+
+\begin{verbatim}
+#include <drivers/shark_mouse26.h>
+
+void hook_func(MOUSE_EVT *mevt) {
+ if (mevt->button & 0x1) {
+
+ /* The 1st button is pressed... */
+ ...
+ }
+ if ((mevt->dx > 10) || (mevt->dx > 10)) {
+
+ /* Increment on x or y axis major than 10... */
+ ...
+ }
+ if (mevt->dz > 0) {
+
+ /* Wheel position changed... */
+ ...
+}
+
+int main(int argc,char *argv[]) {
+
+ /* mouse hook initialization */
+
+ mouse_hook(hook_func);
+ ...
+}
+\end{verbatim}
+
+\begin{intest}
+ISLEFTBUTTON, ISCENTRALBUTTON, ISRIGHTBUTTON\index{isLeftButton()}
+\index{isCentralButton()} \index{isRightButton()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{isLeftButton(int button)}]
+\item [\textbf{isCentralButton(int button)}]
+\item [\textbf{isRightButton(int button)}]
+\item [\textbf{Description:}] These macros are used to test whether a specific
+mouse button is pressed.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{The mouse graphics functions}
+%----------------------------------------------------------------------------
+
+The system provide a set of function to quickly draw the mouse cursor both in
+text and graphic mode. For each mode we can find 2 functions. The first used to
+set the cursor shape and the second to enable/disable the cursor visualization.
+
+ATTENTION: In text mode the mouse position is taken considering characters,
+while in graphics values are pixels as mining.
+
+\vspace{7mm}
+
+\begin{intest}
+MOUSE\_TXTCURSOR,\index{mouse\_txtcursor()}MOUSE\_GRXCURSOR\index{
+mouse\_grxcursor()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void mouse\_txtcursor(int cmd);}]
+\item [\textbf{void mouse\_grxcursor(int cmd, int bpp);}]
+\item [\textbf{Description:}] This function enables/disables the
+textual/grafical autocursor features of the library; \texttt{cmd} can be:
+\texttt{DISABLE} (disable cursor), \texttt{ENABLE} (enable a cursor). The
+graphic version need and other parameter \texttt{bpp} which is depth of the
+screen in bytes. These commands can be composite with two flags:
+
+\begin{itemize}
+\item \texttt{AUTOOFF}: if a user mouse handler is called, then during this call
+the mouse is off (if you use a \texttt{mouse\_off()} you can hang the mouse
+task).
+\item \texttt{WITHOUTSEM}: the autocursor mouse functions are not protected by a
+semaphore (so tasks cannot be blocked, but garbage can be displayed).
+\end{itemize}
+
+\end{description}
+
+\begin{intest}
+MOUSE\_TXTSHAPE\index{mouse\_txtshape()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void mouse\_txtshape(DWORD shape);}]
+\item [\textbf{Description:}] This function defines the shape of the text
+cursor; ``shape'' is a DWORD that is used to display the cursor: the text
+character and attributes are taken from the text memory, these values are and-ed
+with the low word of \texttt{shape} and the result is XOR-ed with the high word
+of \texttt{shape}, the result is written into the text memory. For examples, the
+default mouse cursor shape is 0x7700ffff; the character and attribute that are
+taken from the the memory are and-ed with 0xffff, so they do not change, and
+then are xor-ed with 0x7700: the character is xor-ed with 0x00 and the attribute
+byte is xor-ed with 0x77; the character remains the same but the attribute byte
+is inverted; so the mouse cursor is displayed inverting the colors of the
+character (the attribute byte contains the character foreground and background
+color and is coded in the usually EGA/VGA mode; you can read a book about VGA
+display adapters to find more
+informations).
+\end{description}
+
+\begin{intest}
+MOUSE\_GRXSHAPE\index{mouse\_grxshape()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void mouse\_grxshape(BYTE {*}img, BYTE {*}mask, int bpp);}]
+\item [\textbf{Description:}] This function defines the shape of the graphical
+cursor; \texttt{img} is a pointer to an image of 16x16 that can be used with the
+\texttt{grx\_putimage()} function, or can be \texttt{NULL} (in this case a
+default cursor is used); before putting the image into the screen's memory, the
+image is and-ed with \texttt{mask}. The parameter \texttt{bpp} is depth of the
+screen in bytes.
+\item [Example:]
+
+\begin{tt}
+\begin{verbatim}
+/*
+ * the resolution is 640x480 with 2 BYTE for pixel
+ */
+
+/* WHITE,RED,GREEN and MAGENTA are defined into <cons.h>*/
+
+#define W rgb16(255, 255, 255)
+#define R rgb16(255, 0, 0)
+#define G rgb16( 0, 255, 0)
+#define M rbg16(255, 0, 255)
+
+/* mouse shape */
+
+WORD my_mouse_cursor[16 * 16] = {
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+ 0,W,W,W,W,0,0,0,0,0,0,W,W,W,W,0,
+ 0,W,M,0,0,0,0,0,0,0,0,0,0,M,W,0,
+ 0,W,0,M,0,0,0,0,0,0,0,0,M,0,W,0,
+ 0,W,0,0,M,0,0,0,0,0,0,M,0,0,W,0,
+ 0,0,0,0,0,M,0,0,0,0,M,0,0,0,0,0,
+ 0,0,0,0,0,0,G,G,G,G,0,0,0,0,0,0,
+ 0,0,0,0,0,0,G,0,0,G,0,0,0,0,0,0,
+ 0,0,0,0,0,0,G,0,0,G,0,0,0,0,0,0,
+ 0,0,0,0,0,0,G,0,0,G,0,0,0,0,0,0,
+ 0,0,0,0,0,0,G,G,G,G,0,0,0,0,0,0,
+ 0,0,0,0,0,0,M,M,M,M,0,0,0,0,0,0,
+ 0,0,0,0,0,0,M,M,M,M,0,0,0,0,0,0,
+ 0,0,0,0,0,M,M,M,M,M,M,0,0,0,0,0,
+ 0,0,0,0,M,M,M,M,M,M,M,M,0,0,0,0,
+ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+};
+
+/* mask for pixels (2 bytes in this case) */
+/* 0xffff means that the background image is used */
+/* 0x0000 means tha the background image is cleared */
+/* prior to draw the mouse cursor */
+
+#define F 0xffff
+#define B 0x0000
+
+/* mouse mask */
+WORD my_mouse_mask[16 * 16] = {
+ B,B,B,B,B,B,F,F,F,F,B,B,B,B,B,B,
+ B,0,0,0,0,B,F,F,F,F,B,0,0,0,0,B,
+ B,0,0,B,B,F,F,F,F,F,B,B,B,0,0,B,
+ B,0,B,0,B,F,F,F,F,F,F,B,0,B,0,B,
+ B,0,B,B,0,B,F,F,F,F,B,0,B,B,0,B,
+ B,B,B,F,B,0,B,B,B,B,0,B,F,B,B,B,
+ F,F,F,F,F,B,0,0,0,0,B,F,F,F,F,F,
+ F,F,F,F,F,B,0,B,B,0,B,F,F,F,F,F,
+ F,F,F,F,F,B,0,B,B,0,B,F,F,F,F,F,
+ F,F,F,F,F,B,0,B,B,0,B,F,F,F,F,F,
+ F,F,F,F,F,B,0,0,0,0,B,F,F,F,F,F,
+ F,F,F,F,F,B,0,0,0,0,B,F,F,F,F,F,
+ F,F,F,F,F,B,0,0,0,0,B,F,F,F,F,F,
+ F,F,F,F,B,0,0,0,0,0,0,B,F,F,F,F,
+ F,F,F,B,0,0,0,0,0,0,0,0,B,F,F,F,
+ F,F,F,B,B,B,B,B,B,B,B,B,B,F,F,F,
+};
+
+int main(int argc, char *argv[]) {
+ MOUSE_PARMS mouse = BASE_MOUSE;
+
+ /*
+ * mouse initialization
+ */
+ MOUSE26_init(&mouse);
+
+ /* a resolution of 640x480 is used */
+ mouse_setlimit(XMINLIMIT(640,480),
+ YMINLIMIT(640,480),
+ XMAXLIMIT(640,480),
+ YMAXLIMIT(640,480));
+
+ /* initial position */
+ mouse_setposition(320,280);
+
+ /* mouse threshold */
+ mouse_setthreshold(2);
+
+ /* my new mouse shape */
+ mouse_grxshape(my_mouse_cursor,my_mouse_mask, 2);
+
+ /* automatic graphics mouse cursor enabled */
+ mouse_grxcursor(ENABLE, 2);
+
+ /* mouse displayed into the screen */
+ mouse_on();
+ ...
+}
+\end{verbatim}
+\end{tt}
+
+\end{description}
+
+\begin{intest}
+MOUSE\_OFF, MOUSE\_ON \index{mouse\_off()}\index{mouse\_on()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void mouse\_off(void);}]
+\item [\textbf{void mouse\_on(void);}]
+\item [\textbf{Description:}] This functions disables and enables the display of
+the mouse cursor on the screen (the mouse events are handled).
+\item [\textbf{Warning:}]These functions must be called before/after calling any
+graphic function that modifies the screen.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{The joystick library}
+%----------------------------------------------------------------------------
+
+In order to use the gameport handling functions, the
+\texttt{drivers/shark\_joy26.h} header file, containing the interface functions'
+prototypes, has to be included in the application program.
+
+First of all, the joystick needs be initialized by the calling
+\texttt{JOY26\_init} primitive into the \texttt{\_\_init\_\_} function in the
+initialization file or in any other point of the application code.
+
+ATTENTION: The driver only work with gameport that emulate the ``old
+SoundBlaster'' gameport interface. Other kind of gameports will not be
+identified.
+
+\vspace{7mm}
+
+\begin{intest}
+JOY26\_INIT\index{JOY26\_init()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int JOY26\_init(void);}]
+\item [\textbf{Description:}] It initializes the joystick interface and the
+library's internal data structures.
+\item [\textbf{Return value:}] 0 if the operation is performed successfully; a
+value less than 0, otherwise.
+\end{description}
+
+\begin{intest}
+JOY26\_CLOSE\index{JOY26\_close()}
+\end{intest}
+\begin{description}
+\item [\texttt{int}]\texttt{MOUSE26\_close(void);}
+\item [\textbf{Description:}] It close the joystick interface.
+\item [\textbf{Return value:}] 0 if the operation is performed successfully; -1
+if the joystick in not installed.
+\end{description}
+
+\begin{intest}
+JOY26\_INSTALLED\index{JOY26\_installed()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int JOY26\_installed(void);}]
+\item [\textbf{Description:}] Return if the joystick driver is actually installed.
+\item [\textbf{Return value:}] 0 if the joystick is installed; 1 otherwise.
+\end{description}
+
+\begin{intest}
+JOY\_ENABLE\index{joy\_enable()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void joy\_enable(void);}]
+\item [\textbf{Description:}] Allow the driver to receive data from the hardware.
+\end{description}
+
+\begin{intest}
+JOY\_DISABLE\index{joy\_disable()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{void}]\texttt{joy\_disable(void);}
+\item [\textbf{Description:}] Throw away the data arriving from the hardware
+instead of processing them inside the driver.
+\end{description}
+
+\begin{intest}
+JOY\_SETSTATUS\index{joy\_setstatus()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void joy\_setstatus(int axe0, int axe1, int axe2, int axe3, int buttons);}]
+\item [\textbf{Description:}] Set values for axes and buttons. Usually
+\texttt{axe0} and \texttt{axe1} are x and y axis for the first joystick while
+\texttt{axe2} and \texttt{axe3} are x and y axis for the second one. In the
+\texttt{buttons} parameter each bit rapresents the status of one button.
+\end{description}
+
+\begin{intest}
+JOY\_GETSTATUS\index{joy\_getstatus()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void joy\_getstatus(int {*}axe0, int {*}axe1, int {*}axe2, int {*}axe3, int {*}buttons);}]
+\item [\textbf{Description:}] Get values for axes and buttons. Usually
+\texttt{axe0} and \texttt{axe1} are x and y axis for the first joystick while
+\texttt{axe2} and \texttt{axe3} are x and y axis for the second one. In the
+\texttt{buttons} parameter each bit rappresent the status of one button.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{The speaker library}
+%----------------------------------------------------------------------------
+
+The system provide a driver to use the internal PC speaker. It can play a note
+at a given frequency for a predefined period or in a endless loop. In order to
+use the speaker handling functions, the \texttt{drivers/shark\_spk26.h} header
+file, containing the interface functions' prototypes, has to be included in the
+application program.
+
+First of all, the mouse needs be initialized by the calling
+\texttt{SPEAK26\_init} primitive into the \texttt{\_\_init\_\_} function in the
+initialization file or in any other point of the application code and the input
+low level driver must be already installed.
+
+\vspace{7mm}
+
+\begin{intest}
+SPEAK26\_INIT\index{SPEAK26\_init()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int SPEAK26\_init(void);}]
+\item [\textbf{Description:}] It initializes the speaker interface and the
+library's internal data structures.
+\item [\textbf{Return value:}] 0 if the operation is performed successfully; a
+value less than 0, otherwise.
+\end{description}
+
+\begin{intest}
+SPEAK26\_CLOSE\index{SPEAK26\_close()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int SPEAK26\_close(void);}]
+\item [\textbf{Description:}] It close the speaker interface.
+\item [\textbf{Return value:}] 0 if the operation is performed successfully; -1
+if the speaker in not installed.
+\end{description}
+
+\begin{intest}
+SPEAK26\_INSTALLED\index{SPEAK26\_installed()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int SPEAK26\_installed(void);}]
+\item [\textbf{Description:}] Return if the speaker driver is actually installed.
+\item [\textbf{Return value:}] 0 if the speaker is installed; 1 otherwise.
+\end{description}
+
+\begin{intest}
+SPEAKER\_SOUND\index{speaker\_sound()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void speaker\_sound(unsigned int hz, unsigned int ticks);}]
+\item [\textbf{Description:}] Generate a note at a frequency given using the
+parameter \texttt{hz}. The parameter \texttt{ticks} is the duration of the note;
+if set to 0 the note is repeated in an endless loop.
+\end{description}
+
+\begin{intest}
+SPEAKER\_MUTE\index{speaker\_mute()}
+\end{intest}
+
+\begin{description}
+\item [\texttt{int}]\texttt{speaker\_mute(void);}
+\item [\textbf{Description:}] Reset the internal speaker making it silent.
+\end{description}
+
/branches/new_sharkdoc/vol2/input.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol2/file.tex
===================================================================
--- branches/new_sharkdoc/vol2/file.tex (nonexistent)
+++ branches/new_sharkdoc/vol2/file.tex (revision 1676)
@@ -0,0 +1,84 @@
+%----------------------------------------------------------------------------
+\chapter{The File Management}
+%----------------------------------------------------------------------------
+
+S.Ha.R.K. provides a built-in File System that currently supports Hard Disk
+Drivers and FAT16 partitions.
+
+If you are using the DOS eXtender X to run the application, you can use some
+callback to the DOS 0x21 interrupt, to write/read some bytes from the
+filesystem \footnote{These callbacks are useful when you don't have any
+partition that can be read by the filesystem... for example when running
+S.Ha.R.K. applications from a FAT32 filesystem!}. These functions directly
+interact with the underlying DOS, and can not be used when the system is in
+protected mode. In particular, you can only use these functions into the
+\_\_kernel\_register\_levels\_\_() function and in the RUNLEVEL\_AFTER\_EXIT
+exit functions.
+
+In the case of errors, a \texttt{NULL} or zero value is returned;
+\texttt{DOS\_ferror()} can be used to get the DOS error code; the header file
+\texttt{<ll/i386/x-dos.h>} must be included to use these functions. A running
+(we hope) well documented example can be foun in the \texttt{demos/dosfs}
+directory.
+
+\vspace{7mm}
+
+\begin{intest}
+DOS\_FOPEN\index{DOS\_fopen()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{DOS\_FILE {*}DOS\_fopen(char {*}name, char {*}mode);}]
+\item [\textbf{Description:}] It opens a file and returns a pointer to a file structure.
+The \texttt{name} parameter contains the name of the file to be opened. The
+\texttt{mode} parameter contains a string whose value can be one of the
+following constants: {}``r'' to read, {}``w'' to write, and {}``rw'' to read and
+write. In the case of error, \texttt{NULL} is returned; otherwise the returned
+value can be used as last parameter in the functions listed below.
+\end{description}
+
+\begin{intest}
+DOS\_FCLOSE\index{DOS\_fclose()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void DOS\_fclose(DOS\_FILE {*}f);}]
+\item [\textbf{Description:}] It closes the specified file and releases all allocated DOS
+resources.
+\end{description}
+
+\begin{intest}
+DOS\_FREAD\index{DOS\_fread()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{DWORD DOS\_fread(void {*}buf, DWORD size, DWORD num, DOS\_FILE {*}f);}]
+\item [\textbf{Description:}] It reads \texttt{num} objects of \texttt{size} bytes from
+file \texttt{f} and place them in a buffer pointed by \texttt{buf}. This
+function returns the actual number of bytes read from the file (it can be less
+than $num*size$ bytes). Zero is returned if an error occurs or
+\textit{end-of-file} is found.
+\end{description}
+
+\begin{intest}
+DOS\_FWRITE\index{DOS\_fwrite()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{DWORD DOS\_fwrite(void {*}buf,DWORD size,DWORD num,DOS\_FILE {*}f);}]
+\item [\textbf{Description:}] It writes \texttt{num} objects of \texttt{size} bytes into
+file \texttt{f}. Data are picked from the buffer pointed by \texttt{buf}. This
+function returns the actual number of bytes written (it can be less than
+$num*size$ bytes). Zero is returned if an error occurs.
+\end{description}
+
+\begin{intest}
+DOS\_ERROR\index{DOS\_error()}
+\end{intest}
+
+\begin{description}
+\item [\textbf{unsigned DOS\_error(void);}]
+\item [\textbf{Description:}] Returns the error code of the latest \texttt{DOS\_xxx}
+function.
+\end{description}
+
/branches/new_sharkdoc/vol2/file.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol3/intserver.tex
===================================================================
--- branches/new_sharkdoc/vol3/intserver.tex (nonexistent)
+++ branches/new_sharkdoc/vol3/intserver.tex (revision 1676)
@@ -0,0 +1,307 @@
+%----------------------------------------------------------------------------
+\subsection{Introduction}
+%----------------------------------------------------------------------------
+
+Low-level support of peripheral devices is one of the most
+demanding activities in a real-time system for control
+applications. In fact, the rapid development of new interface
+boards and the continuous upgrade of hardware platforms causes a
+tremendous effort at the operating system level for writing and
+testing low-level drivers for supporting the new hardware. The
+possibility of reusing legacy drivers in real-time systems would
+offer the great advantage of keeping the rate of changes with a
+small programming effort. Since typical legacy drivers are written
+to execute in a non-preemptive fashion, a suitable operating
+system mechanism is needed to protect real-time application tasks
+from unpredictable bursty interrupt requests.
+
+%----------------------------------------------------------------------------
+\subsection{Why do we need a new server technology ?}
+%----------------------------------------------------------------------------
+
+The rapid development of new interface boards and the continuous
+upgrade of hardware platforms causes a tremendous effort at the
+operating system level for writing and testing the low-level
+software to support new peripheral devices. The problem of device
+management is particularly significant in those embedded systems
+dedicated to control applications, where the number of I/O
+peripherals is usually large. In these systems, the code layer
+dedicated to device drivers is one of the most delicate
+components. The possibility of reusing legacy drivers in real-time
+systems would offer the great advantage of keeping the pace of
+changes with a small programming effort.
+
+One of the main problems of reusing legacy drivers in a real-time
+system, however, is that most interrupt handlers disable the
+interruption capability of the processor, executing long portions
+of code at the highest priority in a non-preemptive fashion. As a
+consequence, a bursty sequence of interrupts may introduce long
+blocking delays in application tasks, which would cause hard tasks
+to miss their deadlines and soft tasks to increase their response
+time. Under such an execution model for the interrupts, an
+off-line guarantee of real-time constraints could require the
+system to run with a very low utilization.
+
+Inside S.Ha.R.K. this is possible. The modules stack is instrinsically
+hierarchical and the idle time of the first kernel module becomes the
+execution time for the next one (\ref{f:intserver3}).
+
+\begin{figure}
+\centering
+\includegraphics[width=0.5\columnwidth]{images/int-server3}
+\caption{\small S.Ha.R.K. module stack}
+\label{f:intserver3}
+\end{figure}
+
+Splitting the scheduler, the server algorithm becomes system independent and,
+therefore, it makes it possible to transparently use FP and EDF scheduling
+algorithms.
+
+This approach also keeps the server algorithm simple, just to fit our
+requirements for the IRQ and timers handling, leaving the main scheduler out
+from this specific problem.
+
+%----------------------------------------------------------------------------
+\subsection{Server features}
+%----------------------------------------------------------------------------
+
+The server features are
+
+\begin{itemize}
+
+\item
+The handler is always executed in a non preemptive fashion, but
+the server limits its bandwidth consumption through a suitable
+budget management that allows guaranteeing the other real-time
+activities.
+
+\item
+A hierarchical scheduling approach \cite{Lip03} is employed
+to make the interrupt service mechanism independent of the
+scheduling policy, so that either fixed or dynamic priority
+assignments can be used for the application tasks.
+
+\item
+The server can be tuned to balance its responsiveness versus its
+bandwidth consumption.
+
+\item
+The mechanism can be efficiently implemented to reduce the extra
+overhead typically required in capacity-based servers to set the
+timers for the budget management.
+
+\item
+Finally, the context-switch overhead introduced by the interrupt
+requests can be easily taken into account in the guarantee test
+for the application tasks.
+
+\end{itemize}
+
+%------------------------------------------------------------------
+\subsection{Server description}
+\label{s:desc}
+%------------------------------------------------------------------
+
+The novel server mechanism proposed in this paper aims at
+executing interrupt requests coming from complex legacy drivers
+imported into a real-time kernel from widely available open source
+operating systems. Since a device driver may be imported as it is,
+with very few or even without modifications, it is important to
+provide a method to safely schedule the requests without
+jeopardizing the internal driver temporization, keeping the
+developer away from the low-level details of the driver
+implementation and saving a lot of programming efforts. To achieve
+this goal, the interrupt service routines are always executed in a
+non preemptive fashion, but a budget management mechanism is used
+in the server to protect the application tasks from unbounded
+interference, in the case of long bursty interrupt requests.
+As a consequence of such a budget management mechanism, an ISR can
+experience a bounded activation delay, which can be tuned through
+the server parameters to balance application predictability vs.
+interrupt responsiveness.
+
+The server is defined by 3 parameters: a maximum budget $Q_{max}$,
+a bandwidth $U$, and a budget threshold $Q_\theta$. The server
+also keeps two state variables: its current budget $Q(t) \leq
+Q_{max}$ and an activity state $\Phi(t)$, which can have three
+values:
+
+\begin{itemize}
+
+\item
+$exe$. The server is in this state when it executes an ISR;
+
+\item
+$ready$. The server is ready when there are no pending interrupt
+requests and a new incoming request can be executed immediately
+without any activation delay;
+
+\item
+$idle$. The server is idle when a new request cannot be immediately
+executed because the previous requests consumed the available budget
+below the threshold $Q_\theta$. In this state, the budget is
+recharged
+according to a given replenishment rule, until the maximum level
+$Q_{max}$ is reached or a new request arrives.
+
+\end{itemize}
+
+The maximum budget ($Q_{max}$) is the upper bound for the current
+budget and limits the number of ISRs that can be consecutively
+executed by the server. The budget $Q(t)$ is decreased while an
+ISR is executing to keep track of the remaining budget that can be
+allocated to other requests. To prevent any preemption of the
+server, the budget is allowed to be negative. When no request is
+executing, $Q(t)$ is recharged at a constant rate.
+
+The $U$ parameter specifies the percentage of processor allocated
+to the server, which leaves a bandwidth $1-U$ to the application
+tasks. The value of $U$ directly influences the server budget
+$Q(t)$, which increases at rate $U$ when the server is ready or
+idle, and decreases at rate $1-U$ when the server is executing.
+A higher value of $U$ makes the budget to decrease more slowly (see
+Section \ref{s:rules} for the detailed budget variation rules),
+thus allowing the execution of a higher number of ISRs before
+starting the recharge. On the contrary, decreasing the value of
+$U$ makes the budget to increase more slowly, thus letting more
+space for the application tasks.
+
+The budget threshold $Q_\theta$ ($0 \leq Q_\theta \leq Q_{max}$)
+defines the budget level above which the server can start
+executing pending requests after an idle period. In other words,
+when the budget is exhausted ($Q < 0$) a new request can only be
+started when the budget is replenished up to $Q_\theta$. However,
+if $Q > 0$ and the server is ready, an ISR can be executed even
+though $Q \leq Q_\theta$.
+
+Decreasing the value of $Q_\theta$ decreases the latency of the
+ISR, while increasing $Q_\theta$ decreases the overhead introduced
+by the server during IRQ bursts.
+
+While the server is $idle$, the ISRs that cannot be executed due to
+the bandwidth limitations are sent to a ready queue, which can be
+handled by an arbitrary discipline.
+Then, they are fetched from the queue when the processor can be
+safely assigned to the server, meaning that the execution of an
+interrupt service does not jeopardize the temporal requirements of
+the application tasks.
+
+Two examples of server execution are reported in Figure
+\ref{f:budget} to better illustrate the budget management
+mechanism and the server state transitions.
+
+\begin{figure}
+\centering
+\includegraphics[width=\columnwidth]{images/budget1}
+\includegraphics[width=\columnwidth]{images/budget2}
+\caption{Examples of server budget behavior.}
+\label{f:budget}
+\end{figure}
+
+%------------------------------------------------------------------
+\subsection{Server rules}
+\label{s:rules}
+%------------------------------------------------------------------
+
+This section presents the rules that regulate the variation of the
+budget and the state transitions.
+
+Budget consumption and recharging is regulated by the following
+rules:
+
+\begin{enumerate}
+
+\item
+At the system start-up $\Phi(0) = idle$ and the initial budget is
+set to $0$, i.e., $Q(0) = 0$.
+
+\item
+While $\Phi=idle$ or $\Phi=ready$, the budget increases at a
+constant rate $U$ up to its maximum value. If $Q(t_1)$ is the
+budget at time $t_1 < t_2$, then
+
+\begin{equation}
+\label{equ:inc}
+Q(t_2) = \min \{Q_{max}, \; Q(t_1) + (t_2 - t_1)U\}.
+\end{equation}
+
+\item
+While $\Phi=exe$, the budget decreases at a constant rate equals
+to $1-U$. If $Q(t_1)$ is the budget at time $t_1 < t_2$, then
+\begin{equation}
+\label{equ:dec}
+Q(t_2) = Q(t_1) - (t_2 - t_1)(1 - U).
+\end{equation}
+
+\end{enumerate}
+
+The activity status of the server is determined by the current
+available budget, by the previous server status and by the presence
+or absence of pending ISRs into the ready queue. The status
+switches accordingly with the following rules:
+
+\begin{itemize}
+
+\item
+The initial state of the server is $idle$;
+
+\item
+When an IRQ arrives, if $\Phi$ is $exe$ or $idle$ the ISR is sent to
+the ready queue and the server maintains its current state;
+
+\item
+When an IRQ arrives, if $\Phi=ready$ the server starts executing the
+handler and $\Phi=exe$;
+
+\item
+When an interrupt handler terminates the execution, if $Q(t) < 0$
+$\Phi$ switches from $exe$ to $idle$; if $Q(t) \geq 0$ and the
+ready queue is empty, the server switches to $ready$, otherwise,
+if an ISR is waiting in the queue, the server keeps the $exe$ state
+and starts executing the next ISR;
+
+\item
+When $Q(t)$ increases $\Phi$ can only be $idle$ or $ready$. If $\Phi
+= idle$, when $Q(t)$ reaches $Q_\theta$ and the ready queue is
+empty,
+the server switches to $ready$; if the queue is not
+empty it switches to $exe$ and starts executing the first pending
+request. If $\Phi = ready$, when $Q(t)$ reaches $Q_\theta$
+the server keeps its current status and keeps recharging up to
+$Q_{max}$ if there are no IRQs to execute.
+
+\end{itemize}
+
+\begin{figure}
+\centering
+\includegraphics[width=\columnwidth]{images/fsm}
+\caption{Server finite-states machine.}
+\label{f:fsm}
+\end{figure}
+
+These rules are illustrated in Figure~\ref{f:fsm} as a finite-state
+machine.
+
+%------------------------------------------------------------------
+\subsection{Server Properties}
+\label{s:prop}
+%------------------------------------------------------------------
+
+The proposed interrupt server is characterized by the following
+interesting properties:
+
+\begin{itemize}
+
+\item
+the response time of every single ISR can be predicted in order to
+perform an online guarantee of incoming requests;
+
+\item
+the implementation overhead can be traded for the ISR latency by
+acting on the budget threshold $Q_\theta$;
+
+\item
+the server parameters can be directly used to specify the bandwidth
+allocation within a hierarchical framework.
+
+\end{itemize}
\ No newline at end of file
/branches/new_sharkdoc/vol3/intserver.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol3/vol3.tex
===================================================================
--- branches/new_sharkdoc/vol3/vol3.tex (nonexistent)
+++ branches/new_sharkdoc/vol3/vol3.tex (revision 1676)
@@ -0,0 +1,2850 @@
+\documentclass[english]{report}
+\usepackage[T1]{fontenc}
+\usepackage[latin1]{inputenc}
+\usepackage{geometry}
+\geometry{verbose,a4paper}
+\usepackage{array}
+\usepackage{makeidx}
+\makeindex
+\usepackage{graphicx}
+
+\makeatletter
+
+\usepackage{babel}
+
+\newenvironment{intest}{\noindent\large\bf\hspace*{1pt}}
+{\vspace*{-5pt}\\\line(1,0){433}}
+
+\makeatother
+
+\begin{document}
+
+\thispagestyle{empty}
+
+\begin{center}{\LARGE S.Ha.R.K. User Manual}\end{center}{\LARGE \par} \vfill{}
+
+\begin{center}{\large Volume III}\end{center}
+
+\begin{center}
+S.Ha.R.K. Modules
+\end{center}
+\vfill{}
+
+\begin{center}Written by\end{center}
+
+\begin{center}Giorgio Buttazzo (giorgio at sssup.it)\end{center}
+\begin{center}Paolo Gai (pj at sssup.it)\end{center}
+\begin{center}Luigi Palopoli (luigi at hartik.sssup.it)\end{center}
+\begin{center}Marco Caccamo (caccamo at sssup.it)\end{center}
+\begin{center}Giuseppe Lipari (lipari at sssup.it) \end{center}
+\begin{center}Tullio Facchinetti (tullio.facchinetti at unipv.it) \end{center}
+\vfill{}
+
+\begin{center}\includegraphics[width=2cm]{../common/sssup.ps}\end{center}
+
+\begin{center}
+Scuola Superiore di Studi e Perfezionamento S. Anna
+\end{center}
+
+\begin{center}RETIS Lab\end{center}
+\begin{center}Via Carducci, 40 - 56100 Pisa\end{center}
+\pagebreak
+
+\tableofcontents{}
+
+\begin{abstract}
+The S.Ha.R.K. kernel provides a way to implement in a simple
+way a lot of scheduling algorithms that have been proposed by the
+Real-Time literature. This Volume simply contains a simple
+description on which modules are available and how these modules
+can be used. Moreover, to help the implementation of new modules,
+a small description of the tricks used in the implementation is
+also given.
+\end{abstract}
+
+%----------------------------------------------------------------------------
+\chapter{Models}
+%----------------------------------------------------------------------------
+
+Task Models and Resource Models are the structures used by the
+S.Ha.R.K. Kernel to isolate the scheduling parameter needed by the
+various Scheduling Modules and Resource Modules.
+
+To simplify the use of the Models, the Kernel provides a set of
+macros that can be used to fill their various fields. In the
+following paragraphs, the various models are described in detail.
+All the Model definitions of this chapter can be found in the file
+\texttt{include/kernel/model.h}.
+
+Examples of Models initializations can be found in various
+examples through this Volume.
+
+%----------------------------------------------------------------------------
+\section{HARD\_TASK\_MODEL}
+%----------------------------------------------------------------------------
+
+\begin{tt}
+\begin{verbatim}
+typedef struct {
+ TASK_MODEL t;
+ TIME mit;
+ TIME drel;
+ TIME wcet;
+ int periodicity;
+} HARD_TASK_MODEL;
+\end{verbatim}
+\end{tt}
+
+A Hard Task model can be used to model periodic and sporadic
+tasks. These tasks are usually guaranteed basing on their minimum
+interarrival time (mit) and wcet, and may have a relative
+deadline.
+
+Table \ref{tab:HARD_TASK_MODEL_Macros} shows the macros that
+applies to a \texttt{HARD\_TASK\_MODEL}.
+
+\begin{table}
+\begin{tabular}{|l|p{8cm}|}
+\hline Macro name & Behaviour \\ \hline
+
+hard\_task\_default\_model(m) & Default values for the Model
+(periodic task, others = 0) \\ \hline
+
+hard\_task\_def\_level(m,l) & Set the Model level to l. A Module
+registered at level x can accept a Model only if it has level 0 or
+x. The default value is 0. \\ \hline
+
+hard\_task\_def\_arg(m,a) & Set the void * argument passed to
+the task the first time it is activated. The default value is
+NULL.\\ \hline
+
+hard\_task\_def\_stack(m,s) & Set the task stack size. The default
+value is 4096.\\ \hline
+
+hard\_task\_def\_stackaddr(m,s) & If the stack is statically
+allocated you can tell its address here. The default is NULL (no
+pre-allocated stack).\\ \hline
+
+hard\_task\_def\_group(m,g) & Set the task group to g. Task
+grouping influences primitives like group\_activate() or
+group\_kill()\\ \hline
+
+hard\_task\_def\_usemath(m) & Declare that the task uses floating
+point arithmetic.\\ \hline
+
+hard\_task\_def\_system(m) & Declare that the task is a system
+task. System tasks behaves differently at shutdown. See the
+Architecture manual for details.\\ \hline
+
+hard\_task\_def\_nokill(m) & Declare that the task can not be
+killed. These tasks behaves differently at shutdown. See the
+Architecture manual for details.\\ \hline
+
+hard\_task\_def\_ctrl\_jet(m) & If called, the Kernel must store
+JET informations for the task.\\ \hline
+
+hard\_task\_def\_mit(m,p) & Set the Minimum Interarrival Time
+(MIT) of the Model to p.\\ \hline
+
+hard\_task\_def\_drel(m,d) & Set the relative deadline to
+d.\\ \hline
+
+hard\_task\_def\_wcet(m,w) & Set the Worst Case Execution Time to
+w.\\ \hline
+
+hard\_task\_def\_periodic(m) & Declare that the task is
+Periodic.\\ \hline
+
+hard\_task\_def\_aperiodic(m) & Declare that the task is Sporadic
+(Aperiodic).\\ \hline
+
+hard\_task\_def\_joinable(m) & Declare that the task is joinable
+with task\_join()/pthread\_join().\\ \hline
+
+hard\_task\_def\_unjoinable(m) & Declare that the task is not
+joinable (is detached) with
+task\_join()/pthread\_join().\\ \hline
+
+hard\_task\_def\_trace(m) & Declare that the task has to be traced
+by the Tracer.\\ \hline
+
+hard\_task\_def\_notrace(m) & Declare that the task has not to be
+traced by the Tracer.\\ \hline
+\end{tabular}
+\caption{HARD\_TASK\_MODEL Macros}
+\label{tab:HARD_TASK_MODEL_Macros}
+\end{table}
+
+%----------------------------------------------------------------------------
+\section{SOFT\_TASK\_MODEL}
+%----------------------------------------------------------------------------
+
+\begin{tt}
+\begin{verbatim}
+typedef struct {
+ TASK_MODEL t;
+ TIME period;
+ TIME met;
+ TIME wcet;
+ int periodicity;
+ int arrivals;
+} SOFT_TASK_MODEL;
+\end{verbatim}
+\end{tt}
+
+A Soft Task model can be used to model periodic and aperiodic
+tasks usually not guaranteed or guaranteed basing on their period
+and mean execution time (met). A Soft task can also record pending
+activations if the arrivals are set to SAVE\_ACTIVATIONS. A wcet
+field is also present for those servers that need it (i.e., TBS).
+
+Table \ref{tab:SOFT_TASK_MODEL_Macros} shows the macros that
+applies to a \texttt{SOFT\_TASK\_MODEL}.
+
+\begin{table}
+\begin{tabular}{|l|p{8cm}|}
+\hline Macro name & Behaviour\\ \hline
+
+soft\_task\_default\_model(m) & Default values for the Model
+(periodic task, save arrivals, others = 0).\\ \hline
+
+soft\_task\_def\_level(m,l) & Set the Model level to l. A Module
+registered at level x can accept a Model only if it has level 0 or
+x. The default value is 0.\\ \hline
+
+soft\_task\_def\_arg(m,a) & Set the void * argument passed to
+the task the first time it is activated. The default value is
+NULL.\\ \hline
+
+soft\_task\_def\_stack(m,s) & Set the task stack size. The default
+value is 4096.\\ \hline
+
+soft\_task\_def\_stackaddr(m,s) & If the stack is statically
+allocated you can tell its address here. The default is NULL (no
+pre-allocated stack).\\ \hline
+
+soft\_task\_def\_group(m,g) & Set the task group to g. Task
+grouping influences primitives like group\_activate() or
+group\_kill()\\ \hline
+
+soft\_task\_def\_usemath(m) & Declare that the task uses floating
+point arithmetic.\\ \hline
+
+soft\_task\_def\_system(m) & Declare that the task is a system
+task. System tasks behaves differently at shutdown. See the
+Architecture manual for details.\\ \hline
+
+soft\_task\_def\_nokill(m) & Declare that the task can not be
+killed. These tasks behaves differently at shutdown. See the
+Architecture manual for details.\\ \hline
+
+soft\_task\_def\_ctrl\_jet(m) & If called, the Kernel must store
+JET informations for the task.\\ \hline
+
+soft\_task\_def\_period(m,p) & Set the task period to
+p.\\ \hline
+
+soft\_task\_def\_met(m,d) & Set the task Mean Execution Time (MET)
+to d.\\ \hline
+
+soft\_task\_def\_wcet(m,w) & Set the Worst Case Execution Time to
+w.\\ \hline
+
+soft\_task\_def\_periodic(m) & Declare that the task is
+Periodic.\\ \hline
+
+soft\_task\_def\_aperiodic(m) & Declare that the task is Sporadic
+(Aperiodic).\\ \hline
+
+soft\_task\_def\_joinable(m) & Declare that the task is joinable
+with task\_join()/pthread\_join().\\ \hline
+
+soft\_task\_def\_unjoinable(m) & Declare that the task is not
+joinable (is detached) with
+task\_join()/pthread\_join().\\ \hline
+
+soft\_task\_def\_trace(m) & Declare that the task has to be traced
+by the Tracer.\\ \hline
+
+soft\_task\_def\_notrace(m) & Declare that the task has not to be
+traced by the Tracer.\\ \hline
+
+soft\_task\_def\_save\_arrivals(m) & The task will save a pending
+activation if it arrives when the task is already
+active.\\ \hline
+
+soft\_task\_def\_skip\_arrivals(m) & The task will ignore a
+pending activation if it arrives when the task is already
+active.\\ \hline
+\end{tabular}
+\caption{SOFT\_TASK\_MODEL Macros}
+\label{tab:SOFT_TASK_MODEL_Macros}
+\end{table}
+
+\pagebreak
+
+%----------------------------------------------------------------------------
+\section{NRT\_TASK\_MODEL}
+%----------------------------------------------------------------------------
+
+\begin{tt}
+\begin{verbatim}
+typedef struct {
+ TASK_MODEL t;
+ int weight;
+ TIME slice;
+ int arrivals;
+ int policy;
+ int inherit;
+} NRT_TASK_MODEL;
+\end{verbatim}
+\end{tt}
+
+A NRT task has a weight and a time slice, plus a policy attribute.
+It can be used to model Round Robin, Proportional Share, POSIX,
+and Priority tasks.
+
+Note that policy and inherit are inserted in the model to support
+POSIX compliant scheduling without adding another Task Model;
+weight can be used to contain the fixed priority of a task; slice
+can be used to contain the RR slice of the task.
+
+Table \ref{tab:NRT_TASK_MODEL_Macros} shows the macros that
+applies to a \texttt{NRT\_TASK\_MODEL}.
+
+\begin{table}
+\begin{tabular}{|c|p{8cm}|}
+\hline Macro name & Behaviour\\ \hline
+
+nrt\_task\_default\_model(m) & Default values for the Model (save
+arrivals, NRT\_RR\_POLICY, NRT\_EXPLICIT\_SCHED, others =
+0).\\ \hline
+
+nrt\_task\_def\_level(m,l) & Set the Model level to l. A Module
+registered at level x can accept a Model only if it has level 0 or
+x. The default value is 0.\\ \hline
+
+nrt\_task\_def\_arg(m,a) & Set the void * argument passed to the
+task the first time it is activated. The default value is
+NULL.\\ \hline
+
+nrt\_task\_def\_stack(m,s) & Set the task stack size. The default
+value is 4096.\\ \hline
+
+nrt\_task\_def\_stackaddr(m,s) & If the stack is statically
+allocated you can tell its address here. The default is NULL (no
+pre-allocated stack).\\ \hline
+
+nrt\_task\_def\_group(m,g) & Set the task group to g. Task
+grouping influences primitives like group\_activate() or
+group\_kill()\\ \hline
+
+nrt\_task\_def\_usemath(m) & Declare that the task uses floating
+point arithmetic.\\ \hline
+
+nrt\_task\_def\_system(m) & Declare that the task is a system
+task. System tasks behaves differently at shutdown. See the
+Architecture manual for details.\\ \hline
+
+nrt\_task\_def\_nokill(m) & Declare that the task can not be
+killed. These tasks behaves differently at shutdown. See the
+Architecture manual for details.\\ \hline
+
+nrt\_task\_def\_ctrl\_jet(m) & If called, the Kernel must store
+JET informations for the task.\\ \hline
+
+nrt\_task\_def\_weight(m,w) & Set the task weight to
+w.\\ \hline
+
+nrt\_task\_def\_slice(m,d) & Set the timeslice to
+d.\\ \hline
+
+nrt\_task\_def\_policy(m,p) & Set the policy of the task. p can be
+NRT\_RR\_POLICY or NRT\_FIFO\_POLICY. (used for POSIX
+scheduling)\\ \hline
+
+nrt\_task\_def\_inherit(m,i) & Tell if the task should inherit the
+same properties of the father. i can be NRT\_INHERIT\_SCHED or
+NRT\_EXPLICIT\_SCHED. (used for POSIX scheduling)\\
+\hline
+
+nrt\_task\_def\_joinable(m) & Declare that the task is joinable
+with task\_join()/pthread\_join().\\ \hline
+
+nrt\_task\_def\_unjoinable(m) & Declare that the task is not
+joinable (is detached) with
+task\_join()/pthread\_join().\\ \hline
+
+nrt\_task\_def\_trace(m) & Declare that the task has to be traced
+by the Tracer.\\ \hline
+
+nrt\_task\_def\_notrace(m) & Declare that the task has not to be
+traced by the Tracer.\\ \hline
+
+nrt\_task\_def\_save\_arrivals(m) & The task will save a pending
+activation if it arrives when the task is already
+active.\\ \hline
+
+nrt\_task\_def\_skip\_arrivals(m) & The task will ignore a pending
+activation if it arrives when the task is already
+active.\\ \hline
+\end{tabular}
+\caption{NRT\_TASK\_MODEL Macros}
+\label{tab:NRT_TASK_MODEL_Macros}
+\end{table}
+
+%----------------------------------------------------------------------------
+\section{JOB\_TASK\_MODEL}
+%----------------------------------------------------------------------------
+
+\begin{tt}
+\begin{verbatim}
+typedef struct {
+ TASK_MODEL t;
+ TIME period;
+ struct timespec deadline;
+ int noraiseexc;
+} JOB_TASK_MODEL;
+\end{verbatim}
+\end{tt}
+
+This model implements a Job with an optional period and a starting
+deadline (for the first activation). A Job task can raise a
+XDEADLINE\_MISS exception; if the flag noraiseexc is != 0, the
+exception is not raised.
+
+This model is normally used with aperiodic servers: the aperiodic
+server insert a guest task in another level with that model
+calling \texttt{guest\_create} and \texttt{guest\_activate}. When
+the task has to be removed, \texttt{guest\_end} is called.
+
+Note that there is no capacity control on this model. Note that
+the task that accept this task DOESN'T reactivate the task after a
+period... There is NOT a guest\_endcycle defined for this model...
+
+Table \ref{tab:JOB_TASK_MODEL_Macros} shows the macros that
+applies to a \texttt{JOB\_TASK\_MODEL}.
+
+\begin{table}
+\begin{tabular}{|l|p{8cm}|}
+\hline Macro name& Behaviour\\ \hline
+
+job\_task\_default\_model(m,dl) & Default values for the Model
+(period = 0, deadline = dl, noraiseexc = 0)\\ \hline
+
+job\_task\_def\_level(m,l) & Set the Model level to l. A Module
+registered at level x can accept a Model only if it has level 0 or
+x. The default value is 0.\\ \hline
+
+job\_task\_def\_arg(m,a) & Set the void * argument passed to the
+task the first time it is activated. The default value is
+NULL.\\ \hline
+
+job\_task\_def\_stack(m,s) & Set the task stack size. The default
+value is 4096.\\ \hline
+
+job\_task\_def\_stackaddr(m,s) & If the stack is statically
+allocated you can tell its address here. The default is NULL (no
+pre-allocated stack).\\ \hline
+
+job\_task\_def\_group(m,g) & Set the task group to g. Task
+grouping influences primitives like group\_activate() or
+group\_kill()\\ \hline
+
+job\_task\_def\_usemath(m) & Declare that the task uses floating
+point arithmetic.\\ \hline
+
+job\_task\_def\_system(m) & Declare that the task is a system
+task. System tasks behaves differently at shutdown. See the
+Architecture manual for details.\\ \hline
+
+job\_task\_def\_nokill(m) & Declare that the task can not be
+killed. These tasks behaves differently at shutdown. See the
+Architecture manual for details.\\ \hline
+
+job\_task\_def\_ctrl\_jet(m) & If called, the Kernel must store
+JET informations for the task.\\ \hline
+
+job\_task\_def\_period(m,p) & Set the period to p.\\ \hline
+
+job\_task\_def\_deadline(m,dl) & Set the deadline to
+dl.\\ \hline
+
+job\_task\_def\_noexc(m) & Set noraiseexc = 1.\\ \hline
+
+job\_task\_def\_yesexc(m) & Set noraiseexc = 1.\\ \hline
+
+job\_task\_def\_joinable(m) & Declare that the task is joinable
+with task\_join()/pthread\_join().\\ \hline
+
+job\_task\_def\_unjoinable(m) & Declare that the task is not joinable (is
+detached) with task\_join()/pthread\_join().\\ \hline
+
+job\_task\_def\_trace(m) & Declare that the task has to be traced
+by the Tracer.\\ \hline
+
+job\_task\_def\_notrace(m) & Declare that the task has not to be
+traced by the Tracer.\\ \hline
+\end{tabular}
+\caption{HARD\_TASK\_MODEL Macros}
+\label{tab:JOB_TASK_MODEL_Macros}
+\end{table}
+
+%----------------------------------------------------------------------------
+\section{BDEDF\_RES\_MODEL (BlockDevice EDF resource model)}
+%----------------------------------------------------------------------------
+
+TBD
+
+%----------------------------------------------------------------------------
+\section{BDPSCAN\_RES\_MODEL (Block Device PSCAN resource model)}
+%----------------------------------------------------------------------------
+
+TBD
+
+%----------------------------------------------------------------------------
+\section{PC\_RES\_MODEL (Priority Ceiling Resource Model)}
+%----------------------------------------------------------------------------
+
+\begin{tt}
+\begin{verbatim}
+typedef struct {
+ RES_MODEL r;
+ DWORD priority;
+} PC_RES_MODEL;
+\end{verbatim}
+\end{tt}
+
+This Resource Model signal to the Priority Ceiling (PC) Module
+that the task may use the PC protocol for some mutexes.
+
+Note that the PC Module consider the tasks created without using
+this resource models to have priority = MAX\_DWORD (the lowest).
+
+The macro that can be used to setup the Resource Model are the
+following:
+
+\texttt{PC\_res\_default\_model(res, prio) }
+
+Initializes a PC\_RES\_MODEL with a priority equal to prio.
+
+\texttt{PC\_res\_def\_level(res,l)}
+
+Set the Model level to l (in a way similar to what happens to task
+models).
+
+%----------------------------------------------------------------------------
+\section{SRP\_RES\_MODEL (Stack Resource Policy resource model)}
+%----------------------------------------------------------------------------
+
+\begin{tt}
+\begin{verbatim}
+typedef struct {
+ RES_MODEL r;
+ DWORD preempt;
+} SRP_RES_MODEL;
+\end{verbatim}
+\end{tt}
+
+This Resource Model signal to the Stack Resource Policy (PC)
+Module that the task will use the SRP protocol.
+
+Note that the SRP Module does not influence the schedule of any
+task that did not pass a SRP\_RES\_MODEL at its creation. The SRP
+Module uses another resource model that is embedded into the mutex
+structure. See \texttt{modules/srp/srp.c} for details.
+
+The macro that can be used to setup the Resource Model are the
+following:
+
+\texttt{SRP\_res\_default\_model(res, pre) }
+
+Initializes a SRP\_RES\_MODEL with a preemption level equal to
+prio.
+
+\texttt{SRP\_res\_def\_level(res,l)}
+
+Set the Model level to l (in a way similar to what happens to task
+models).
+
+%----------------------------------------------------------------------------
+\chapter{Mutex attributes}
+%----------------------------------------------------------------------------
+
+Every mutex attribute encode a particular mutex protocol, and one
+of them must be passed to the mutex\_init() primitive to specify
+the protocol used by a particular mutex. The following paragraphs
+describe in detail the mutex attributes. Their definitions can be
+found in \texttt{include/kernel/model.h}. Examples of use of mutex
+attributes can be found later in this document.
+
+%----------------------------------------------------------------------------
+\section{PI\_mutexattr\_t (Priority Inheritance Mutex Attribute)}
+%----------------------------------------------------------------------------
+
+\texttt{typedef mutexattr\_t PI\_mutexattr\_t;}
+
+The Priority Ceiling Mutex Attribute.
+
+You can initialize that attribute using the static initializer
+\texttt{PI\_MUTEXATTR\_INITIALIZER} or calling the macro
+
+\texttt{PI\_mutexattr\_default(a)}
+
+where a is the mutex attribute.
+
+%----------------------------------------------------------------------------
+\section{NPP\_mutexattr\_t (Non Preemptive Protocol Mutex Attribute)}
+%----------------------------------------------------------------------------
+
+\texttt{typedef mutexattr\_t NPP\_mutexattr\_t;}
+
+The Non Preemptive Protocol Mutex Attribute. You can initialize
+that attribute using the static initializer
+\texttt{NPP\_MUTEXATTR\_INITIALIZER} or calling the macro
+
+\texttt{NPP\_mutexattr\_default(a)}
+
+where a is the mutex attribute.
+
+%----------------------------------------------------------------------------
+\section{PC\_mutexattr\_t (Priority Ceiling Mutex Attribute)}
+%----------------------------------------------------------------------------
+
+\texttt{typedef struct \{ mutexattr\_t a; DWORD ceiling; \}
+PC\_mutexattr\_t;}
+
+The Priority Ceiling Mutex Attribute.
+
+You can initialize that attribute using the static initializer
+\texttt{PC\_MUTEXATTR\_INITIALIZER} or calling the macro
+
+\texttt{PC\_mutexattr\_default(at,c) }
+
+where at is the mutex attribute, and c is the ceiling of the
+mutex.
+
+%----------------------------------------------------------------------------
+\section{SRP\_mutexattr\_t (Stack Resource Policy Mutex Attribute)}
+%----------------------------------------------------------------------------
+
+\texttt{typedef mutexattr\_t SRP\_mutexattr\_t;}
+
+The Stack Resource Policy Mutex Attribute. You can initialize that
+attribute using the static initializer
+\texttt{SRP\_MUTEXATTR\_INITIALIZER} or calling the macro
+
+\texttt{SRP\_mutexattr\_default(a) }
+
+where at is the mutex attribute.
+
+%----------------------------------------------------------------------------
+\section{NOP\_mutexattr\_t (No Protocol Mutex Attribute)}
+%----------------------------------------------------------------------------
+
+\texttt{typedef mutexattr\_t NOP\_mutexattr\_t;}
+
+The No Protocol Mutex Attribute.
+
+You can initialize that attribute using the static initializer
+\texttt{NOP\_MUTEXATTR\_INITIALIZER} or calling the macro
+
+\texttt{NOP\_mutexattr\_default(a) }
+
+where at is the mutex attribute.
+
+%----------------------------------------------------------------------------
+\section{NOPM\_mutexattr\_t (No Protocol Multiple lock Mutex Attribute)}
+%----------------------------------------------------------------------------
+
+typedef mutexattr\_t NOPM\_mutexattr\_t;
+
+The No Protocol Multiple lock Mutex Attribute. You can initialize
+that attribute using the static initializer
+\texttt{NOPM\_MUTEXATTR\_INITIALIZER} or calling the macro
+
+\texttt{NOPM\_mutexattr\_default(a) }
+
+where at is the mutex attribute.
+
+%----------------------------------------------------------------------------
+\chapter{Scheduling algorithms}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\section{DUMMY}
+%----------------------------------------------------------------------------
+
+\paragraph{Task Models Accepted:}
+
+\begin{description}
+\item [DUMMY\_TASK\_MODEL]- This Model is used only at system
+startup to register the dummy task. It cannot be used by the other
+modules.
+\end{description}
+
+\paragraph{Description:}
+
+This Module implements a \texttt{dummy} task. A dummy task is a
+task like all the other task that simply does an infinite loop,
+does nothing inside.
+
+Why we need such a Module? Look at the Scheduling Module
+Architecture: when the Kernel needs to schedule a task, it asks to
+all the registered modules if they have a task to schedule. The
+hyphotesis is that there must be ALWAYS a task to schedule. The
+dummy Scheduling Modules is used to register a module that have
+always a task to schedule (the dummy task).
+
+The dummy Module is not needed if you can ensure that there will
+always be a task to schedule.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XUNVALID\_GUEST]This level doesn't support guests. When a
+guest operation is called, the exception is raised. \item
+[XUNVALID\_DUMMY\_OP]The dummy task can't be created, or
+activated, or another (strange) problem occurred.
+\end{description}
+
+\paragraph{Usage:}
+
+Usually the Dummy Module is the LAST scheduling module registered
+in the function
+
+\texttt{\_\_kernel\_register\_levels\_\_}.
+
+Just insert the following line into
+\texttt{\_\_kernel\_register\_levels\_\_} to register the Module:
+
+\texttt{dummy\_register\_level();}
+
+If you have a CPU where the HLT instruction works, you can use the
+define \texttt{\_\_HLT\_WORKS\_\_}. If that \texttt{\#define} is
+defined, the idle loop of the \texttt{dummy} task will use
+\texttt{HLT}, maybe saving power.
+
+\paragraph{Files:}
+
+\texttt{modules/dummy/*}
+
+\paragraph{Implementation hints:}
+
+You can look at the code to learn how to create a new task at
+startup using a \texttt{RUNLEVEL\_INIT} function.
+
+%----------------------------------------------------------------------------
+\section{IntDrive Interrupt Server}
+%----------------------------------------------------------------------------
+
+\input{intserver.tex}
+
+\paragraph{Files:}
+
+\texttt{modules/intdrive/*}
+
+%----------------------------------------------------------------------------
+\subsection{Implementation}
+%----------------------------------------------------------------------------
+
+\begin{intest}
+INTDRIVE\_register\_level \index{INTDRIVE\_register\_level}
+\end{intest}
+
+\begin{description}
+\item [\textbf{LEVEL INTDRIVE\_register\_level(TIME capacity, TIME q\_theta, int
+U, int flags);}]
+\item [\textbf{Description:}]This function registers the IntDrive module at
+initialization time. This model should be usually registered as the first module
+in the \texttt{\_\_kernel\_register\_levels\_\_} function.
+\item [\textbf{Parameters:}]~
+
+\begin{itemize}
+\item \textbf{capacity}: the server capacity;
+\item \textbf{q\_theta}: the server threshold;
+\item \textbf{U}: the maximum bandwidth consumed by the server;
+\item \textbf{flags}: a set of configuration options. Supported values are:
+
+\begin{itemize}
+\item \textbf{INTDRIVE\_CHECK\_WCET}: when a WCET overrun occurs, an exception
+is raised.
+\end{itemize}
+
+\end{itemize}
+
+\end{description}
+
+\begin{intest}
+INTDRIVE\_usedbandwidth \index{INTDRIVE\_usedbandwidth}
+\end{intest}
+
+\begin{description}
+\item [\textbf{bandwidth\_t INTDRIVE\_usedbandwidth(LEVEL l);}]
+\item [\textbf{Description:}]returns the bandwidth used by the IntDrive.
+\end{description}
+
+\begin{intest}
+INTDRIVE\_set\_q\_theta \index{INTDRIVE\_set\_q\_theta}
+\end{intest}
+
+\begin{description}
+\item [\textbf{TIME INTDRIVE\_set\_q\_theta(LEVEL l, TIME new\_q\_theta);}]
+\item [\textbf{Description:}]changes the \texttt{q\_theta} value. Notice that
+changing \texttt{q\_theta} does not affect the bandwidth used by the server, nor
+the schedulability conditions for the application tasks.
+\end{description}
+
+\textbf{ATTENTION:} notice that IntDrive is based on the Lipari-Bini
+hierarchical framework proposed in \cite{Lip03}. Therefore, the schedulability
+tests used by the current scheduling modules are no more sufficient to guarantee
+the schedulability. See \cite{Lip03} and \cite{Fac05} for more details.
+
+%----------------------------------------------------------------------------
+\section{EDF (Earliest Deadline First) }
+%----------------------------------------------------------------------------
+
+\paragraph{Task Models Accepted:}
+
+\begin{description}
+\item [HARD\_TASK\_MODEL]- Hard Tasks (Periodic and Sporadic). The
+\texttt{wcet} and \texttt{mit} must be != 0. These parameters will
+be used to set the Worst Case Execution Time (WCET) and Period of
+the tasks. The \texttt{periodicity} can be either
+\texttt{PERIODIC} or \texttt{APERIODIC}. drel field must be <=
+mit.
+
+\begin{description}
+\item [NOTE:]A Relative Deadline of 0 is interpreted as MIT. \item
+[NOTE:]The utilization of the task is computed as wcet/drel. \item
+[NOTE:]\textbf{offset} field specifies a release offset relative
+to task\_activate or group\_activate.
+\end{description}
+
+\end{description}
+
+\paragraph{Guest Models Accepted:}
+
+\begin{description}
+\item [JOB\_TASK\_MODEL]- A single guest task activation. It must
+be identified by an absolute deadline and a period. The
+\texttt{period} field is ignored. \item [Description:]This module
+schedules periodic and sporadic tasks based on their absolute
+deadlines. The task guarantee is based on a simple utilization
+approach. The utilization factor of a task is computed as
+wcet/drel. (By default, drel = mit.) A periodic task must only be
+activated once; subsequent activations are triggered by an
+internal timer. By contrast, an sporadic task must be explicitely
+activated for each instance. NO GUARANTEE is performed on guest
+tasks. The guarantee must be performed by the level that inserts
+guest tasks in the EDF level.
+\end{description}
+
+\paragraph{Exceptions raised:}
+
+\begin{description}
+\item [XDEADLINE\_MISS]If a task misses its deadline and the
+\texttt{EDF\_ENABLE\_DL\_EXCEPTION} flag is set, this exception is
+raised. Note that after raising that exception, the task can't be
+put in execution again. The safest thing to do is to Shut Down the
+system! This exception is also raised if a guest task miss its
+deadline. \item [XWCET\_VIOLATION]If a task executes longer than
+its declared wcet and the \texttt{EDF\_ENABLE\_WCET\_EXCEPTION}
+flag is set, this exception is raised and the task is put in the
+\texttt{EDF\_WCET\_VIOLATED} state. To reactivate it, use
+\texttt{EDF\_task\_activate} via task\_activate or manage directly
+the EDF data structure. Note that the exception is not handled
+properly, an \texttt{XDEADLINE\_MISS} exception will also be
+raised at the period end. \item [XACTIVATION]If a sporadic task is
+activated with a rate that is greather than the rate declared in
+the model, this exception is raised and the task is NOT activated.
+This exception is also raised if we are trying to activate a
+periodic task stopped with \texttt{task\_delay}. \item
+[XUNVALID\_GUEST]This exception is raised if a
+\texttt{guest\_endcycle} or \texttt{guest\_sleep} guest calls are
+called.
+\end{description}
+
+\paragraph{Usage:}
+
+Usually this model is registered as one of the first Modules in
+the \texttt{\_\_kernel\_register\_levels\_\_} function. To
+register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{EDF\_register\_level(flag);}
+
+where \texttt{flag} can be:
+
+\begin{description}
+\item [(No\_flags\_enabled)]- Deadline and wcet overruns are
+ignored. Pending periodic jobs are queued and are eventually
+scheduled with correct deadlines according to their original
+arrival times. Sporadic tasks that arrive to often aresimply
+dropped. \item [EDF\_ENABLE\_DL\_CHECK]- When a deadline overrun
+occurs, the dl\_miss counter of the task is increased. Same
+behavior for pending jobs as above. \item
+[EDF\_ENABLE\_WCET\_CHECK]- When a wcet overrun occurs, the
+wcet\_miss counter of the task is increased. Same behavior for
+pending jobs as above. \item [EDF\_ENABLE\_DL\_EXCEPTION]- When a
+deadline overrun occurs, an exception is raised. \item
+[EDF\_ENABLE\_WCET\_EXCEPTION]- When a wcet overrun occurs, an
+exception is raised. \item [EDF\_ENABLE\_ACT\_EXCEPTION]When a
+periodic or sporadic task is activated too often, an exception is
+raised.
+\end{description}
+
+The functions \texttt{EDF\_get\_dl\_miss},
+\texttt{EDF\_get\_wcet\_miss}, \texttt{EDF\_get\_act\_miss}, and
+EDF\_get\_nact can be used to find out the number of missed
+deadlines, the number of wcet overruns, the number of skipped
+activations, and the number of currently queued periodic
+activations.
+
+\begin{description}
+\item [EDF\_DISABLE\_ALL]- All checks disabled \item
+[EDF\_ENABLE\_GUARANTEE]- Guarantee test enabled.
+
+When enabled, an acceptance test
+($\sum\frac{WCET_{i}}{Period_{i}}<1$) is performed; Deadline miss
+exceptions are raised in any case.
+
+\item [EDF\_ENABLE\_ALL]- All checks enabled
+\end{description}
+
+The EDF Module provides also addictional functions:
+
+\begin{description}
+\item [\textbf{bandwidth\_t EDF\_usedbandwidth(LEVEL l);}]
+It returns the used bandwidth, where l is the level at which the
+EDF Module is registered.
+\item [\textbf{int EDF\_get\_dl\_miss(PID p);}]
+It returns the deadline miss counter.
+\item [\textbf{int EDF\_get\_wcet\_miss(PID p);}]
+It returns the wcet miss counter.
+\item [\textbf{int EDF\_get\_act\_miss(PID p);}]
+It returns the activation miss counter.
+\end{description}
+
+\paragraph{Files:}
+
+\texttt{modules/edf/*}
+
+\paragraph{Implementation hints:}
+
+It uses the CONTROL\_CAP field to keep track of the task execution
+time. It implements a ZOMBIE state for ended tasks. It post a
+single OSLib event for each task for deadline/reactivation/zombie
+detection. The \texttt{guest\_endcycle} and \texttt{guest\_sleep}
+guest calls are not implemented.
+
+\begin{description}
+\item [NOTES:]~
+\end{description}
+
+\begin{enumerate}
+\item Relative deadlines \textbf{drel <= mit} may be specified.
+\item An offset
+>
+0 will delay the activation of the task by the same amount of
+time. To synchronize a group of tasks, assign suitable offsets and
+then use the group\_activate function. \item This level doesn't
+manage the main task. \item The level uses the priority and
+timespec\_priority fields. \item The guest tasks don't provide the
+guest\_endcycle function.
+\end{enumerate}
+
+%----------------------------------------------------------------------------
+\section{POSIX (fixed priority FIFO/RR scheduler)}
+%----------------------------------------------------------------------------
+
+\paragraph{Task Models Accepted:}
+
+\begin{description}
+\item [NRT\_TASK\_MODEL]- Non-Realtime Tasks. If the
+\texttt{inherit} field is set to \texttt{NRT\_INHERIT\_SCHED}, the
+scheduling properties of the running task are inherited (as
+required by the POSIX standard). Else, the \texttt{slice} field is
+used to set the time slice of the task (if \texttt{slice} is set
+to 0, the default value is used); the \texttt{weight} field is
+used to set the task priority; the \texttt{policy} field is used
+to set the policy of the task (\texttt{NRT\_RR\_POLICY} for
+Round-Robin or \texttt{NRT\_FIFO\_POLICY} for FIFO); the
+\texttt{arrivals} field can be set to \texttt{SAVE\_ARRIVALS} or
+\texttt{SKIP\_ARRIVALS}.
+\end{description}
+
+\paragraph{Description:}
+
+This module schedule his tasks following the POSIX scheduler as
+described by the standard IEEE 1003.1c. This Module is typically
+used by the POSIX primitives for their scheduling pourposes. For
+example, the pthread\_create function calls the task\_createn
+function passing a NRT\_TASK\_MODEL filled with the correct
+parameters.
+
+The Module can create the \texttt{\_\_init\_\_} task, that is
+typically used to call the Standard C \texttt{main()} function.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XUNVALID\_GUEST]This level doesn't support guests. When a
+guest operation is called, the exception is raised.
+\end{description}
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{POSIX\_register\_level(slice, createmain, mb,
+prioritylevels);}
+
+where \texttt{slice} is the default timeslice for the POSIX tasks scheduled
+using the Round-Robin policy, \texttt{createmain} is \texttt{POSIX\_MAIN\_YES}
+or \texttt{POSIX\_MAIN\_NO} if you want that the POSIX Module creates or not the
+\texttt{\_\_init\_\_} task, \texttt{mb} is the \texttt{struct multiboot\_info
+*} the Kernel passed to the \texttt{\_\_kernel\_register\_levels\_\_}
+function, and prioritylevels are the number of different priority levels
+supported by the Module \footnote{The POSIX standard requires a minimum of 32
+priority levels}.
+
+The POSIX Module provides also some addictional function, that are
+used to implement the behaviour of various POSIX primitives:
+
+\texttt{int POSIX\_sched\_yield(LEVEL l);}
+
+This function forces the running task to go to his queue tail,
+then calls the scheduler and changes the context. It is used by
+the \texttt{sched\_yield()} primitive.
+
+\texttt{int POSIX\_get\_priority\_max(LEVEL l);}
+
+This function returns the maximum level allowed for the POSIX
+level. It is used by the \texttt{sched\_get\_priority()}
+primitive.
+
+\texttt{int POSIX\_rr\_get\_interval(LEVEL l);}
+
+This function returns the default timeslice for the POSIX level.
+It is used by the \texttt{sched\_rr\_get\_interval()} primitive.
+
+\texttt{int POSIX\_getschedparam(LEVEL l, PID p, int *policy,
+int *priority);}
+
+This functions returns some paramaters of a task; \texttt{policy}
+is set to \texttt{NRT\_RR\_POLICY} or \texttt{NRT\_FIFO\_POLICY};
+priority is set in the range \texttt{{[}0..prioritylevels{]}}. The
+function returns \texttt{ENOSYS} or \texttt{ESRCH} if there are
+problems. The function must be called with interrupts disabled and
+is used by the \texttt{pthread\_getschedparam()} primitive.
+
+\texttt{int POSIX\_setschedparam(LEVEL l, PID p, int policy, int
+priority);}
+
+This functions sets some paramaters of a task; \texttt{policy}
+must be set to \texttt{NRT\_RR\_POLICY} or
+\texttt{NRT\_FIFO\_POLICY}; priority must be set in the range
+\texttt{{[}0..prioritylevels{]}}. The function returns
+\texttt{ENOSYS}, \texttt{EINVAL} or \texttt{ESRCH} if there are
+problems. The function must be called with interrupts disabled and
+is used by the \texttt{pthread\_setschedparam() primitive}.
+
+\paragraph{Files:}
+
+\texttt{modules/posix/*}
+
+\paragraph{Implementation hints:}
+
+The implementation of this module is directly derived from the RR
+scheme.
+
+%----------------------------------------------------------------------------
+\section{RM (Rate Monotonic)}
+%----------------------------------------------------------------------------
+
+\paragraph{Task
+Models Accepted:}
+
+\begin{description}
+\item [HARD\_TASK\_MODEL]- Hard Tasks (Periodic and Sporadic). The
+\texttt{wcet} and \texttt{mit} must be != 0. These parameters will
+be used to set the Worst Case Execution Time (WCET) and Period of
+the tasks. The \texttt{periodicity} can be either
+\texttt{PERIODIC} or \texttt{APERIODIC}. The Relative Deadline is
+ignored (deadlines are equal to periods).
+\end{description}
+
+\paragraph{Guest Models Accepted:}
+
+\begin{description}
+\item [JOB\_TASK\_MODEL]- A single guest task activation. It must
+be identified by an absolute deadline and a period.
+\end{description}
+
+\paragraph{Description:}
+
+This module schedule his tasks following the classic RM scheme as
+described by Liu and Layland. The task guarantee is based on the
+factor utilization approach. The tasks scheduled are periodic and
+sporadic. The sporadic tasks are like hard task with periodicity
+set to \texttt{APERIODIC}; they are guaranteed as a periodic task
+with period equal to the minimum interarrival time. All the task
+are put in a queue and the scheduling is based on the period
+value.
+
+No Guarantee is performed on guest tasks. The guarantee must be
+performed by the level that inserts guest tasks in the RM level.
+
+If a RM task does not respect its WCET and deadline constraints,
+then the Module will raise an exception. Note that the deadline
+exception is not recoverable, so the Module will be in an
+inconsistent state after a Deadline Miss. Deadline Miss in this
+Module are treated as unrecoverable errors.
+
+If you try to activate a Periodic task that is not sleeping,
+nothing happens.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XDEADLINE\_MISS]If a task miss his deadline, the exception
+is raised. Note that after raising that exception, the task can't
+be put in execution again. The safest thing to do is to Shut Down
+the system! This exception is also raised if a guest task miss its
+deadline. \item [XWCET\_VIOLATION]If a task doesn't end the
+current cycle before if consume the \texttt{wcet}, an exception is
+raised, and the task is put in the \texttt{RM\_WCET\_VIOLATED}
+state. To reactivate it, use \texttt{RM\_task\_activate} via
+task\_activate or manage directly the RM data structure. Note that
+the exception is not handled properly, an \texttt{XDEADLINE\_MISS}
+exception will also be raised at the period end. \item
+[XACTIVATION]If a sporadic task is activated with a rate that is
+greather than the rate declared in the model, this exception is
+raised and the task is NOT activated. This exception is also
+raised if we are trying to activate a periodic task stopped with
+\texttt{task\_sleep} before the deadline in which the
+\texttt{task\_sleep} is called. \item [XUNVALID\_GUEST]This
+exception is raised if a \texttt{guest\_endcycle} or
+\texttt{guest\_sleep} guest calls are called.
+\end{description}
+
+\paragraph{Usage:}
+
+Usually this model is registered as one of the first Modules in
+the \texttt{\_\_kernel\_register\_levels\_\_} function. To
+register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{RM\_register\_level(flag);}
+
+where \texttt{flag} can be:
+
+Restrictions and special features:
+
+\begin{description}
+\item [(No\_flags\_enabled)]- Deadline and wcet overruns are
+ignored. Pending periodic jobs are queued and are eventually
+scheduled with correct deadlines according to their original
+arrival times. Sporadic tasks that arrive to often are simply
+dropped. \item [RM\_ENABLE\_DL\_CHECK]- When a deadline overrun
+occurs, the dl\_miss counter of the task is increased. Same
+behavior for pending jobs as above. \item
+[RM\_ENABLE\_WCET\_CHECK]- When a wcet overrun occurs, the
+wcet\_miss counter of the task is increased. Same behavior for
+pending jobs as above. \item [RM\_ENABLE\_DL\_EXCEPTION]- When a
+deadline overrun occurs, an exception is raised. \item
+[RM\_ENABLE\_WCET\_EXCEPTION]- When a wcet overrun occurs, an
+exception is raised. \item [RM\_ENABLE\_ACT\_EXCEPTION]When a
+periodic or sporadic task is activated too often, an exception is
+raised. \item [RM\_DISABLE\_ALL]- Wcet and Guarantee test disabled
+\item [RM\_ENABLE\_GUARANTEE]- Guarantee test enabled (when
+enabled, an acceptance test ($\sum\frac{WCET_{i}}{Period_{i}}<1$)
+is performed; Deadline miss exceptions are raised in any case.
+Note that, for reasons of semplicity, the test that has been
+implemented IS NOT the test for RM, but only a simple acceptance
+test. \item [RM\_ENABLE\_ALL]- Wcet and Guarantee test enabled
+\end{description}
+The RM Module provides also addictional functions:
+
+\begin{description}
+\item [\textbf{bandwidth\_t RM\_usedbandwidth(LEVEL l);}]
+It returns the used bandwidth, where l is the level at which the
+RM Module is registered.
+\item [\textbf{int RM\_get\_dl\_miss(PID p);}]
+It returns the deadline miss counter.
+\item [\textbf{int RM\_get\_wcet\_miss(PID p);}]
+It returns the wcet miss counter.
+\item [\textbf{int RM\_get\_act\_miss(PID p);}]
+It returns the activation miss counter.
+\end{description}
+
+\paragraph{Files:}
+
+\texttt{modules/rm/*}
+
+\paragraph{Implementation hints:}
+
+The implementation of this module is very similar to the
+implementation of the EDF Module.
+
+\paragraph{NOTE}
+
+\begin{enumerate}
+\item Relative deadlines drel <= mit may be specified. \item An offset > 0 will
+delay the activation of the task by the same amount of time. To synchronize a
+group of tasks, assign suitable \item offsets and then use the group\_activate
+function. \item This level doesn't manage the main task. \item The level uses
+the priority and timespec\_priority fields. \item The guest tasks don't provide
+the guest\_endcycle function. \item At init time, the user can specify the
+behavior in case ofdeadline and wcet overruns. The following flags are
+available:
+\end{enumerate}
+
+%----------------------------------------------------------------------------
+\section{RR (Round Robin)}
+%----------------------------------------------------------------------------
+
+\paragraph{Task Models Accepted:}
+
+\begin{description}
+\item [NRT\_TASK\_MODEL]- Non-Realtime Tasks. The \texttt{slice}
+field is used to set the time slice of the task. If \texttt{slice}
+is set to 0, the default value is used. The \texttt{weight},
+\texttt{arrivals}, \texttt{policy} and \texttt{inherit} fields are
+ignored.
+\end{description}
+
+\paragraph{Description:}
+
+This module schedule his tasks following the classic round-robin
+scheme. The default timeslice is given at registration time and is
+a a per-task specification. The default timeslice is used if the
+\texttt{slice} field in the \texttt{NRT\_TASK\_MODEL} is 0.
+
+If a task is activated when it is already active (its instance is
+not yet finished on a \texttt{task\_endcycle} or
+\texttt{task\_sleep}), nothing happens.
+
+If you need to remember the pending activations you can use the
+\texttt{RR2} scheduling module.
+
+The Module can create the \texttt{\_\_init\_\_} task, that is
+typically used to call the Standard C \texttt{main()} function.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XUNVALID\_GUEST]This level doesn't support guests. When a
+guest operation is called, the exception is raised.
+\end{description}
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{RR\_register\_level(slice, createmain, mb);}
+
+where \texttt{slice} is the default timeslice for the RR tasks,
+\texttt{createmain} is \texttt{RR\_MAIN\_YES} or
+\texttt{RR\_MAIN\_NO} if you want that RR creates or not the
+\texttt{\_\_init\_\_} task, \texttt{mb} is the \texttt{struct
+multiboot\_info *} the Kernel passed to the
+\texttt{\_\_kernel\_register\_levels\_\_} function.
+
+You can use more than one RR Scheduling Module to simulate a
+Multilevel scheduling policy. The RR Module does not add any
+addictional function.
+
+\paragraph{Files:}
+
+\texttt{modules/rr/*}
+
+\paragraph{Implementation hints:}
+
+This is one of the simplest scheduling module. It can be useful to
+learn how to create the \_\_init\_\_ task at startup time. It uses
+the CONTROL\_CAP field. It supports negative task capacities (that
+can happen when using shadows; for that reason, the scheduler has
+a while inside, and the timeslices ar added and not assigned). No
+Guarantee is performed at task creation.
+
+%----------------------------------------------------------------------------
+\section{RR2 (Round Robin with pending activations)}
+%----------------------------------------------------------------------------
+
+\paragraph{Task Models Accepted:}
+
+\begin{description}
+\item [NRT\_TASK\_MODEL]- Non-Realtime Tasks. The \texttt{slice}
+field is used to set the time slice of the task. If \texttt{slice}
+is set to 0, the default value is used. The \texttt{arrivals}
+field is used to say if the activations have to be saved
+(\texttt{SAVE\_ARRIVALS}) or skipped (\texttt{SKIP\_ARRIVALS}).
+The \texttt{weight}, \texttt{policy} and \texttt{inherit} fields
+are ignored.
+\end{description}
+
+\paragraph{Description:}
+
+The Module is identical to the RR Scheduling Module, except that
+task activations can be saved if a task was created with the
+arrivals field equal to SAVE\_ARRIVALS.
+
+\paragraph{Exceptions Raised:}
+
+See the RR Scheduling Module.
+
+\paragraph{Usage:}
+
+See the RR Scheduling Module, changing every occurrence of RR with
+RR2.
+
+\paragraph{Files:}
+
+\texttt{modules/rr2/*}
+
+\paragraph{Implementation hints:}
+
+With respect to the RR Scheduling Module, it adds a pending
+activation counter (nact) for each task.
+
+%----------------------------------------------------------------------------
+\section{RRSOFT (hard/SOFT Round Robin)}
+%----------------------------------------------------------------------------
+
+\paragraph{Task Models Accepted:}
+
+\begin{description}
+\item [HARD\_TASK\_MODEL]- Hard Tasks (Periodic and Sporadic).
+Only the periodicity and the mit parameters are used to know if
+the task is periodic/sporadic and to set the task period. The task
+timeslice is set to the default value. \item [SOFT\_TASK\_MODEL]-
+Soft Tasks (Periodic and Sporadic). Only the periodicity, arrivals
+and period parameters are used to know if the task is
+periodic/sporadic, to set the task period and to know if the
+pending activations should be saved. The task timeslice is set to
+the default value. \item [NRT\_TASK\_MODEL]- Non-Realtime Tasks.
+The \texttt{slice} field is used to set the time slice of the
+task. If \texttt{slice} is set to 0, the default value is used.
+The \texttt{arrivals} field is used to say if the activations have
+to be saved (\texttt{SAVE\_ARRIVALS}) or skipped
+(\texttt{SKIP\_ARRIVALS}). The \texttt{weight}, \texttt{policy}
+and \texttt{inherit} fields are ignored.
+\end{description}
+
+\paragraph{Description:}
+
+This module can be used as a polymorphic module that can accept
+Hard, Soft or NRT Task Models. The policy used to schedule the
+tasks is the same of RR2, plus the fact that SOFT and HARD tasks
+can be periodic, so they can be automatically activated at each
+instance.
+
+This Module is very useful if you want to replace another Module
+that accept Hard of Soft tasks with a round-robin scheduler, for
+example to compare a scheduling algorithm with the plain round
+robin.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XUNVALID\_GUEST]This level doesn't support guests. When a
+guest operation is called, the exception is raised.
+\end{description}
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{RRSOFT\_register\_level(slice, createmain, mb, models);}
+
+where \texttt{slice} is the default timeslice for the RR tasks,
+\texttt{createmain} is \texttt{RR\_MAIN\_YES} or
+\texttt{RR\_MAIN\_NO} if you want that RR creates or not the
+\texttt{\_\_init\_\_} task, \texttt{mb} is the \texttt{struct
+multiboot\_info *} the Kernel passed to the
+\texttt{\_\_kernel\_register\_levels\_\_} function, and
+\texttt{models} specifies the kind of Models accepted by the
+Module. The \texttt{models} value can be an or of the values of
+the following constants: \texttt{RRSOFT\_ONLY\_HARD},
+\texttt{RRSOFT\_ONLY\_HARD}, \texttt{RRSOFT\_ONLY\_HARD}.
+
+You can use more than one RR Scheduling Module to simulate a
+Multilevel scheduling policy. The RR Module does not add any
+addictional function.
+
+\paragraph{Files:}
+
+\texttt{modules/rrsoft/*}
+
+\paragraph{Implementation hints:}
+
+The implementation of the Module is similar to RR2 plus the
+implementation of the reactivation for periodic tasks.
+
+%----------------------------------------------------------------------------
+\chapter{Aperiodic servers}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\section{CBS (Constant Bandwidth Server)}
+%----------------------------------------------------------------------------
+
+\paragraph{Task Models Accepted:}
+
+\begin{description}
+\item [SOFT\_TASK\_MODEL]- Soft Tasks (Periodic and Sporadic). The
+\texttt{met} and \texttt{period} must be != 0. These parameters
+will be used to set the Mean Execution Time (MET) and the Period
+of the tasks. The \texttt{periodicity} can be either
+\texttt{PERIODIC} or \texttt{APERIODIC}. The \texttt{arrivals}
+field can be either \texttt{SAVE\_ARRIVALS} or
+\texttt{SKIP\_ARRIVALS}. The \texttt{wcet} field is ignored (Worst
+case execution times are not used by CBS).
+\end{description}
+
+\paragraph{Description:}
+
+This module schedule his tasks following the CBS algorithm. The
+task guarantee is based on the factor utilization approach. The
+tasks scheduled are periodic and sporadic. The sporadic tasks are
+like hard task with periodicity set to \texttt{APERIODIC}. All the
+task are put as guest task in the scheduling queue of another
+Module (typically that Module is an EDF Module).
+
+A CBS server is attached to each task, with the parameters passed
+in the \texttt{SOFT\_TASK\_MODEL}.
+
+If you try to activate a Periodic task that is not sleeping, a pending
+activation is recorded \footnote{If the task was created with the
+\texttt{SAVE\_ARRIVALS} option... }.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XUNVALID\_GUEST]This level doesn't support guests. When a
+guest operation is called, the exception is raised.
+\end{description}
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{CBS\_register\_level(flag, master);}
+
+where \texttt{flag} can be:
+
+\begin{description}
+\item [CBS\_DISABLE\_ALL]- Guarantee test disabled. \item
+[CBS\_ENABLE\_GUARANTEE]- Guarantee test enabled (when enabled, an
+acceptance test ($\sum\frac{met_{i}}{period_{i}}<1$) is performed;
+Deadline miss exceptions are raised in any case. \item
+[CBS\_ENABLE\_ALL]- Guarantee test enabled.
+\end{description}
+and \texttt{master} is the level to that the CBS is attached. At
+the moment, you can attach a CBS Module either to an \texttt{EDF}
+or an \texttt{EDFACT} Module. The CBS Module can be registered as
+the last scheduling Module after the \texttt{DUMMY} Module (this
+because the CBS Module does not use background time, and because
+when a CBS task is ready it is inserted in another queue!).
+
+The CBS Module provides also an addictional function, that can be
+used to get the used bandwidth by the Module and the pending
+activations of a task. The prototypes of these function are:
+
+\texttt{bandwidth\_t CBS\_usedbandwidth(LEVEL l);}
+
+where l is the level at which the CBS Module is registered.
+
+\texttt{int CBS\_get\_nact(LEVEL l, PID p);}
+
+Returns the number of pending activations of a task. No control is
+done if the task is not a CBS task! (l is the level at which the
+CBS Module is registered, p is the PID of the task).
+
+\paragraph{Files:}
+
+\texttt{modules/cbs/*}
+
+\paragraph{Implementation hints:}
+
+CBS implementation is similar to the EDF implementation except
+that a capacity exaustion postpones a deadline, and that the
+deadline event is simply a reactivation. This is one of the only
+Modules where the \texttt{task\_eligible} task calls is defined
+non-void.
+
+%----------------------------------------------------------------------------
+\section{HARD\_CBS}
+%----------------------------------------------------------------------------
+
+This Module is very similar to the standard CBS, but it implements
+the Hard Reservation algorithm.
+
+\begin{description}
+\item [Files:]\texttt{modules/hardcbs/*}
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{DS (Deferrable Server)}
+%----------------------------------------------------------------------------
+
+\paragraph{Task Models Accepted:}
+
+\begin{description}
+\item [SOFT\_TASK\_MODEL]- Soft Tasks (only Sporadic). The
+\texttt{periodicity} can be only \texttt{APERIODIC}. The
+\texttt{arrivals} field can be either \texttt{SAVE\_ARRIVALS} or
+\texttt{SKIP\_ARRIVALS}. The other fields are ignored.
+\end{description}
+
+\paragraph{Description:}
+
+This module schedule its tasks following the Deferrable Server
+Algorithm. All the aperiodic requests are served on a FCFS basis.
+The Module can be configured to use only its budget or to also use
+the idle time left by the higher level Modules. The Module can be
+configured to save or skip task activations. The Module can be
+attached to either a RM or an EDF Module.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XUNVALID\_GUEST]This level doesn't support guests. When a
+guest operation is called, the exception is raised.
+\end{description}
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{DS\_register\_level(flag, master, Cs, per);}
+
+where \texttt{flag} can be:
+
+\begin{description}
+\item [DS\_DISABLE\_ALL]- Guarantee test disabled; Background
+scheduling disabled. \item [DS\_ENABLE\_BACKGROUND]- Background
+scheduling enabled. \item [DS\_ENABLE\_GUARANTEE\_EDF]- Guarantee
+test enabled (when enabled, an acceptance test ($U_{p}+U_{s}<1$)
+is performed. This flag have to be used if the Module is attached
+to an EDF Module. \item [DS\_ENABLE\_ALL\_EDF]- EDF guarantee test
+enabled, Background scheduling disabled. \item
+[DS\_ENABLE\_GUARANTEE\_RM]- Guarantee test enabled (when enabled,
+an acceptance test ($U_{p}+U_{s}<ln\,2$) is performed. This flag
+have to be used if the Module is attached to a RM Module. \item
+[DS\_ENABLE\_ALL\_RM]- RM guarantee test enabled, Background
+scheduling disabled.
+\end{description}
+\texttt{master} is the level to that the DS Module is attached. At
+the moment, you can attach a DS Module either to an \texttt{EDF},
+\texttt{EDFACT} or \texttt{RM} Module. \texttt{Cs} and
+\texttt{per} are the budget and the period of the deferrable
+server. If it is configured to do not use background time, the DS
+Module can be registered as the last scheduling Module after the
+\texttt{DUMMY} Module. Otherwise, it should be put in the middle
+of the list to catck the idle time left by higher level Modules.
+
+The DS Module provides also an addictional function, that can be
+used to get the used bandwidth by the Module. The prototype of the
+function is:
+
+\texttt{bandwidth\_t DS\_usedbandwidth(LEVEL l);}
+
+where l is the level at which the DS Module is registered.
+
+\paragraph{Files:}
+
+\texttt{modules/ds/*}
+
+\paragraph{Implementation hints:}
+
+The DS Module uses a FIFO queue to enqueue the ready tasks. Only
+the first task is inserted into the queue of the Master Level. The
+Module does not use the CONTROL\_CAP field, but it handles its
+capacity event by itself. The budget of the module is recharged
+every DS period, and is kept into an internal data structure of
+the module, and not in the wcet and avail\_time fields of every
+task. Note that the idle time is recognized when the DS scheduler
+is called. In that case, no capacity event is posted. The
+implementation is very similar to the PS Module implementation.
+
+%----------------------------------------------------------------------------
+\section{PS (Polling Server)}
+%----------------------------------------------------------------------------
+
+\paragraph{Task Models Accepted:}
+
+\begin{description}
+\item [SOFT\_TASK\_MODEL]- Soft Tasks (only Sporadic). The
+\texttt{periodicity} can be only \texttt{APERIODIC}. The
+\texttt{arrivals} field can be either \texttt{SAVE\_ARRIVALS} or
+\texttt{SKIP\_ARRIVALS}. The other fields are ignored.
+\end{description}
+
+\paragraph{Description:}
+
+This module schedule its tasks following the Polling Server
+Algorithm. All the aperiodic requests are served on a FCFS basis.
+The Module can be configured to use only its budget or to also use
+the idle time left by the higher level Modules. The Module can be
+configured to save or skip task activations. The Module can be
+attached to either a RM or an EDF Module.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XUNVALID\_GUEST]This level doesn't support guests. When a
+guest operation is called, the exception is raised.
+\end{description}
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{PS\_register\_level(flag, master, Cs, per);}
+
+where \texttt{flag} can be:
+
+\begin{description}
+\item [PS\_DISABLE\_ALL]- Guarantee test disabled; Background
+scheduling disabled. \item [PS\_ENABLE\_BACKGROUND]- Background
+scheduling enabled. \item [PS\_ENABLE\_GUARANTEE\_EDF]- Guarantee
+test enabled (when enabled, an acceptance test ($U_{p}+U_{s}<1$)
+is performed. This flag have to be used if the Module is attached
+to an EDF Module. \item [PS\_ENABLE\_ALL\_EDF]- EDF guarantee test
+enabled, Background scheduling disabled. \item
+[PS\_ENABLE\_GUARANTEE\_RM]- Guarantee test enabled (when enabled,
+an acceptance test ($U_{p}+U_{s}<ln\,2$) is performed. This flag
+have to be used if the Module is attached to a RM Module. \item
+[PS\_ENABLE\_ALL\_RM]- RM guarantee test enabled, Background
+scheduling disabled.
+\end{description}
+\texttt{master} is the level to that the DS Module is attached. At
+the moment, you can attach a PS Module either to an \texttt{EDF},
+\texttt{EDFACT} or \texttt{RM} Module. \texttt{Cs} and
+\texttt{per} are the budget and the period of the deferrable
+server. If it is configured to do not use background time, the PS
+Module can be registered as the last scheduling Module after the
+\texttt{DUMMY} Module. Otherwise, it should be put in the middle
+of the list to catck the idle time left by higher level Modules.
+
+The PS Module provides also an addictional function, that can be
+used to get the used bandwidth by the Module. The prototype of the
+function is:
+
+\texttt{bandwidth\_t PS\_usedbandwidth(LEVEL l);}
+
+where l is the level at which the PS Module is registered.
+
+\paragraph{Files:}
+
+\texttt{modules/ps/*}
+
+\paragraph{Implementation hints:}
+
+The PS Module uses a FIFO queue to enqueue the ready tasks. Only
+the first task is inserted into the queue of the Master Level. The
+Module does not use the CONTROL\_CAP field, but it handles its
+capacity event by itself. The budget of the module is recharged
+every PS period, and is kept into an internal data structure of
+the module, and not in the wcet and avail\_time fields of every
+task. Note that the idle time is recognized when the PS scheduler
+is called. In that case, no capacity event is posted. The
+implementation is very similar to the DS Module implementation.
+
+%----------------------------------------------------------------------------
+\section{SS (Sporadic Server)}
+%----------------------------------------------------------------------------
+
+\paragraph{Task Models Accepted:}
+
+\begin{description}
+\item [SOFT\_TASK\_MODEL]- Soft Tasks (only Sporadic). The
+\texttt{periodicity} can be only \texttt{APERIODIC}. The
+\texttt{arrivals} field can be either \texttt{SAVE\_ARRIVALS} or
+\texttt{SKIP\_ARRIVALS}. The other fields are ignored.
+\end{description}
+
+\paragraph{Description:}
+
+This module schedule its tasks following the Sporadic Server
+Algorithm. The Module can be configured to save or skip task
+activations. The Module can be attached to either a RM or an EDF
+Module. The module has been written by Marco Gigante. Please
+contact the author for more informations.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XUNVALID\_GUEST]This level doesn't support guests. When a
+guest operation is called, the exception is raised.
+\end{description}
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{SS\_register\_level(flag, master, Cs, per);}
+
+where \texttt{flag} can be:
+
+\begin{description}
+\item [SS\_DISABLE\_ALL]- Guarantee test disabled; Background
+scheduling disabled. \item [SS\_ENABLE\_BACKGROUND]- Background
+scheduling enabled. \item [SS\_ENABLE\_GUARANTEE\_EDF]- Guarantee
+test enabled (when enabled, an acceptance test ($U_{p}+U_{s}<1$)
+is performed. This flag have to be used if the Module is attached
+to an EDF Module. \item [SS\_ENABLE\_ALL\_EDF]- EDF guarantee test
+enabled, Background scheduling disabled. \item
+[SS\_ENABLE\_GUARANTEE\_RM]- Guarantee test enabled (when enabled,
+an acceptance test ($U_{p}+U_{s}<ln\,2$) is performed. This flag
+have to be used if the Module is attached to a RM Module. \item
+[SS\_ENABLE\_ALL\_RM]- RM guarantee test enabled, Background
+scheduling disabled.
+\end{description}
+
+\texttt{master} is the level to that the SS Module is attached. At
+the moment, you can attach a SS Module either to an \texttt{EDF},
+\texttt{EDFACT} or \texttt{RM} Module. \texttt{Cs} and
+\texttt{per} are the budget and the period of the deferrable
+server. If it is configured to do not use background time, the SS
+Module can be registered as the last scheduling Module after the
+\texttt{DUMMY} Module. Otherwise, it should be put in the middle
+of the list to catck the idle time left by higher level Modules.
+
+The SS Module provides also some addictional function, that can be
+used to get the used bandwidth by the Module and its available
+capacity. The prototypes of the functions are:
+
+\texttt{bandwidth\_t SS\_usedbandwidth(LEVEL l);}
+
+where l is the level at which the SS Module is registered.
+
+\texttt{int SS\_availCs(LEVEL l);}
+
+Returns tha available capacity of the Module
+
+\paragraph{Files:}
+
+\texttt{modules/ss/*}
+
+\paragraph{Implementation hints:}
+
+The implementation of the Module is quite complex. Please refer to
+the comments in the source code.
+
+%----------------------------------------------------------------------------
+\section{TBS (Total Bandwidth Server)}
+%----------------------------------------------------------------------------
+
+\paragraph{Task Models Accepted:}
+
+\begin{description}
+\item [SOFT\_TASK\_MODEL]- Soft Tasks (only Sporadic). The
+\texttt{wcet} must be != 0. The \texttt{periodicity} can be either
+\texttt{PERIODIC} or \texttt{APERIODIC}. The \texttt{arrivals}
+field can be either \texttt{SAVE\_ARRIVALS} or
+\texttt{SKIP\_ARRIVALS}. The other fields are ignored.
+\end{description}
+
+\paragraph{Description:}
+
+This module schedule his tasks following the TBS algorithm. The
+task guarantee is based on the factor utilization approach. The
+tasks scheduled are only sporadic. Each task has a deadline
+assigned with the TBS scheme,
+$d_{k}=\max(r_{k},d_{k-1})+\frac{wcet}{U_{s}}$
+
+The tasks are inserted in an EDF level (or similar), and the TBS
+level expects that the task is scheduled with the absolute
+deadline passed in the guest model.
+
+The acceptance test is based on the factor utilization approach.
+The theory guarantees that the task set is schedulable if
+$U_{p}+U_{s}\leq1$ so it is sufficient to add the Us to the
+bandwidth used by the upper levels.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XUNVALID\_GUEST]This level doesn't support guests. When a
+guest operation is called, the exception is raised. \item
+[XDEADLINE\_MISS]If a task miss his deadline, the exception is
+raised. Normally, a TBS task can't cause the raise of such
+exception because if it really use more time than declared a
+\texttt{XWCET\_VIOLATION} is raised instead. \item
+[XWCET\_VIOLATION]If a task doesn't end the current cycle before
+if consume the wcet, an exception is raised, and the task is put
+in the \texttt{TBS\_WCET\_VIOLATED} state. To reactivate it, call
+\texttt{TBS\_task\_activate} using \texttt{task\_activate} or
+manage directly the TBS data structure. Note that if the exception
+is not handled properly, an \texttt{XDEADLINE\_MISS} exception
+will also be raised at the absolute deadline...
+\end{description}
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{TBS\_register\_level(flag, master, num, den);}
+
+where \texttt{flag} can be:
+
+\begin{description}
+\item [TBS\_DISABLE\_ALL]- Guarantee test disabled. \item
+[TBS\_ENABLE\_GUARANTEE]- Guarantee test enabled (when enabled,
+the acceptance test is performed); Deadline miss exceptions are
+raised in any case. \item [TBS\_ENABLE\_WCET\_CHECK]- WCET check
+enabled. \item [TBS\_ENABLE\_ALL]- Guarantee test and WCET check
+enabled.
+\end{description}
+and \texttt{master} is the level to that the TBS is attached. num
+and den are the reserved bandwidth ($U_{s}=\frac{num}{den}$) for
+the TBS server. At the moment, you can attach a TBS Module either
+to an \texttt{EDF} or an \texttt{EDFACT} Module. The TBS Module
+can be registered as the last scheduling Module after the
+\texttt{DUMMY} Module (this because the TBS Module does not use
+background time, and because when a TBS task is ready it is
+inserted in another queue!).
+
+The TBS Module provides also some addictional functions, that can
+be used to get the used bandwidth by the Module and the pending
+activations of a task. The prototypes of these function are:
+
+\texttt{bandwidth\_t TBS\_usedbandwidth(LEVEL l);}
+
+where l is the level at which the TBS Module is registered.
+
+\texttt{int TBS\_get\_nact(LEVEL l, PID p);}
+
+Returns the number of pending activations of a task. No control is
+done if the task is not a TBS task! (l is the level at which the
+TBS Module is registered, p is the PID of the task).
+
+\paragraph{Files:}
+
+\texttt{modules/tbs/*}
+
+\paragraph{Implementation hints:}
+
+The TBS implementation uses a FIFO queue for serving the aperiodic
+requests of the Module's tasks. Only the first task is put in the
+ready queue of the master module.
+
+%----------------------------------------------------------------------------
+\chapter{Sharing resource access protocols}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\section{CABS}
+%----------------------------------------------------------------------------
+
+\paragraph{Description:}
+
+This module implements the Cyclical Asynchronous Buffers as
+described in the Volume I of the User Manual.
+
+Note that the Maximum number of CABs that can be created is
+MAX\_CAB (defined in include/modules/cabs.h).
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{CABS\_register\_module();}
+
+\paragraph{Files:}
+
+\texttt{modules/cabs/*}
+
+%----------------------------------------------------------------------------
+\section{HARTPORT}
+%----------------------------------------------------------------------------
+
+\paragraph{Description:}
+
+This module implements the Communication Ports as described in the
+Volume I of the User Manual.
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the \texttt{\_\_init\_\_} task
+\footnote{or in any other task; in any case this function has to be called
+before using the port primitives}:
+
+\texttt{HARTPORT\_init();}
+
+\paragraph{IMPORTANT: }
+
+Remember that to get the ports running, you need to register also
+the SEM module!
+
+\paragraph{Files:}
+
+\texttt{modules/hartport/*}
+
+%----------------------------------------------------------------------------
+\section{NOP (NO Protocol)}
+%----------------------------------------------------------------------------
+
+\paragraph{Resource Models Accepted:}
+
+None.
+
+\paragraph{Description:}
+
+The NOP Module implements a binary semaphore using the mutex
+interface. If a task owns a mutex, it can not lock that mutex
+again until it has unlocked it. This protocol can produce priority
+inversions and chained blocking.
+
+\paragraph{Exceptions Raised:}
+
+None
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{NOP\_register\_module();}
+
+The NOP protocol uses the default mutex mechanism provided by the
+Kernel. In that way, the NOP behaviour for a mutex can be set at
+run-time, and the applications can choose the protocol of their
+mutexes without changing the task source code.
+
+To initialize a NOP mutex, you need to call \texttt{mutex\_init()}
+passing a previously initialized \texttt{NOP\_mutexattr\_t}.
+
+In the following example, the demo task uses two resources,
+labeled with \texttt{m1} and \texttt{m2}, and accesses three
+different critical sections:
+
+\begin{tt}
+\begin{verbatim}
+#include <modules/nop.h>
+...
+
+mutex_t m1,m2;
+...
+
+void *demo(void *arg) {
+ ...
+
+ mutex_lock(&m1);
+
+ /* critical section of m1 */
+ ...
+
+ mutex_unlock(&m1);
+ ...
+
+ mutex_lock(&m1);
+
+ /* only m1 locked */
+ ...
+
+ mutex_lock(&m2);
+
+ /* m1 and m2 locked */
+ ...
+
+ mutex_unlock(&m2); /* NOTE: first m2, then m1! */
+ mutex_unlock(&m1);
+ ...
+
+ return 0;
+}
+
+...
+
+int main(int argc, char **argv) {
+ HARD_TASK_MODEL m;
+ PID p0, p1, p2;
+
+ NOP_mutexattr_t a;
+
+ /* Initialize the NOP mutexes */
+ NOP_mutexattr_default(a);
+ mutex_init(&m1, &a);
+ mutex_init(&m2, &a);
+ ...
+
+ /* Create the task */
+ hard_task_default_model(m);
+ hard_task_def_mit(m, 1000000);
+ hard_task_def_wcet(m, 80000);
+ p0 = task_create("DEMO", demo, &m, NULL);
+ ...
+}
+\end{verbatim}
+\end{tt}
+
+Critical sections must be properly nested (like Chinese boxes):
+hence the order of the \texttt{mutex\_unlock(m1)} and
+\texttt{mutex\_unlock(m2)} primitives cannot be changed without
+modifying the corresponding \texttt{mutex\_lock()}.
+
+\paragraph{Note:}
+
+NOP Mutexes can be statically allocated. See
+\texttt{include/modules/nop.h} for details.
+
+\paragraph{Note:}
+
+A task can use NOP mutexes with other mutexes with different
+protocol (for example, PI, PC, SRP mutexes). We don't know the
+behaviour of that choice, but, if you want to try, it works!
+
+\paragraph{Files:}
+
+\texttt{modules/nop/*}
+
+\paragraph{Implementation hints:}
+
+The implementation of the NOP mutexes is similar to the internal
+semaphores.
+
+%----------------------------------------------------------------------------
+\section{NOPM (NO Protocol Multiple lock)}
+%----------------------------------------------------------------------------
+
+\paragraph{Resource Models Accepted:}
+
+None.
+
+\paragraph{Description:}
+
+The NOP Module implements a binary semaphore using the mutex
+interface. If a task owns a mutex, it can lock that mutex again.
+It is like the NOP Module, but the owner of the mutex can issue
+multiple lock/unlock on mutex. This protocol can produce priority
+inversions and chained blocking.
+
+\paragraph{Exceptions Raised:}
+
+None
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{NOPM\_register\_module();}
+
+The NOPM protocol uses the default mutex mechanism provided by the
+Kernel. In that way, the NOPM behaviour for a mutex can be set at
+run-time, and the applications can choose the protocol of their
+mutexes without changing the task source code.
+
+To initialize a NOPM mutex, you need to call
+\texttt{mutex\_init()} passing a previously initialized
+\texttt{NOPM\_mutexattr\_t}.
+
+In the following example, the demo task uses two resources,
+labeled with \texttt{m1} and \texttt{m2}, and accesses three
+different critical sections:
+
+\begin{tt}
+\begin{verbatim}
+#include <modules/nopm.h>
+...
+
+mutex_t m1, m2;
+...
+
+void *demo(void *arg) {
+ ...
+
+ mutex_lock(&m1);
+
+ /* critical section of m1 */
+ ...
+
+ mutex_unlock(&m1);
+ ...
+
+ mutex_lock(&m1);
+
+ /* only m1 locked */
+ ...
+
+ mutex_lock(&m2);
+
+ /* m1 and m2 locked */
+ ...
+
+ mutex_unlock(&m2); /* NOTE: first m2, then m1! */
+ mutex_unlock(&m1);
+ ...
+
+ return 0;
+}
+
+...
+
+int main(int argc, char **argv) {
+ HARD_TASK_MODEL m;
+ PID p0, p1, p2;
+
+ NOPM_mutexattr_t a;
+
+ /* Initialize the NOP mutexes */
+ NOPM_mutexattr_default(a);
+ mutex_init(&m1, &a);
+ mutex_init(&m2, &a);
+ ...
+
+ /* Create the task */
+ hard_task_default_model(m);
+ hard_task_def_mit(m, 1000000);
+ hard_task_def_wcet(m, 80000);
+ p0 = task_create("DEMO", demo, &m, NULL);
+ ...
+}
+\end{verbatim}
+\end{tt}
+
+Critical sections must be properly nested (like Chinese boxes):
+hence the order of the \texttt{mutex\_unlock(m1)} and
+\texttt{mutex\_unlock(m2)} primitives cannot be changed without
+modifying the corresponding \texttt{mutex\_lock()}.
+
+\paragraph{Note:}
+
+A task can use NOPM mutexes with other mutexes with different
+protocol (for example, PI, PC, SRP mutexes). We don't know the
+behaviour of that choice, but, if you want to try, it works!
+
+\paragraph{Files:}
+
+\texttt{modules/nopm/*}
+
+\paragraph{Implementation hints:}
+
+The implementation of the NOPM mutexes is similar to the NOP
+implementation, except that it counts the numer of times a task
+locked a mutex.
+
+%----------------------------------------------------------------------------
+\section{NPP (Non Preemptive Protocol)}
+%----------------------------------------------------------------------------
+
+\paragraph{Resource Models Accepted:}
+
+None.
+
+\paragraph{Description:}
+
+The NPP Module implements a binary semaphore using the mutex
+interface. The difference with the NOP Module is that when a task
+lock a NPP mutex, it became non-preemptive as it called the
+\texttt{task\_nopreempt()} primitive. Critical section can be
+nested.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XMUTEX\_OWNER\_KILLED]This exception is raised when a task
+ends and it owns one or more mutexes.
+\end{description}
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{NPP\_register\_module();}
+
+The NPP protocol uses the default mutex mechanism provided by the
+Kernel. In that way, the NPP behaviour for a mutex can be set at
+run-time, and the applications can choose the protocol of their
+mutexes without changing the task source code.
+
+To initialize a NPP mutex, you need to call \texttt{mutex\_init()}
+passing a previously initialized \texttt{NPP\_mutexattr\_t}.
+
+In the following example, the demo task uses two resources,
+labeled with \texttt{m1} and \texttt{m2}, and accesses three
+different critical sections:
+
+\begin{tt}
+\begin{verbatim}
+#include <modules/npp.h>
+...
+
+mutex_t m1,m2;
+...
+
+void *demo(void *arg) {
+ ...
+
+ mutex_lock(&m1);
+
+ /* critical section of m1 */
+ ...
+
+ mutex_unlock(&m1);
+ ...
+
+ mutex_lock(&m1);
+
+ /* only m1 locked */
+ ...
+
+ mutex_lock(&m2);
+
+ /* m1 and m2 locked */
+ ...
+
+ mutex_unlock(&m2); /* NOTE: first m2, then m1! */
+ mutex_unlock(&m1);
+ ...
+
+ return 0;
+}
+
+...
+
+int main(int argc, char **argv) {
+ HARD_TASK_MODEL m;
+ PID p0, p1, p2;
+ NPP_mutexattr_t a;
+
+ /* Initialize the NOP mutexes */
+ NPP_mutexattr_default(a);
+ mutex_init(&m1,&a);
+ mutex_init(&m2,&a);
+ ...
+
+ /* Create the task */
+ hard_task_default_model(m);
+ hard_task_def_mit(m, 1000000);
+ hard_task_def_wcet(m, 80000);
+ p0 = task_create("DEMO", demo, &m, NULL);
+ ...
+}
+\end{verbatim}
+\end{tt}
+
+Critical sections must be properly nested (like Chinese boxes):
+hence the order of the \texttt{mutex\_unlock(m1)} and
+\texttt{mutex\_unlock(m2)} primitives cannot be changed without
+modifying the corresponding \texttt{mutex\_lock()}.
+
+\paragraph{Note:}
+
+A task can use NPP mutexes with other mutexes with different
+protocol (for example, PI, PC, SRP mutexes; except for nested
+critical sections). We don't know the behaviour of that choice,
+but, if you want to try, it works!
+
+\paragraph{Files:}
+
+\texttt{modules/npp/*}
+
+\paragraph{Implementation hints:}
+
+The implementation of the NPP Module counts the number of locks a
+task issued and uses
+\texttt{task\_preempt()}/\texttt{task\_nopreempt()} to implement
+the protocol.
+
+%----------------------------------------------------------------------------
+\section{PC (Priority Ceiling)}
+%----------------------------------------------------------------------------
+
+\paragraph{Resource Models Accepted:}
+
+\begin{description}
+\item [PC\_RES\_MODEL]- Task priority. This model have to be used
+to tell to the PC Module that a task have to be scheduled
+following the PC rules. The model can be passed at creation time
+to more than one task, and it only contains the priority
+information.
+\end{description}
+
+\paragraph{Description:}
+
+This Module implements the Priority Ceiling (PC) Protocol. This
+mechanism can be easily applied to Fixed Priority Scheduling to
+bound blocking times and to eliminate chained blocking and
+deadlocks.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XMUTEX\_OWNER\_KILLED]This exception is raised when a task
+ends and it owns one or more PC mutexes.
+\end{description}
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{PC\_register\_module();}
+
+The PC protocol uses the default mutex mechanism provided by the
+Kernel. In that way, the PC behaviour for a mutex can be set at
+run-time, and the applications can choose the protocol of their
+mutexes without changing the task source code.
+
+To initialize a PC mutex, you need to call \texttt{mutex\_init()}
+passing a previously initialized \texttt{PC\_mutexattr\_t}, that
+contains the ceiling of the mutex.
+
+To apply the Priority Ceiling protocol to a task, you need to tell the Module
+what is the priority of that task \footnote{Also a task that have to be
+scheduled using the PC rules but without using any PC mutex must declare its
+priority!}. That information is given ti the Module using a Resource Model of
+type \texttt{PC\_RES\_MODEL} at task creation time (in other words, to the
+\texttt{task\_createn} primitive). That model have to be previously initialized
+with the priority of the task.
+
+Note that the priority value used by the PC Module may differ from
+the priority of the scheduling algorithm that really schedule the
+tasks. Typically, priorities are set to the same (or equipollent)
+values.
+
+In the following example, the demo task uses two resources,
+labeled with \texttt{m1} and \texttt{m2}, and accesses three
+different critical sections:
+
+\begin{tt}
+\begin{verbatim}
+#include <modules/pc.h>
+...
+
+mutex_t m1,m2;
+...
+
+void *demo(void *arg) {
+ ...
+
+ mutex_lock(&m1);
+
+ /* critical section of m1 */
+ ...
+
+ mutex_unlock(&m1);
+ ...
+
+ mutex_lock(&m1);
+
+ /* only m1 locked */
+ ...
+
+ mutex_lock(&m2);
+
+ /* m1 and m2 locked */
+ ...
+
+ mutex_unlock(&m2); /* NOTE: first m2, then m1! */
+ mutex_unlock(&m1);
+ ...
+
+ return 0;
+}
+...
+
+int main(int argc, char **argv) {
+ HARD_TASK_MODEL m;
+ PID p0, p1, p2;
+
+ PC_mutexattr_t a;
+ PC_RES_MODEL r;
+
+ /* Initialize the SRP mutexes */
+ PC_mutexattr_default(a,1); /* 1 is the pr. level */
+ mutex_init(&m1,&a);
+ mutex_init(&m2,&a);
+ ...
+
+ /* Create the task */
+ hard_task_default_model(m);
+ hard_task_def_mit(m, 1000000);
+ hard_task_def_wcet(m, 80000);
+ PC_res_default_model(r, 1); /* set the task Priority */
+
+ p0 = task_create("DEMO", demo, &m, &r);
+ ...
+}
+\end{verbatim}
+\end{tt}
+
+Critical sections must be properly nested (like Chinese boxes):
+hence the order of the \texttt{mutex\_unlock(m1)} and
+\texttt{mutex\_unlock(m2)} primitives cannot be changed without
+modifying the corresponding \texttt{mutex\_lock()}.
+
+The Module also provides three functions that are used to
+implement similar POSIX functions. Typically the user does not
+need to call them.
+
+\texttt{int PC\_get\_mutex\_ceiling(const mutex\_t *mutex, DWORD
+*ceiling);}
+
+This function gets the ceiling of a PC mutex, and it have to be
+called only by a task that owns the mutex. Returns -1 if the mutex
+is not a PC mutex, 0 otherwise.
+
+\texttt{int PC\_set\_mutex\_ceiling(mutex\_t *mutex, DWORD
+ceiling, DWORD *old\_ceiling);}
+
+This function sets the ceiling of a PC mutex, and it have to be
+called only by a task that owns the mutex. Returns -1 if the mutex
+is not a PC mutex, 0 otherwise.
+
+\texttt{void PC\_set\_task\_ceiling(RLEVEL r, PID p, DWORD
+priority);}
+
+This function sets the priority of a task.
+
+\paragraph{Note:}
+
+The Real-Time Literature typically found a feasibility test for
+the scheduling only in the case that all hard tasks use the PC
+protocol. Note that the Module is written in a way that only the
+tasks that declared their Priority will use the PC protocol. If a
+task that does not have a Priority, it is not scheduled using the
+PC protocol, also if it is inserted in the same scheduling queue
+of PC tasks.
+
+\paragraph{Note:}
+
+A task can use PC mutexes with other mutexes with different
+protocol (for example, PI, SRP, NOP mutexes). We don't know the
+behaviour of that choice, but, if you want to try, it works!
+
+\paragraph{Files:}
+
+\texttt{modules/pc/*}
+
+\paragraph{Implementation hints:}
+
+The PC Module uses the shadow mechanism to implement its
+behaviour. It keeps track of all the locked mutexes to block
+(setting the shadow field to the mutex owner) a task that requires
+a lock on a mutex with ceiling less than the system ceiling. When
+unlocking, all the shadows are reset. At that point they will try
+again to reaquire the mutex, that time starting from the highest
+priority task in the scheduling queue.
+
+%----------------------------------------------------------------------------
+\section{PI (Priority Inheritance)}
+%----------------------------------------------------------------------------
+
+\paragraph{Resource Models Accepted:}
+
+None.
+
+\paragraph{Description:}
+
+This Module implements the Priority Inheritance mechanism. This
+mechanism can be easily applied to Fixed Priority Scheduling to
+bound blocking times.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XMUTEX\_OWNER\_KILLED]This exception is raised when a task
+ends and it owns one or more PI mutexes.
+\end{description}
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{PI\_register\_module();}
+
+The PI protocol uses the default mutex mechanism provided by the
+Kernel. In that way, the PI behaviour for a mutex can be set at
+run-time, and the applications can choose the protocol of their
+mutexes without changing the task source code.
+
+To initialize a PI mutex, you need to call \texttt{mutex\_init()}
+passing a previously initialized \texttt{PI\_mutexattr\_t}.
+
+In the following example, the demo task uses two resources,
+labeled with \texttt{m1} and \texttt{m2}, and accesses three
+different critical sections:
+
+\begin{tt}
+\begin{verbatim}
+#include <modules/pi.h>
+...
+
+mutex_t m1,m2;
+...
+
+void *demo(void *arg) {
+ ...
+
+ mutex_lock(&m1);
+
+ /* critical section of m1 */
+ ...
+
+ mutex_unlock(&m1);
+ ...
+
+ mutex_lock(&m1);
+
+ /* only m1 locked */
+ ...
+
+ mutex_lock(&m2);
+
+ /* m1 and m2 locked */
+ ...
+
+ mutex_unlock(&m2); /* NOTE: first m2, then m1! */
+ mutex_unlock(&m1);
+ ...
+
+ return 0;
+}
+...
+
+int main(int argc, char **argv) {
+ HARD_TASK_MODEL m;
+ PID p0, p1, p2;
+
+ PI_mutexattr_t a;
+
+ /* Initialize the SRP mutexes */
+ PI_mutexattr_default(a);
+ mutex_init(&m1,&a);
+ mutex_init(&m2,&a);
+ ...
+
+ /* Create the task */
+ hard_task_default_model(m);
+ hard_task_def_mit(m, 1000000);
+ hard_task_def_wcet(m, 80000);
+ p0 = task_createn("DEMO", demo, &m, NULL);
+ ...
+}
+\end{verbatim}
+\end{tt}
+
+Critical sections must be properly nested (like Chinese boxes):
+hence the order of the \texttt{mutex\_unlock(m1)} and
+\texttt{mutex\_unlock(m2)} primitives cannot be changed without
+modifying the corresponding \texttt{mutex\_lock()}.
+
+\paragraph{Note:}
+
+A task can use PI mutexes with other mutexes with different
+protocol (for example, SRP, PC, NOP mutexes). We don't know the
+behaviour of that choice, but, if you want to try, it works!
+
+\paragraph{Files:}
+
+\texttt{modules/pi/*}
+
+\paragraph{Implementation hints:}
+
+This is the simplest protocol that can be implemented using the
+shadows mechanism. The implementation set the shadow field when a
+task blocks, and reset it when the mutex is unlocked. At that
+point, the highest priority free task will lock the mutex.
+
+%----------------------------------------------------------------------------
+\section{SEM (POSIX Semaphores)}
+%----------------------------------------------------------------------------
+
+\paragraph{Description:}
+
+This module implements the POSIX Semaphores as described in the
+Volume I of the User Manual.
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{SEM\_register\_module();}
+
+\paragraph{Files:}
+
+\texttt{modules/sem/*}
+
+\paragraph{Implementation hints:}
+
+The implementation uses a fixed number of semaphores (note that
+Internal Semaphores does not!). Note the use of
+\texttt{task\_testcancel()} to implement the cancellation points.
+
+%----------------------------------------------------------------------------
+\section{SRP (Stack Resource Policy)}
+%----------------------------------------------------------------------------
+
+\paragraph{Resource Models Accepted:}
+
+\begin{description}
+\item [SRP\_RES\_MODEL]- Preemption levels. This model have to be
+used to tell to the SRP Module that a task have to be scheduled
+following the SRP rules. The model can be passed at creation time
+to more than one task, and it only contains the preemption level
+information.
+\end{description}
+
+\paragraph{Description:}
+
+\emph{Stack Resource Policy} (SRP) is a mutual exclusion mechanism
+suitable for hard real-time tasks, that can be used with static or
+dynamic scheduling algorithms. Its main feature is the property
+that a task is blocked not when it tries to use the resource, but
+when it tries to preempt another task owning the shared resource.
+This early blocking simplifies the protocol implementation and
+reduces the number of context switches, increasing the system
+efficiency.
+
+This SRP implementation provides a simplified version of the protocol, suitable
+only for single-unit resources, that defines a particular behaviour for the
+\texttt{mutex\_XXX} primitives. Moreover, it is implemented using the shadows
+mechanism (described in the S.Ha.R.K. architecture manual), so there is no
+restriction on the Task Models of the tasks that will use SRP \footnote{However,
+note that a schedulability test is only available for EDF and RM schedulers.}.
+
+SRP is implemented associating a dynamic priority $p(\tau)$ and a
+preemption level $\pi(\tau)$ to each task $\tau$. If an EDF
+scheduler is used to schedule the tasks that use SRP, we can say
+that the priority $p(\tau)$ of task $\tau$ is proportional to
+$1/d$, where $d$ is the task's absolute deadline, while the
+preemption level $\pi(\tau)$ is proportional to $1/D$, where $D$
+is the tasks's relative deadline.
+
+Each resource is assigned a dynamic \emph{priority ceiling}
+$C_{R}$, defined as:
+\[
+C_{R}=max\{0\},\;\{\pi(\tau):R\in R(\tau)\, and\, Rsbusy\}
+\]
+
+\noindent where $R(\tau)$ is the set of all resources used by task
+$\tau$. According to this definition, if a resource is free, its
+ceiling is 0; if a resource is busy, its ceiling is the maximum
+among the preemption levels of tasks using it. A \emph{System
+Ceiling} $\Pi_{S}$ is also defined as the maximum ceiling among
+all the resources:
+\[
+\Pi_{S}\;=\; max_{r}\{ C_{r}\;:\; r=1,\ldots,m\}.
+\]
+
+Starting from these definitions, the SRP works according to the
+following rule:
+
+\begin{quote}
+\emph{The execution of a task is delayed until it becomes the task
+having the highest priority and its preemption level is strictly
+greater than the system ceiling.}
+\end{quote}
+
+Two tests are needed to allow a task to execute: a test on its
+priority (i.e., the deadline, which is dynamically assigned) and a
+test on the preemption level (which is statically determined).
+
+The SRP protocol ensures that a task $\tau$, once started, cannot
+be blocked on any resource until it terminates. Consequently, SRP
+avoids unbounded priority inversion, blocking chains, and
+deadlocks. It also reduces the number of context switches and
+simplifies the implementation of the mechanism.
+
+Since the SRP may be applied on various Scheduling Modules with
+different scheduling policies, no guarantee or blocking time
+calculations are performed by the Kernel.
+
+The tasks that use SRP mutexes must declare the use of a shared
+resource, using the provided resource modules.
+
+Finally, note that this implementation of SRP is NOT compatible
+with the join primitive. If a task that uses SRP mutexes calls
+\texttt{task\_join} or \texttt{pthread\_join}, the result is
+undefined.
+
+\paragraph{Exceptions Raised:}
+
+\begin{description}
+\item [XMUTEX\_OWNER\_KILLED]This exception is raised when a task
+ends and it owns one or more SRP mutexes. \item
+[XSRP\_UNVALID\_LOCK]This exception is raised when a task try to
+lock a srp mutex but it don't have the privilege.
+\end{description}
+
+\paragraph{Usage:}
+
+To register this module, just put this line into the
+\texttt{\_\_kernel\_register\_levels\_\_} function:
+
+\texttt{SRP\_register\_module();}
+
+The SRP protocol uses the default mutex mechanism provided by the
+Kernel. In that way, the SRP behaviour for a mutex can be set at
+run-time, and the applications can choose the protocol of their
+mutexes without changing the task source code.
+
+To initialize a SRP mutex, you need to call \texttt{mutex\_init()}
+passing a previously initialized \texttt{SRP\_mutexattr\_t}.
+
+To use a SRP mutex, you need to tell the Module two kind of
+informations:
+
+\begin{itemize}
+\item First, every task that have to be scheduled following the SRP rules must
+have a (fixed) preemption level \footnote{Also a task that have to be scheduled
+using the SRP rules but without using any SRP mutex must declare its preemption
+level!}.
+\item Second, every task must declare the mutexes that it will use during its
+life.
+\end{itemize}
+
+All the two informations have to be given to the Module using
+Resource Models.
+
+To set a task preemption level you need to pass an
+\texttt{SRP\_RES\_MODEL} at task creation time (in other words, to
+the \texttt{task\_createn} primitive). That model have to be
+previously initialized with the preemption level of the task.
+
+To declare that a task will use a particular mutex, you have to
+pass another Resource Model at task creation time. The Model you
+need to pass is returned by the following function:
+
+\texttt{RES\_MODEL *SRP\_usemutex(mutex\_t *m);}
+
+where \texttt{m} is the SRP mutex the task will use.
+
+In the following example, the demo task uses two resources,
+labeled with \texttt{m1} and \texttt{m2}, and accesses three
+different critical sections:
+
+\begin{tt}
+
+\begin{verbatim}
+ #include <modules/srp.h>
+...
+
+mutex_t m1,m2;
+...
+
+void *demo(void *arg) {
+ ...
+
+ mutex_lock(&m1);
+
+ /* critical section of m1 */
+ ...
+
+ mutex_unlock(&m1);
+ ...
+
+ mutex_lock(&m1);
+ /* only m1 locked */
+ ...
+
+ mutex_lock(&m2);
+
+ /* m1 and m2 locked */
+ ...
+
+ mutex_unlock(&m2); /* NOTE: first m2, then m1! */
+ mutex_unlock(&m1);
+ ...
+
+ return 0;
+}
+...
+
+int main(int argc, char **argv) {
+ HARD_TASK_MODEL m;
+ PID p0, p1, p2;
+
+ SRP_mutexattr_t a;
+ SRP_RES_MODEL r;
+
+ /* Initialize the SRP mutexes */
+
+ SRP_mutexattr_default(a);
+ mutex_init(&m1,&a);
+ mutex_init(&m2,&a);
+ ...
+
+ /* Create the task */
+ hard_task_default_model(m);
+ hard_task_def_mit(m, 1000000);
+ hard_task_def_wcet(m, 80000);
+ SRP_res_default_model(r, 3); /* set the task Preemption level */
+ p0 = task_createn("DEMO", demo, &m, &r, SRP_usemutex(&m1),
+SRP_usemutex(&m2), NULL);
+ ...
+}
+\end{verbatim}
+\end{tt}
+
+Critical sections must be properly nested (like Chinese boxes):
+hence the order of the \texttt{mutex\_unlock(m1)} and
+\texttt{mutex\_unlock(m2)} primitives cannot be changed without
+modifying the corresponding \texttt{mutex\_lock()}.
+
+\paragraph{Note:}
+
+The Real-Time Literature typically found a feasibility test for the scheduling
+only in the case that all hard tasks use the SRP protocol. Note that the Module
+is written in a way that only the tasks that declared their Preemption Level
+will use the SRP protocol. If a task that does not have a Preemption Level
+\footnote{i.e., it was created without passing a \texttt{SRP\_RES\_MODEL} to the
+\texttt{task\_createn} primitive.}, it is not scheduled using the SRP protocol,
+also if it is inserted in the same scheduling queue of SRP tasks.
+
+\paragraph{Note:}
+
+A task can use SRP mutexes with other mutexes with different
+protocol (for example, PI, PC, NOP mutexes). We don't know the
+behaviour of that choice, but, if you want to try, it works!
+
+\paragraph{Files:}
+
+\texttt{modules/srp/*}
+
+\paragraph{Implementation hints:}
+
+Notes about the implementation of SRP are inserted in the heading
+the source file \texttt{modules/srp/srp.c}.
+
+%----------------------------------------------------------------------------
+\chapter{File system Modules}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\section{BD\_EDF}
+%----------------------------------------------------------------------------
+
+TBD
+
+%----------------------------------------------------------------------------
+\section{BD\_PSCAN}
+%----------------------------------------------------------------------------
+
+TBD
+
+\printindex{}
+
+\bibliographystyle{alpha}
+\bibliography{../common/biblio}
+
+\end{document}
/branches/new_sharkdoc/vol3/vol3.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol3/images/budget1.fig
===================================================================
--- branches/new_sharkdoc/vol3/images/budget1.fig (nonexistent)
+++ branches/new_sharkdoc/vol3/images/budget1.fig (revision 1676)
@@ -0,0 +1,120 @@
+#FIG 3.2
+Portrait
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+0 32 #b6bab6
+0 33 #dfdfdf
+6 -135 720 135 945
+4 0 0 50 -1 0 12 0.0000 4 165 135 -135 855 Q\001
+4 0 0 50 -1 32 12 0.0000 4 135 105 0 945 q\001
+-6
+6 -250 1750 105 1930
+4 0 0 50 -1 0 12 0.0000 4 180 210 -105 1885 (t)\001
+4 0 0 50 -1 32 12 0.0000 4 135 150 -250 1905 F\001
+-6
+6 5850 900 6615 1620
+2 2 0 1 0 7 50 -1 20 0.000 0 0 -1 0 0 5
+ 5850 1080 6030 1080 6030 900 5850 900 5850 1080
+2 2 0 1 0 33 50 -1 20 0.000 0 0 -1 0 0 5
+ 5850 1350 6030 1350 6030 1170 5850 1170 5850 1350
+2 2 0 1 0 32 50 -1 20 0.000 0 0 -1 0 0 5
+ 5850 1620 6030 1620 6030 1440 5850 1440 5850 1620
+4 0 0 50 -1 0 12 0.0000 4 135 270 6165 1035 idle\001
+4 0 0 50 -1 0 12 0.0000 4 180 420 6165 1305 ready\001
+4 0 0 50 -1 0 12 0.0000 4 90 270 6165 1575 exe\001
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 180 1350 180 0
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 180 1170 5670 1170
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 180 810 5400 810
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 180 1170 1440 540
+2 1 0 1 0 33 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1440 540 2160 900
+2 1 0 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2160 900 2520 720
+2 1 0 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2520 720 3240 1080
+2 1 0 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3240 1080 3600 900
+2 1 0 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3600 900 4320 1260
+2 1 0 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 4320 1260 5400 720
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 180 1980 5670 1980
+2 2 0 1 0 7 50 -1 20 0.000 0 0 -1 0 0 5
+ 180 1980 900 1980 900 1710 180 1710 180 1980
+2 2 0 1 0 33 50 -1 20 0.000 0 0 -1 0 0 5
+ 900 1980 1440 1980 1440 1710 900 1710 900 1980
+2 2 0 1 0 32 50 -1 20 0.000 0 0 -1 0 0 5
+ 1440 1980 2160 1980 2160 1710 1440 1710 1440 1980
+2 2 0 1 0 33 50 -1 20 0.000 0 0 -1 0 0 5
+ 2160 1980 2520 1980 2520 1710 2160 1710 2160 1980
+2 2 0 1 0 32 50 -1 20 0.000 0 0 -1 0 0 5
+ 2520 1980 3240 1980 3240 1710 2520 1710 2520 1980
+2 2 0 1 0 33 50 -1 20 0.000 0 0 -1 0 0 5
+ 3240 1980 3600 1980 3600 1710 3240 1710 3240 1980
+2 2 0 1 0 32 50 -1 20 0.000 0 0 -1 0 0 5
+ 3600 1980 4320 1980 4320 1710 3600 1710 3600 1980
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 180 450 5400 450
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 900 1710 900 810
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 1440 1710 1440 540
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2160 1710 2160 900
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2520 1710 2520 720
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3240 1710 3240 1080
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3600 1710 3600 900
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 4320 1710 4320 1260
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 45.00 90.00
+ 3600 2340 3600 2025
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 45.00 90.00
+ 2520 2340 2520 2025
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 45.00 90.00
+ 1440 2340 1440 2025
+2 2 0 1 0 33 50 -1 20 0.000 0 0 -1 0 0 5
+ 5220 1980 5400 1980 5400 1710 5220 1710 5220 1980
+2 2 0 1 0 7 50 -1 20 0.000 0 0 -1 0 0 5
+ 4320 1980 5220 1980 5220 1710 4320 1710 4320 1980
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 5220 1710 5220 810
+4 1 0 50 -1 0 12 0.0000 4 135 45 540 1890 i\001
+4 1 0 50 -1 0 12 0.0000 4 90 60 1170 1890 r\001
+4 1 0 50 -1 0 12 0.0000 4 90 90 1800 1890 e\001
+4 1 0 50 -1 0 12 0.0000 4 90 60 2340 1890 r\001
+4 1 0 50 -1 0 12 0.0000 4 90 60 3420 1890 r\001
+4 1 0 50 -1 0 12 0.0000 4 90 90 2880 1890 e\001
+4 1 0 50 -1 0 12 0.0000 4 90 90 3960 1890 e\001
+4 1 0 50 -1 0 12 0.0000 4 135 375 1800 1620 ISR1\001
+4 1 0 50 -1 0 12 0.0000 4 135 375 2880 1620 ISR2\001
+4 1 0 50 -1 0 12 0.0000 4 135 375 3960 1620 ISR3\001
+4 0 0 50 -1 0 12 0.0000 4 180 345 -315 135 Q(t)\001
+4 0 0 50 -1 0 12 0.0000 4 165 135 -315 495 Q\001
+4 0 0 50 -1 0 8 0.0000 4 60 210 -180 540 max\001
+4 0 0 50 -1 0 12 0.0000 4 135 90 -45 1170 0\001
+4 0 0 50 -1 0 12 0.0000 4 165 405 3690 2340 IRQ3\001
+4 0 0 50 -1 0 12 0.0000 4 165 405 2610 2340 IRQ2\001
+4 0 0 50 -1 0 12 0.0000 4 165 405 1530 2340 IRQ1\001
+4 0 0 50 -1 0 12 0.0000 4 105 60 5580 1440 t\001
+4 1 0 50 -1 0 12 0.0000 4 90 60 5310 1890 r\001
+4 1 0 50 -1 0 12 0.0000 4 135 45 4770 1890 i\001
/branches/new_sharkdoc/vol3/images/budget1.fig
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol3/images/budget2.fig
===================================================================
--- branches/new_sharkdoc/vol3/images/budget2.fig (nonexistent)
+++ branches/new_sharkdoc/vol3/images/budget2.fig (revision 1676)
@@ -0,0 +1,121 @@
+#FIG 3.2
+Portrait
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+0 32 #b6bab6
+0 33 #dfdfdf
+6 -135 720 135 945
+4 0 0 50 -1 0 12 0.0000 4 165 135 -135 855 Q\001
+4 0 0 50 -1 32 12 0.0000 4 135 105 0 945 q\001
+-6
+6 -270 2300 85 2480
+4 0 0 50 -1 0 12 0.0000 4 180 210 -125 2435 (t)\001
+4 0 0 50 -1 32 12 0.0000 4 135 150 -270 2455 F\001
+-6
+6 5850 900 6615 1620
+2 2 0 1 0 7 50 -1 20 0.000 0 0 -1 0 0 5
+ 5850 1080 6030 1080 6030 900 5850 900 5850 1080
+2 2 0 1 0 33 50 -1 20 0.000 0 0 -1 0 0 5
+ 5850 1350 6030 1350 6030 1170 5850 1170 5850 1350
+2 2 0 1 0 32 50 -1 20 0.000 0 0 -1 0 0 5
+ 5850 1620 6030 1620 6030 1440 5850 1440 5850 1620
+4 0 0 50 -1 0 12 0.0000 4 135 270 6165 1035 idle\001
+4 0 0 50 -1 0 12 0.0000 4 180 420 6165 1305 ready\001
+4 0 0 50 -1 0 12 0.0000 4 90 270 6165 1575 exe\001
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 180 1755 180 0
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 180 450 5400 450
+2 1 0 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 180 540 360 450
+2 1 0 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 360 450 900 450
+2 1 0 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 900 450 1620 810
+2 1 0 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 1620 810 2340 1170
+2 2 0 1 0 32 50 -1 20 0.000 0 0 -1 0 0 5
+ 2340 2520 3060 2520 3060 2250 2340 2250 2340 2520
+2 2 0 1 0 32 50 -1 20 0.000 0 0 -1 0 0 5
+ 1620 2520 2340 2520 2340 2250 1620 2250 1620 2520
+2 2 0 1 0 32 50 -1 20 0.000 0 0 -1 0 0 5
+ 900 2520 1620 2520 1620 2250 900 2250 900 2520
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 45.00 90.00
+ 900 2880 900 2565
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 45.00 90.00
+ 1485 2880 1485 2565
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 45.00 90.00
+ 2070 2880 2070 2565
+2 1 0 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2340 1170 3060 1530
+2 2 0 1 0 7 50 -1 20 0.000 0 0 -1 0 0 5
+ 3060 2520 4500 2520 4500 2250 3060 2250 3060 2520
+2 2 0 1 0 33 50 -1 20 0.000 0 0 -1 0 0 5
+ 180 2520 900 2520 900 2250 180 2250 180 2520
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 900 2250 900 450
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3060 2250 3060 1530
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 4500 2250 4500 810
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 180 1170 5670 1170
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 180 2520 5670 2520
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 180 810 5400 810
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 180 1530 5400 1530
+2 1 0 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3060 1530 4500 810
+2 1 0 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 4500 810 5040 1080
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 45.00 90.00
+ 3420 2880 3420 2565
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 1620 2250 1620 810
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2340 2250 2340 1170
+2 2 0 1 0 32 50 -1 20 0.000 0 0 -1 0 0 5
+ 4500 2520 5040 2520 5040 2250 4500 2250 4500 2520
+2 2 0 1 0 33 50 -1 20 0.000 0 0 -1 0 0 5
+ 5040 2520 5400 2520 5400 2250 5040 2250 5040 2520
+2 1 1 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 5040 2205 5040 1080
+2 1 0 1 0 33 50 -1 -1 4.000 0 0 -1 0 0 2
+ 5040 1080 5400 900
+4 0 0 50 -1 0 12 0.0000 4 180 345 -315 135 Q(t)\001
+4 0 0 50 -1 0 12 0.0000 4 135 90 -45 1170 0\001
+4 1 0 50 -1 0 12 0.0000 4 90 90 1260 2430 e\001
+4 1 0 50 -1 0 12 0.0000 4 90 90 1980 2430 e\001
+4 1 0 50 -1 0 12 0.0000 4 90 90 2700 2430 e\001
+4 1 0 50 -1 0 12 0.0000 4 90 60 540 2430 r\001
+4 0 0 50 -1 0 12 0.0000 4 165 405 990 2880 IRQ1\001
+4 0 0 50 -1 0 12 0.0000 4 165 405 1575 2880 IRQ2\001
+4 0 0 50 -1 0 12 0.0000 4 165 405 2160 2880 IRQ3\001
+4 1 0 50 -1 0 12 0.0000 4 135 45 3780 2430 i\001
+4 1 0 50 -1 0 12 0.0000 4 135 375 1260 2160 ISR1\001
+4 1 0 50 -1 0 12 0.0000 4 135 375 2700 2160 ISR3\001
+4 1 0 50 -1 0 12 0.0000 4 135 375 1980 2160 ISR2\001
+4 0 0 50 -1 0 12 0.0000 4 165 135 -315 495 Q\001
+4 0 0 50 -1 0 8 0.0000 4 60 210 -180 540 max\001
+4 0 0 50 -1 0 12 0.0000 4 165 135 -315 1485 Q\001
+4 0 0 50 -1 0 8 0.0000 4 90 180 -180 1530 min\001
+4 0 0 50 -1 0 12 0.0000 4 105 60 5580 1440 t\001
+4 0 0 50 -1 0 12 0.0000 4 165 405 3510 2880 IRQ4\001
+4 1 0 50 -1 0 12 0.0000 4 90 60 5220 2430 r\001
+4 1 0 50 -1 0 12 0.0000 4 135 375 4770 2160 ISR4\001
+4 1 0 50 -1 0 12 0.0000 4 90 90 4770 2430 e\001
/branches/new_sharkdoc/vol3/images/budget2.fig
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol3/images/fsm.fig
===================================================================
--- branches/new_sharkdoc/vol3/images/fsm.fig (nonexistent)
+++ branches/new_sharkdoc/vol3/images/fsm.fig (revision 1676)
@@ -0,0 +1,65 @@
+#FIG 3.2
+Landscape
+Center
+Inches
+Letter
+100.00
+Single
+-2
+1200 2
+5 1 0 1 0 7 50 -1 -1 0.000 0 1 1 0 4865.014 -26.357 2952 2267 3915 2805 5040 2955
+ 1 1 1.00 60.00 120.00
+5 1 0 1 0 7 50 -1 -1 0.000 0 1 1 0 3318.629 4924.761 5232 2637 4230 2085 3105 1950
+ 1 1 1.00 60.00 120.00
+5 1 0 1 0 7 50 -1 -1 0.000 0 1 1 0 6304.447 2547.802 6222 2947 6525 2205 5910 2445
+ 1 1 1.00 60.00 120.00
+5 1 0 1 0 7 50 -1 -1 0.000 0 1 1 0 7631.921 2998.618 2325 2595 2400 3975 2775 5175
+ 1 1 1.00 60.00 120.00
+5 1 0 1 0 7 50 -1 -1 0.000 0 1 0 1 1414.775 1558.577 3525 5325 4575 4500 5302 3437
+ 1 1 1.00 60.00 120.00
+5 1 0 1 0 7 50 -1 -1 0.000 0 0 0 1 -2666.610 4746.062 2700 2475 3075 3750 3150 5100
+ 1 1 1.00 60.00 120.00
+5 1 0 1 0 7 50 -1 -1 0.000 0 1 1 0 1620.000 2062.500 1950 1800 1200 2025 1950 2325
+ 1 1 1.00 60.00 120.00
+5 1 0 1 0 7 50 -1 -1 0.000 0 1 1 0 2511.513 1245.395 2775 1575 2475 825 2175 1500
+ 1 1 1.00 60.00 120.00
+6 1365 2790 2100 3375
+4 2 0 50 -1 0 12 0.0000 4 135 285 2100 2925 ISR\001
+4 2 0 50 -1 0 12 0.0000 4 135 735 2100 3150 execution\001
+4 2 0 50 -1 0 12 0.0000 4 135 600 2100 3375 finishes\001
+-6
+6 1215 540 1950 1125
+4 2 0 50 -1 0 12 0.0000 4 135 285 1950 675 ISR\001
+4 2 0 50 -1 0 12 0.0000 4 135 735 1950 900 execution\001
+4 2 0 50 -1 0 12 0.0000 4 135 600 1950 1125 finishes\001
+-6
+1 3 0 3 0 7 50 -1 -1 0.000 1 0.0000 2475 2025 525 525 2475 2025 3000 2025
+1 3 0 3 0 7 50 -1 -1 0.000 1 0.0000 5625 3000 525 525 5625 3000 6150 3000
+1 3 0 3 0 7 50 -1 -1 0.000 1 0.0000 3075 5625 525 525 3075 5625 3600 5625
+4 1 0 50 -1 0 22 0.0000 4 150 420 2490 2130 exe\001
+4 1 0 50 -1 0 22 0.0000 4 225 465 5640 3090 idle\001
+4 1 0 50 -1 0 22 0.0000 4 300 705 3075 5700 ready\001
+4 0 0 50 -1 0 12 0.0000 4 180 630 4275 3225 Q(t) < 0\001
+4 2 0 50 -1 0 12 0.0000 4 135 285 3375 2775 ISR\001
+4 0 0 50 -1 0 12 0.0000 4 165 315 3225 3900 IRQ\001
+4 0 0 50 -1 0 12 0.0000 4 135 480 3300 4125 arrival\001
+4 0 0 50 -1 0 12 0.0000 4 165 840 6825 2250 IRQ arrival\001
+4 0 0 50 -1 0 12 0.0000 4 180 735 1500 3975 Q(t) >= 0\001
+4 1 0 50 -1 0 12 0.0000 4 180 630 2025 4500 queue is\001
+4 1 0 50 -1 0 12 0.0000 4 150 465 2100 4725 empty\001
+4 1 0 50 -1 0 12 0.0000 4 165 840 600 1950 IRQ arrival\001
+4 1 0 50 -1 0 12 0.0000 4 180 1350 375 2175 ISR sent to queue\001
+4 0 0 50 -1 0 12 0.0000 4 180 1350 6900 2475 ISR sent to queue\001
+4 0 0 50 -1 0 12 0.0000 4 180 735 2175 600 Q(t) >= 0\001
+4 1 0 50 -1 0 12 0.0000 4 150 750 3450 1125 not empty\001
+4 1 0 50 -1 0 12 0.0000 4 180 630 3225 900 queue is\001
+4 1 0 50 -1 0 12 0.0000 4 150 465 4575 5250 empty\001
+4 1 0 50 -1 0 12 0.0000 4 180 630 4650 5025 queue is\001
+4 1 0 50 -1 0 12 0.0000 4 180 885 5025 1950 ISR waiting\001
+4 1 0 50 -1 0 12 0.0000 4 180 630 5025 2175 in queue\001
+4 0 0 50 -1 0 12 0.0000 4 180 675 3495 1770 Q(t) = Q\001
+4 0 0 50 -1 0 12 0.0000 4 180 675 4920 4470 Q(t) = Q\001
+4 0 0 50 -1 32 12 0.0000 4 135 105 5625 4575 q\001
+4 0 0 50 -1 32 12 0.0000 4 135 105 4200 1875 q\001
+4 2 0 50 -1 0 12 0.0000 4 135 735 3825 3000 execution\001
+4 2 0 50 -1 0 12 0.0000 4 135 600 3900 3225 finishes\001
/branches/new_sharkdoc/vol3/images/fsm.fig
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol3/images/int-server1.dia
===================================================================
--- branches/new_sharkdoc/vol3/images/int-server1.dia (nonexistent)
+++ branches/new_sharkdoc/vol3/images/int-server1.dia (revision 1676)
@@ -0,0 +1,21 @@
+‹í]msÛ6þž_¡Q¿ÜÍD47餹ÜÔ3½ëµu'wŸ<´ÅȺʒGb^üå~ûᅊ$Š”d ›Ò¦“Z’¬@>û`±»Øýþ‡¯w“Þç|¾Ϧ¯û$û½|z3Ž§£×ý?.ÿ>Hú?¼yñýpœ½’Góì®'ÿÅt¡Þ½îßÅý«³³/_¾“‡EVÌæÁdü)XägÿË&“ìL^tÖó¢×[`˜™ú¬ü4+ŠùøúS‘÷¦Ù]þºÝü9šÏ>M‡}sUyÝÍl2›÷>g“×ýï>ê?ý³r˜³qvŒ}ŸòëyžýÙ<t(ÿ¤i›¡ïóyuØ»ûÙb,/)î·.iGýíšòª…¼h:zóÝÛè;ó•ÊVcÕ}ÑF!Å]6§Ûr余˜Aƒ„Rº¼q +/b/b/b¼¸ºŸÍ‹y6.¶Å\Ïf“<›IÅüSÞ^Îâ&›HÈìš
+i?úÇqQÌö|ÿÙdqÈÌÇߴ籚8š‡»q㊆Q¾Œ‡ÅíÕ×]·+ (onj€8ŸÇ‹ñõ$¯›ÃxZX?ñåðn†¯>#ÍÉ«n‰ 3Z#é“œçüñ¤?ú4æ‹=`Û¼¦a¤Ûò²³}w½zÝ¡7Æ|TY‚µˆIöÏËá\-¾½ò—¼³vf×ÿÍoŠrz¿Ùt˜Í‡½AïÇÙ×þʖ–ÄxøºÿK¸y{ª’ƒIþÛº?÷³o ð—,©Îy›7šÆ¿¾®?—Ȧ£I¾&"”BD¦ü|¨/Y„!o'6ŸäwW7³ùt{Åw65-CÓÈöôV«“Ínóñè¶h´ûz6æó}_= –㏧ò¶_mê|ƒ©†íD,ng_®jLÕýëv=»œ­«µ¦[M‹aµŒ­2:–(Ýò b1¬z¡r5(×õGõ_•ëçñ4¯Ñ.j«]ÉË( T0ÄJ£"¥]‘’Öù7³éô*Ÿõ—Ԕê.‘ߨ大Ÿînî«âëŒËGéÞtx•Íç³/Ձs)ΌÌ,G¾šäÓÑní‹mEìÕïȋV0[­k@ ¨‘YsxŸSn–œxï­±U‹Í9mÿž¶Ÿ4ˆJL䳅[0Pá\*\äÀÈ F^ü’j­;—Š¦¬½ÖÞÁú¶9¥ºßSŽê†ê¶KÝ.ó¯Eºq[u£ VßÔøRÑÎ¥Î%zsÕrq+Ôü÷øä*×4Yï:4±q]%Šqyñ÷¯zEC(c‡§°Éù<›uòÔ罏ÙÝxò ¿V6]ô{‹âA¹´äã5ÿô§|ò9/Æ7Ù:<þlíåj!›Ø ÙÚ`k#¤º±;ÈsÒFP6¦wyý“[qÕ¡Rjý  ÔÛRCHCPê-èžp)„¨M!—/¹|ùü)âÝÛ½}wqùŸW½_ÿRü™Â5SÔaéÒp wï5¦»D†Ž‡p?ÖûN’ú.­§ÞA^®Ù§Ù‚'^öš‰µsG=9
+ÚHHa
+ +Z¡Þ‘ ¤Ð ­Î¬¶¢ý쟷ÜËÎ*µ7Ÿ0ºŒ¹Õ<—F“ÂUöV!ÚJîm%QUv4”àˆXgŒ0e¸PHc‰)C)æ’¸‰.t`K5èýôáÝûKä×ü°7äP~ N,* -kˁJQ]°~Ef±(zd}1µgù¼RPbÍ LJêD´æ'$÷Ä°‰3äH?aö¾WPV0¾Wš,}¯BjR/¾×MÖ;±ÚÎýH¯Ô‹ó•8Èô¡´ñhý¤ûPqh‚Ö{ĀpûÊŽ„%[©C7&%”›Sà)¡ÕiÕe…ígŽ‰j'žJbËEaNҔ%jɐ/¢s0Œµ{$–/<¬ÁÎ@³èâšA¸x ûã/ ÖˆX·FÊÃeă1’ì1F’N†€ +毉=^AcË
+¯Œ¦fÓÇØ9¡¬±0 8jw'/Š›¾'­uV„€¥YɯÔÐ,Õ4+̞O@Ó¬ØK³¸v7ž\ +ŸÿÚ½‰ý¡jßâMb„U3¬¬ã°ØCEø:°hèXd¯*Dd5Æñ(µ_Y{®"¨Ð^$ÂåFVhïN'NV|x{9@Îz[€;†ˆyúˆ^}¥ÊìîpoDYêFoí|ÔºI@kÝDXëæè
+I5-ÀÖ±G‚¯À©*/ ×_šÂ7]X~ßÿû=®¾®Wßm´-¿›¥‡}ùmÚúY‡yS¢‡®‡•Œ—±ˆÚ¼ø(‰U7±†«°0Ö¡ÖñØD¥ @«ÈRˆ\E¥¶¼ŒH'ыß0YÝù"Z‡7ÌKåáÀ̆f#BYÙ$»Xdˆ“6³‘|šÙÖI º¾88Cu:ޘÙ$H}XÙuój¸
+­ìc°²üÀ©ƒ$¨#˜l=W!H/ž`£+]Á4ŒYçŽÐXÃÒ + +3çPà5ÌbZiXë%»ËJö,ƒ!Œ8°Â„3L,}9„qW¶jªìo¸Ys¾Y#µžhܯÁ­•Ô¾ÕƒouÅ6Z]I˜Džz]1è^Wh•6hçÑ5ãaÌMW9è5y "Æ72Ð~ΑÁaޑºGŽýP(‹ìÕ$ €[ôhaÙ¤§ìÃߣg{b5&T€zP÷Úê·×=¡(@uOšË~=ê +ñÓ±g{jM×`çÔ¿vnëœA®~Z‚*Itªvï9eÍÞÐ[JÂ~N}´ðY‰!j‘–‹5¶ñAÊ؁@ä +PÃ>qdØs`Ã^懶iOLÞ÷gÚïNÌÁ~>OQ¥ÜA°eq”[&¤ßZúsÊÚGGŸêÔêÜAú4ÛSQèÂÙÝÓg)CuõQ¯#ìësºÆS‚}|î¸"ëLšÕ{dàî>¥ÝáG{H±ÇÏÉsEð-@ق:²'¨€·'t¯õša·Ÿ·'°ß7†p”ÂvöÐ’’(vü9eO-vüñ棍"7>Z`n0>Ú²ïr/yjû³=¹o~‚Î?‘£Ì!*|€7^¯¿Ü¡=…{5x±ÿC»ØµA÷22–]€–‡r}äœîo„=€0å­¥î 7§"h|$B/•H¡úÔËÉšp," 0Bí¿ÿE”¸ApûÇ÷ ÇBoíU÷–P?ij` Þ¾¥n’5W Ólü@N»BŦ%‚j0HL»„ÄCƒ„ƒ˜8m=ýãï‘Àd[„ÚM ³Wà YvJ¤A̱TóIûAëP‡åšëpâ(a5ñ‘°ºÜ0ou p]‚ ù<‡RVÜ>Ÿ ցÔx¢J¾4 …? 8æ8•ÂÜ>$/|Ô嫲ÂSUqPQ59Žû\2\x¨ŸÚ5ߚh³‹Ÿôƍ`ƒÏ nœ;XM©—åtÅ<ˆ°ôäiS…@¦ðœðÆíÓ.˜»›­ìnæÉîfÙÝ íî£nÀ…õÿl”f +Íx÷Cÿ'v p£dö鸒Eqoa†XËjÙÑ9Y›¶…©ƒµŒz±öÖH¸-<õm!Ãm¡çma:
+ýàІ±ÊCKÒ4Ò9ÁL¾P¥Yˆü…ŸŠUdVð1¦£}S¹˜Þ=‹-–]þ¦w+ñVT135Ž{«_o(Âë•QÁš8åÓ¸ŠHªò(«É•iÀàKYmM“+‡/Ú +|)r¤*a—iÚê'K4È8<m‚²Î¦ ûBš›|‰ö·øÐøNyP9ZKL">NìlÏ®)i‚àA‡'8èG]°0Vkq¤~h™ây8BšÜ2îeí9âpšŒÑe^ô±0¶<F¼ ۞cƒ»Ÿ¦H–OA–±ÿxìߢJú8Våã&:°Øl\ÒrãÂʍ‹„™Ï8ë,Iú™u¤/´ºÃÇӅ–¢¨,\¾7ú¶ç†{<ÄR'0Œ­…“™­1;eêë µçÝÚ¡›”#à8!jã@#FuÞQœ„©Aqì%?osŽõ„ª¾ÂÆõ9=‚¸Ùz'ðþÉeNOä+§úä0ܞ£ËœkÈ骝óÀG98 â[= íLE‹¿ýŒ%=N†Õïòzȳ=&T>§^؂”®Ø‚Bt†->¼½ÀN*lA‘-üf
+ë-¡°¥Ð%1¤éªzY‘—y¨&]™YíŒá¶Ó¿÷„;mÛ'w8hÓ½*U´WZÆ¡*
+ªq ì­Ì®æ‚¸“Í*»\ë ¯Å“; ¸\³­Æ-7°õÔ¸2³ú ÐÉ÷ .@Ë¡AkØVçÖP^²-÷¶ñž–Ök†?‘:qa'$ðÆmé^Ò-¸wÚbZxªû4}ÓM‹ƒu$ž†°ÝˆHjN×Äú¬ +ÕÙjÚOõ¨Ì¬ö‚î=åx$¡dÁnòR}&Q-î:WMš*EMËCªZevÇcvxª’ŸX¯Iî$W¥®K9‰‚Ë㟰w|nX” ¬Ãî$'±"ˆ â´ "A‚ðJ֑vJ}´Ù¡¦•“a )2ŬœÓ&ŠZØaœ”+ìãìúäH šðmdð UÆ1N“Nïþ¸¼ø埽¿üöûeïÝÛߑ4Ü[ÛøÃ] 0îâÅшƒ(#4õÖÏÑI‘ð…Œjææú á øXãn@Œ¥BÕNPg€#!ÎiÀ8Uñ^¢_<¤‹*ìâ1$×X«Å& ÔX*[‹ÅÊGé#Ÿj_Ç› 6j€y?Éòù›æü;šgwo^ü3áPÙ8'
\ No newline at end of file
/branches/new_sharkdoc/vol3/images/int-server1.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol3/images/int-server2.dia
===================================================================
--- branches/new_sharkdoc/vol3/images/int-server2.dia (nonexistent)
+++ branches/new_sharkdoc/vol3/images/int-server2.dia (revision 1676)
@@ -0,0 +1,8 @@
+‹í\ÑnÛ6}÷W.0´€K“)QU"ÛÜ-ÀÖ®¨‹mO†l3ŽVY2$:©_öí#%§‰mÉvD3kjH ô½ºäá9¼—d^¿ù2‹¬kžfa÷ÚÀ¶Åãq2 ãi¯ýiðö%k¿9k½ž„Á+ù;Mƒ™%¿gêS¯}%ÄüU·{ss¢eˆ$Q¸ïþDQЕºí³–eÝ70 D ž­žB¤áh!¸3Þk‚ñçiš,âI»hµj7N¢$µ®ƒ¨×~v™ÿ´»+3Ý5;;lσ)¥<ø\mÊÏ«czÎÓM³³y’…²‰XηšTØQïµYµÊd£xzöìœ<+^iõàÎVًV:³ †ñ¶Ù7QÑ0Œñm?<ÜÅȼ‹È¼‹Ô¼‹0ΓT¤A(¶ÝŒ’$âA\xé‚×÷“ƒHBfW(¨¾õËPˆdÏû_QvHÅ㯳ç¡3qš†“Ýq­E…•›p"®†_vu˜Öï±ÂÁҜƒë0 G/‹!Œ…öˆßš_Çüæåœ|÷uMLÖ*IÂ8åôá¤?]„žíÛz›
+KW«fÝ}½¾ÙîЎ)mHpî"
+–<]™ÿñN|­Õ¯xç^/$£øX¬Âû(‚x¤ë¥Õ¢p.gøÝzB®&ÂI¯ý®wÑfPÒ äÀ­>š'_Dí`@7ÃÞ¦Ž*ó£Ñ¦õTÆÄӈßz Ê¡>‚€ÒŽ ìzÞxÄgÃq’ÆÛZ¬€r9luË:¦¯x8½Õ¶ p÷™/Hт҅²åÛv¨Qð(šƒ‡֑2
+͐N >X>Žêj9 ®IüH'¹!9²Ô$~tcúþtžŽKÀcë‚Ǐb#¢‹xÄwó Ë)ˆÂêù'q<äñ$äñU Í­KVãEz͇“0“1y5&^Bà„qM╩ßi ªg]¾|*†Aš&7›æy¼˜æmmÛÈÇÓÝ8úNöö9îÜð/¢drÝÉÉ:&§¥ P‡èú x¶Ôj§fÏ ýž\i£M妛ùÿFu©ÿW¿¢¼´#{«*$±(ó¥ž[—Á,Œ–ò•‚8k[™Xª4ClñÕ_ytÍE8î³ÊÃß`KEÊ*ë9Y‡Ø^˜Õq±ž»î([B¨ç(ˆÂi<ãåãvÇSè@/¥™©QJ º”à,Í6H å+fÊI ü@{äðçùÅ eÿ4h(âر»†&L҄£]RpԀ1“ª<¸9K¸³{ ˆ‹ŸkVG§‡-¸5ô`’\]z j¸¼µ½›£DîC’õÂ›C¿}zøð\¼°~˜
+߂'Æ0Ó,Q‚ºï'àÿÏåÅA¦½ŠÈGŒš­ÊÃólܱcÔs|é”Òq‚„:†Ëƒe–´Bb¶6ë`5¥Á) +zÚS«šµmxj®œ êË循¢'£á‘ð{ˆXꗯQqƒ*Žà¸"/è™æ
+Ì”o¶)Âp©ã)¿ QlZÇKB,iE5·•9oä¼LΑþ š¶Ùœ\Ú§n>QdZŽ\àἸOžRfÞ³>¶ú¿ÿ1øÛúð©ÿ©ß(üѾ ŠMAϤÄkŸc@ãˡۂz®:Äã æ{;ŒÙJL)¤Ä°¼o…WÖ¤öG8ÄcÛu׍²?9e? ;×x­=÷Á$2ÕYWÕÚ½o_ÑOo£þÄ»mMvnRº‰þñmÓG@6óô‚<âߌPª®@è0Ó%ö­øJ®št «6ö0iDûDD›ã628%1`’§!°™Tl”ßëª ÏG–ìÖóýwkð¾H¿_4~l ßÀ^“y›”oý“vì1öÈ]ɘ¨ u¦®%s¸‘K~
+‚L×ÙA›ä^qàÇt.µÜ&Miýd´\û°FZÀ<l‚Êä;?˘mÀ<•„¹¢7Š^ÀFÕMªºþÉ7XÜ_7}ò:Ž#ÝÈôÜóüüÒ¼£Jì¶BÓ7cËB¬ºÈïÖ._¾cN©%Ù7²~²®åEoƒóÓ,×t™¤Ëiàxùþ$Ol¯\*¼¥nÆ]¼û¥uñ®Ù47´i¾‰ÆF࣏âsþžÎZkÿê¬õŸm£´üQ
\ No newline at end of file
/branches/new_sharkdoc/vol3/images/int-server2.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol3/images/int-server3.dia
===================================================================
--- branches/new_sharkdoc/vol3/images/int-server3.dia (nonexistent)
+++ branches/new_sharkdoc/vol3/images/int-server3.dia (revision 1676)
@@ -0,0 +1,10 @@
+‹íZÛnÛ8}ÏWÊ«K‹º«©Sl6-¶@» ´i}2h‹‘¹•)ƒ¢ãøe¿}II‰c]|‘ÄÝ,  y4GC93#úÝûÇe¬=`–’„Nt ]Ãtž„„FýûÝÇ7¾þþúâ]HÐ[ñ1´ÔÄ4•G}Áùêíx¼Ùl@¼MOˆÉ¤xü7Šc4FcýúBÓ^:Gò\qqÎÈlͱFÑOôšÿŒX²¦¡ž[vó$N˜ö€â‰~yŸ}ôqáf¼çç€ïŠðŒaô³Ùµ!>AÐÆõ
+³²Ûå*I‰0áÛUŤÁüÿ¦°J…®/±/ó[*Nì|ÕÝh#_"ZÅkç aß4ͧu8b¦"VÁÔCtºJgˆð*Ì,IbŒhŽÄÙ·ÇIç(”9
+lïýžpž¹ÿ{§§Ÿ~Ξs31b$<œˆ{ +^6$ä‹éã¡å2€Ó~Árÿ[eþHJf1®‹€PÞùy?¹ßöã¾ü„2EÞ]ޑ¹·FÉ}ì`ç|ɏÖ$ÄéªíÛ4xZfãc«^¶;uaòS¥œAÄh‹YáþfWzµâªób’Ù_x΋ð¾qDCÄBív“<ê»NBô$œèûËSH8êWYŸUòL"ΚÀ*]•&€Ù¬ìŸ‰b\`HÓ¹2 +à Ó Çx9'ŒVk|ád ™tTCzVqx¼/0‰¼Ù½ ܖ+”.’Í´¦½;^ëêsr¼£ck~®ü´Aà;#ØmysCŠ%Q,7c©' P-W;‡6°µg¶š=¨©x¤ÐmOÓVcä|õå‘|åÚÚ1¸°­ {‡y +c­®ŒµÒsFðUòbՅÒùÞ´/šC¨^;@.âH{[²iz ÙŒ¿gWzðé÷»Û¯Ÿ~|hx)p ënãÊëåyí-I¼÷…hªk)ßÊöP<èüÒßpü€9™£—]ìùwPɏºf7}ʝJ»6Hû£ÇwN†Ñ +H ÷]âúLJézY3“šÊê ¥Ja÷ Rþ-¨T
+‚¬Ì+å ©°í¾~©øpûqP *Q¡Ü *UÂéC%d7êOi ,„Bö®œÕ2¥pelzÎ뗊_o¾ +R¡B*jx7¨…ÂqÙíg\¬áª—% |—Mрºÿ¸Ü%¸a\y=”·ŽL¨¾º™p”¿‰”#³kKÂþ/ªÛí÷/_þꛂúVC¼¡¼õ¢Ÿ Å5já÷Õ CÅNà؁d@дe?lB@äF˜×ò=Û<¡tŠi˜…Ó"Èz
+w؛„™¯Ê÷Q·~V¤á1–lʎwü´:zžÆ˜F‡J¸Ü®Gšا!ȇ.¨%² ­”‹§o´…È›Biy’íñi»o'º[á@͵°¸ÖØ¿V·ÞK7ÔOf}ôòÕT 8­Ëò$Žø٘kY®•mÁxžú´®DXoeuÛòú•æµÑ!¯Íÿ&¯¡ÑGb绩ž«<·sXdv6,¶N£³»&ÂFÃ.ìÛ¯4·Í¹ívÍíü8ûeÜõÅÞOç®/þh6š2/
\ No newline at end of file
/branches/new_sharkdoc/vol3/images/int-server3.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol3/makefile
===================================================================
--- branches/new_sharkdoc/vol3/makefile (nonexistent)
+++ branches/new_sharkdoc/vol3/makefile (revision 1676)
@@ -0,0 +1,4 @@
+MAIN = vol3
+MAIN_NAME = vol3
+
+include ../common/manual.mk
/branches/new_sharkdoc/vol3/makefile
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/kernel.tex
===================================================================
--- branches/new_sharkdoc/vol4/kernel.tex (nonexistent)
+++ branches/new_sharkdoc/vol4/kernel.tex (revision 1676)
@@ -0,0 +1,1167 @@
+%----------------------------------------------------------------------------
+\chapter{The Generic Kernel Internals}
+%----------------------------------------------------------------------------
+
+In this chapter some information are given on the implementation
+of the Generic Kernel. The objective of this chapter is to give
+the user enought information about the internal of the kernel to
+allow an analysis of the source code. The code described in this
+chapter is contained into the \texttt{kernel} directory.
+
+%----------------------------------------------------------------------------
+\section{System Tasks and User Tasks}
+\label{Kernel_TaskUtente}
+%----------------------------------------------------------------------------
+
+The Generic Kernel classifies the tasks in the system using two
+flags of the control field of the task descriptor. The Programming
+Model of the kernel is a monoprocess multithread model, so each
+task shares a common memory without any kind of address
+protection.
+
+The two flags of interest are the \texttt{SYSTEM\_TASK} and the
+\texttt{NO\_KILL} flags:
+
+\begin{itemize}
+\item If the \texttt{SYSTEM\_TASK} flag is set a task is a task
+used internally by the Kernel, otherwise the task is considered an
+user task; \item If the \texttt{NO\_KILL} flag is set a task
+cannot be killed by a \texttt{task\_kill} or
+\texttt{pthread\_cancel} primitive.
+\end{itemize}
+These two flags divide the task universe in four sets (look at
+Figure \ref{Kernel_4Insiemi} and at Table
+\ref{Kernel_Tab_4Insiemi}):%
+\begin{figure}
+\begin{center}\includegraphics[%
+ width=8cm]{images/kernel_quattro_insiemi.eps}\end{center}
+
+
+\caption{\label{Kernel_4Insiemi}The four sets in whitch the tasks
+are divided; The values of the two flags \texttt{SYSTEM\_TASK}
+(ST) and \texttt{NO\_KILL} (NK) are showed.}
+\end{figure}
+%
+\begin{table}
+\begin{center}\begin{tabular}{|c||c|c|}
+\hline & \texttt{SYSTEM\_TASK=0}&
+\texttt{SYSTEM\_TASK=1}\\ \hline \hline
+\texttt{NO\_KILL=0}& User tasks& System Drivers\\
+\hline \texttt{NO\_KILL=1}& Immortal User Tasks& System
+Tasks\\ \hline
+\end{tabular}\end{center}
+
+
+\caption{\label{Kernel_Tab_4Insiemi}The four sets in whitch the
+tasks are divided.}
+\end{table}
+
+\begin{description}
+\item [User~Tasks]These are the tasks usually created by the user;
+\item [Immortal~User~Tasks]These tasks are tasks that the user
+wants to protect against uncontrolled cancellations. Usually the
+life of these tasks is not important for the termination of the
+system; in other words, the system can shut down also if these
+tasks are not ended; \item [System~Drivers]These tasks are handled
+directly by the Kernel or by some Libraries that implement some
+important things (for example, the file system controls the hard
+disks with tasks of this type); \item [System~Tasks]These are
+non-critical tasks that have to be always present in the system;
+the life of the system depends on the life of these tasks. Such a
+task is for example the dummy task.
+\end{description}
+
+System termination can be generated automatically by the Generic Kernel or it
+can be forced if the user calls the \texttt{exit()} function.
+
+The Generic Kernel starts the system termination when all User
+Tasks ends or when all the System Drivers ends.
+
+To do the shutdown in a correct way, the libraries that are
+implemented using the System Drivers should end in a correct way.
+Look at Section\ref{Kernel_Inizializzazione} for more
+informations.
+
+%----------------------------------------------------------------------------
+\section{Initialization and Termination}
+\label{Kernel_Inizializzazione}
+%----------------------------------------------------------------------------
+
+In this section the structure of the function
+\texttt{\_\_kernel\_init\_\_} is described in more detail. This
+function is the function called by the OS Lib at system startup.
+%
+% Tool: such section does not exists.
+%
+% The interface between the Generic Kernel and the OS Lib is not
+% described here but in section \ref{OSLib_SezInizializzazione}.
+
+%----------------------------------------------------------------------------
+\subsection{Interrupt Disabling}
+%----------------------------------------------------------------------------
+
+The first thing that is done in the function is the disabling of
+the interrupts. When the system starts, the OS Lib allocs a
+context, whose number is stored by the Generic Kernel into the
+global variable \texttt{global\_context}. In this startup context
+the function \texttt{\_\_kernel\_init\_\_} is called; also the
+functions that it calls run in that context.
+
+The context used by the tasks will be allocated next, with a call
+to the OS Lib function \texttt{ll\_context\_create} (this function
+is called by the Generic Kernel into the primitive
+\texttt{task\_create}).
+
+The interrupts will be enabled automatically at the first context
+change.
+
+%----------------------------------------------------------------------------
+\subsection{Initialization of the Memory Management}
+%----------------------------------------------------------------------------
+
+After disabling the interrupts, the dynamic memory manager can be
+initialized. It must be the first thing that is initialized
+because dynamic memory is used extensively in all the Kernel (and
+the first place where it is used is the Module Registration).
+
+%----------------------------------------------------------------------------
+\subsection{Initialization of the static data structures}
+%----------------------------------------------------------------------------
+
+The next step in the in the Kernel startup is the initialization
+of the staticdata structures. In particular, it will be
+initialized:
+
+\begin{itemize}
+\item The task descriptor and the task-specific data; \item The
+free descriptor queue; \item The arrays that contains the pointers
+to the Module descriptors; \item The tata structures used to
+implement POSIX signals; \item The data structures used to call
+the init functions posted through the function
+\texttt{sys\_atrunlevel}.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsection{Resgistration of the Modules in the system}
+\label{Kernel_kernel_register_levels}
+%----------------------------------------------------------------------------
+
+At this point, the system has the interrupts disabled and all
+static data structures initialized. Now, the Generic kernel needs
+to know what is the real Module configuration in the system. To
+handle that, the following function is called:
+
+\bigskip{}
+\begin{center}\texttt{TIME
+\_\_kernel\_register\_levels\_\_(void {*}arg)}\end{center}
+\bigskip{}
+
+That function is a user defined function that must call the
+registration functions of the Scheduling Modules and of the
+Resource Modules.
+
+It has a parameter that contains a pointer to a \texttt{multiboot}
+structure,that can be used to know some information about the
+system and about the command line
+arguments.%
+\footnote{The function \texttt{\_\_compute\_args\_\_} described in
+the file \texttt{include/kernel/func.h} can be
+used.%
+} . These informations can be useful to modify the Module
+registration dinamically at run time.
+
+The value returned by the function is the system tick that the
+system will use for the periodic timer initialization. If the
+value returned is 0 the generic kernel will use the one-shot timer
+instead
+%
+% Tool: such section does not exists.
+%
+% (look at Section \ref{OSLib_Inizializzazione})
+.
+
+To simplify the developing of the applications, the kernel
+distribution contains some init examples in the directory
+\texttt{kernel/init}.
+
+In the initialization function only these functions can be used:
+
+\begin{itemize}
+\item The functions that alloc and free the dynamic memory
+(described in Section \ref{KernSupport_GestioneMemoria}); \item
+The function \texttt{sys\_atrunlevel} that can be used to register
+the initialization and termination functions; \item The functions
+of the C library exported by the OS Lib; \item The functions that
+prints some messages on the console, like for example
+\texttt{printk} and \texttt{kern\_printf}.
+\end{itemize}
+\bf{The other functions of the Generic Kernel and of the OS
+Lib can not be used}.
+
+For the developers that knows the earlier versions of the Hartik
+Kernel, the body of the startup function
+\texttt{\_\_kernel\_register\_levels\_\_} can be thought as the
+first part of the \texttt{main()} function (until the
+\texttt{sys\_init()}).
+
+%----------------------------------------------------------------------------
+\subsection{OS Lib initialization}
+%----------------------------------------------------------------------------
+
+At this point all the data structures are initialized, so the
+system can go in multitasking mode calling the OS Lib's
+\texttt{ll\_init} and \texttt{event\_init} functions.
+
+%----------------------------------------------------------------------------
+\subsection{Initialization functions call}
+\label{Kernel_Runlevel_init}
+%----------------------------------------------------------------------------
+
+At this point the system has only one valid context (the
+\texttt{global\_context}); there aren't any tasks yet (because
+nobody could create them before).
+
+To end the initialization part the Generic Kernel calls the
+initialization functions registered by the Modules registered in
+the system. Because the OS Lib is initialized, all the function
+exported by it can be called. Moreover, the primitives
+\texttt{task\_create} and \texttt{task\_activate} can be called.
+
+The initialization functions can be used by the Scheduling Modules
+to create a startup task set. Tipically the startup task set is
+composed by two tasks: the \texttt{dummy} task (usually created by
+the \texttt{dummy} Scheduling Module
+%
+\footnote{This module simply ends the Scheduling Module levels, in
+a way that there will be always a task to
+schedule.%
+}) and the task that has the function \texttt{\_\_init\_\_} as
+body (that task is usually created by the Round Robin
+(\texttt{RR}) Scheduling Module). This choice is the tipical
+situation used in most cases, but is not mandatory. The only thing
+really important is that there must be a task to schedule after
+this step.
+
+The function \texttt{\_\_init\_\_} is usually contained into the
+initialization files, just after the \texttt{\_\_kernel\_register}
+\texttt{\_levels\_\_} function. That function is the body of the
+first task that is executed in the system. The actions done by
+that function are tipically two:
+
+\begin{itemize}
+\item the initialization of some devices and libraries that use
+some system primitives (for example, the semaphores) and for this
+reason they must be initialized into a context of a {}``real''
+task (and not in the \texttt{global\_context} where the
+initialization functions are called). Examples of these libraries
+are for example the communication ports, and the keyboard and
+mouse drivers (all these libraries uses the semaphores); \item the
+call to the \texttt{main()} function (in this way the Applications
+can be writed using the straight C
+standard)%
+\footnote{The function \texttt{\_\_call\_main\_\_} described in
+the file \texttt{include/kernel/func.h} can be
+used.%
+}.
+\end{itemize}
+For the developers that knows the earlier versions of the Hartik
+Kernel, the body of the \texttt{\_\_init\_\_} function can be
+thought as the part of the \texttt{main()} function (from the
+\texttt{sys\_init} to the \texttt{sys\_end()}).
+
+Per quanti fossero familiari con le versioni precedenti del
+Kernel, il corpo della funzione \texttt{\_\_init\_\_} corrisponde
+più o meno alla parte della funzione \texttt{main()} compresa tra
+la \texttt{sys\_init} (esclusa) e la \texttt{sys\_end} finale
+(esclusa).
+
+%----------------------------------------------------------------------------
+\subsection{First context change}
+%----------------------------------------------------------------------------
+
+Now, the data structures are initialized, and the first tasks are
+created. At this point the Generic Kernel simply schedule the
+first task and dispatch it.
+
+When the first task is scheduled the global context is also saved.
+Because the global context is not a context of a task, the system
+will never schedule again the global context until all the user
+task are finished.
+
+The system will change the context to the global context also when
+the \texttt{sys\_end} or the \texttt{sys\_abort} functions are
+called to shut down the system. Note that the function
+\texttt{ll\_abort} does not change the context to the global
+context, but it simply change to a safe stack and shut down the OS
+Lib, without shutting down the Generic Kernel correctly.
+
+%----------------------------------------------------------------------------
+\subsection{The shutdown functions}
+%----------------------------------------------------------------------------
+
+When the last user task ends, or when the \texttt{sys\_end}, or
+\texttt{sys\_abort} function are called, the current context
+changes to the global context.
+
+At this point the system has to do some operations to shut down
+the system in a correct
+way%
+\footnote{For example, if the File System is used maybe there will
+be some data that have to be written on the
+disks%
+}.
+
+The operations that have to be called depends on the registered
+Modules, so the Generic Kernel allows to set, using the function
+\texttt{sys\_atrunlevel}, a set of functions to be called at this
+time.
+
+Usually these functions activates some recovery tasks that will
+shut down correctly the system. These function should be small,
+because just after the calls the system will be scheduled again to
+allow the libraries to shut down using the newly activated
+threads.
+
+If the shutdown functions are too long and uses a lot of computation time, thete
+can be some undesirable effects that can put the system in an instable state
+\footnote{A typical situation is that when the system is rescheduled a task that
+used a resource miss a deadline; then the Scheduling Module disable its
+schedulability, and the operation on the device cannot end, and with it all the
+system!}.
+
+%----------------------------------------------------------------------------
+\subsection{Termination request for all user tasks}
+%----------------------------------------------------------------------------
+
+To speed-up the system termination, the system tries to kill all
+the user tasks. Because the cancellation is usually deferred (as
+told by the POSIX standard), this should not cause the
+instantaneous dead of all tasks when the system returns in
+multitasking mode.
+
+%----------------------------------------------------------------------------
+\subsection{Second context change}
+%----------------------------------------------------------------------------
+
+To shut down correctly the system the scheduler must be called
+again. For the secon time the system exits from the global
+context. The system usually evolve as follows:
+
+\begin{itemize}
+\item The user tasks should die (slowly\ldots{}); \item The
+shutdown function should give some information to the system tasks
+so they can finish their work and end.
+\end{itemize}
+The system will return to the global context when all system tasks
+will end or the \texttt{sys\_abort} will be called. The
+\texttt{sys\_end} function does not have any effect in this phase.
+
+%----------------------------------------------------------------------------
+\subsection{Exit functions called before OS Lib termination}
+%----------------------------------------------------------------------------
+
+When all the tasks end or the \texttt{sys\_abort} is called the
+execution returns to the global context. At this point the
+functions registered through the \texttt{sys\_atrunlevel} function
+with the parameter \texttt{RUNLEVEL\_BEFORE\_EXIT} are called.
+
+The mission of these functions is to terminate the cleaning of the
+system (for example, it may be useful to set the display in text
+mode if the application uses the graphic modes).
+
+%----------------------------------------------------------------------------
+\subsection{Termination of the OS Lib}
+%----------------------------------------------------------------------------
+
+At this point the system can end its work. For this reason the
+function \texttt{ll\_end} is called; this function frees all the
+data structures allocated with the \texttt{ll\_init}. After this
+call only the function specified in the Section
+\ref{Kernel_kernel_register_levels} can be called.
+
+%----------------------------------------------------------------------------
+\subsection{Exit functions called after OS Lib termination}
+%----------------------------------------------------------------------------
+
+Finally, the Kernel calls the last functions registered with the
+\texttt{sys\_atrunlevel}, that tipically prints some nice messages
+or simply reboot the computer.
+
+%----------------------------------------------------------------------------
+\section{Task creation and on-line guarantee}
+\label{Kernel_Garanzia}
+%----------------------------------------------------------------------------
+
+The Generic Kernel primitive that creates and guarantees a new
+task is called \texttt{task\_createn}. The prototype of that
+function is the following (the code of the primitive is contained
+in the file \texttt{kernel/create.c}):
+
+\bigskip{}
+\noindent \texttt{PID task\_createn(char {*}name, TASK
+({*}body)(), TASK\_MODEL {*}m, \ldots{});}
+\bigskip{}
+
+\noindent The parameter passed with that function are the
+following:
+
+\begin{description}
+\item [\texttt{name}]Symbolic name for the task, used for
+statistical pourposes; \item [\texttt{body}]Pointer to the first
+instruction of the task; \item [\texttt{m}]Pointer to a Task Model
+for the new task to be created \item [\texttt{\ldots{}}]List of
+Resource Model pointers terminated with a \texttt{NULL} pointer.
+\end{description}
+The primitive returns the descriptor number associated to the
+newly created task, or \texttt{NIL} if the task cannot be created
+in the system. In the latter case the variable \texttt{errno} is
+set to a value that explain the typology of the
+error%
+\footnote{The error codes are listed in the file
+\texttt{include/bits/errno.h}.%
+}.
+
+There is also a redefinition of the primitive called
+\texttt{task\_create} that accept only one Resource Module instead
+of {}``\ldots{}''. This redefinition may be useful because usually
+only a few tasks need more than one Resource Model.
+
+The step followed to create and guarantee correctly a new task are
+described in the following paragraphs.
+
+The first thing to do is to find a unused task descriptor.
+Tipically the free descriptors are queued in the \texttt{freedesc}
+queue. During the selection the tasks that are into the freedesc
+queue but that waits a synchronization with a \texttt{task\_join}
+primitive are discarded (look at Section \ref{Kernel_Join}).
+
+At this point the descriptor chosen is removed from the freedesc
+queue and initialized with some default values.
+
+Then, a Scheduling Module that can handle the Task Model passed as
+parameter have to be found. The research is done starting from
+level 0 and calling the \texttt{public\_create} function. When a
+correct Module is found the task is created into that module.
+
+The next step in task creation is the handling of the Resource
+Models passed. This initialization is done calling the
+\texttt{res\_register} function on the Resource Modules registered
+in the system.
+
+At this point all system components are informed of the Quality of
+Service required by the new task, and the on-line guarantee can
+start. The guarantee algorithm cannot be called before registering
+the Resource Models because in general {}``hybrid'' Modules can be
+developed (for example, a Module can register itself as Scheduling
+Module and Resource Module, using the two descriptors...).
+
+Finally, if the task can be guaranteed, the stack memory for the
+task is allocated (only if needed), the task context is created
+using the OS Lib function \texttt{ll\_context\_create}), the
+creation event is registered for the tracer and the task is
+counted into the user or system task counter.
+
+If one of these steps fail, the system will be put in the state
+preceding the call of the primitive (the functions
+\texttt{public\_detach} and \texttt{res\_detach} are also called).
+
+Looking at the on-line system guarantee, the generic kernel
+supports a distributed guarantee on all the Scheduling Modules
+based on the utilization factor paradigm. The system will call the
+\texttt{public\_guarantee} function starting from level 0, and
+passing each time the free bandwidth left by the upper levels.
+This algorithm is implemented in the \texttt{guarantee()} function
+stored in the file \texttt{kernel/kern.c}. That function returns
+-1 if the task set cannot be guaranteed, 0 otherwise.
+
+This approach allows the implementation in a simple way the
+on-line guarantee of many algorithms. However, this approach is
+not suitable to implement more complex algorithms, like for
+example the Deferrable Server guarantee, the TB{*} \cite{But97}
+guarantee and others. in these cases two strategies can be used:
+
+\begin{itemize}
+\item All the system tasks are guarantee off-line, so the
+guarantee procedure can be disabled at run-time. \item All the
+algorithms that need a guarantee are developed in a single
+Sheduling Module, placed at level 0. In this way it can control
+all the system bandwidth, and a guarantee can be done because the
+Module knows all the data needed. However, in this way all
+advantages of the Modularity is lost.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\section{Task activation}
+\label{Kernel_Attivazione}
+%----------------------------------------------------------------------------
+
+The Generic Kernel, unlike the POSIX standard, decouple the task
+creation and guarantee and the task activation. This is done
+because in literature many proofs are given for tasks that are
+activated at the start of the major cycle. Also, the guarantee
+function can be heavy and long, unlike the activation that is
+typically shorter.
+
+The primitives provided by the generic kernel to activate a task
+are two:
+
+\begin{description}
+\item [\texttt{task\_activate}]Activation of a single
+task%
+\footnote{This primitive can be called also into an OS Lib event
+and into the global\_context (in other words, in the function
+posted with the primitive
+\texttt{sys\_atrunlevel}).%
+}; \item [\texttt{group\_activate}]Activation of a group of tasks
+in an atomic
+way%
+\footnote{The system is rescheduled only one time, so it can
+speed-up the activation of a lot of
+tasks.%
+}.
+\end{description}
+The Generic kernel provides a mechanism that allow to freeze task
+activations. That mechanism is inserted in the generic kernel to
+allow the modular implementation of some shared resource protocols
+like SRP or similar.
+
+This mechanism use the task descripror control field flag
+\texttt{FREEZE\_ACTIVATION}, that stores the freeze state of the
+activations, and use the task descripror field
+\texttt{frozen\_activations}, that stores the number of freed
+activations for the Generic Kernel.
+
+These primitives are also defined:
+
+\begin{description}
+\item [\texttt{task\_block\_activation}]blocks explicit task
+activations and activates its counting. The function usually
+returns 0, or -1 if the task index is not correct. \item
+[\texttt{task\_unblock\_activation}]enables explicit task
+activations. it returns -1 if the task had the
+\texttt{FREEZE\_ACTIVATION} field disabled, or the number of
+freezed activations. If there were freezed activations, the
+primitive does not the activations.
+\end{description}
+The prototypes presenyted in this Section are showed in Figura
+\ref{Kernel_Fig_activate} and they are stored in the files file
+\texttt{kernel/activate.c} and
+\texttt{kernel/blkact.c}.%
+\begin{figure}
+\begin{center} \fbox{\tt{ \begin{minipage}{6cm} \begin{tabbing}
+123\=123\=123\=\kill
+int task\_activate(PID p);\\
+int group\_activate(WORD g);\\
+int task\_block\_activation(PID p);\\
+int task\_unblock\_activation(PID p);\\
+\end{tabbing} \end{minipage} }} \end{center}
+\label{Kernel_Fig_activate}
+\caption{Prototypes of the actiovation
+functions.}
+\end{figure}
+
+%----------------------------------------------------------------------------
+\section{The Scheduler}
+\label{Kernel_Scheduler}
+%----------------------------------------------------------------------------
+
+The steps that the Generic Kernel does when the system is
+rescheduled are three:
+
+\begin{itemize}
+\item If when the system is rescheduled a task is running, the end
+of the slice must be called for that
+task%
+\footnote{A task slice is the time interval in that starts when
+the running task is dispatched and end when the system is
+scheduled
+again.%
+}; \item Then, a new task to run must be found (scheduling); \item
+Finally, the chosen task must be run (dispatching).
+\end{itemize}
+These steps are implemented into the system primitives and in the
+\texttt{scheduler()} function stored in the file
+\texttt{kernel/kern.c}. In the following section the three points
+are showed in detail.
+
+%----------------------------------------------------------------------------
+\subsection{Current slice end for the running task}
+%----------------------------------------------------------------------------
+
+To specify which are the actions to do at the end of a slice of
+the running task, the reason af the slice end must be known.
+Depending on the behaviour of the end of the slice, different
+actions should be made.
+
+For this reason the Generic Kernel provides different functions
+that terminates a slice. The cases in that a slice must be ended
+are the following (into parenthesis the related Task Calls are
+listed):
+
+\begin{enumerate}
+\item A new task becomes active in the system, so the Generic
+Kernel wants to check if a preemption (\texttt{public\_epilogue})
+must be done. This situation can happen in a lot of situations,
+like for example:
+
+\begin{itemize}
+\item a new task is activated with a \texttt{task\_activate} or
+\texttt{group\_activate} primitive; \item a resource or a mutex is
+freed, so a task blocked on it is unblocked; \item a periodic task
+is reactivated at the beginning of its period; \item a System
+Driver is activated because an intrettupt is arrived;
+\end{itemize}
+\item The running task finishes its available capacity
+(\texttt{public\_epilogue}); \item The running task blocks itself
+on a synchronization primitive (\texttt{public\_block}); \item The
+running task ends its instance and it suspend itself with a
+\texttt{task\_endcycle} primitive (\texttt{public\_message});
+\item The running task ends or it is killed by a
+\texttt{task\_kill} or \texttt{pthread\_cancel} primitive
+(\texttt{public\_end});
+\end{enumerate}
+In general the funcions sequence that have to be called is the
+following:
+
+\begin{enumerate}
+\item The current time is read into the global variable
+\texttt{schedule\_time}%
+\footnote{That variable is used as temporal reference for the
+scheduling time. Note that the Generic kernel does not separe the
+CPU time passed executing user code and system code; all the CPU
+time is assigned to the user
+task.%
+}; \item The length of the current terminated slice is computed
+using the variables \texttt{schedule\_time} and
+\texttt{cap\_lasttime}; \item The computation time of the current
+slice is accounted to the task (look at Section \ref{Kernel_Jet});
+\item The capacity event (if one is pending) is erased; \item The
+Scheduling Module function that handles the termination of the
+slice for the task is called..
+\end{enumerate}
+To simplify the writing of the primitives the following approach
+is implemented: because the preemption rescheduling is the most
+common situation, the sequence given before that terminates with a
+call to \texttt{public\_epilogue} is included as prologue in the
+\texttt{scheduler()} function. That prologue is not executed if
+the variables \texttt{exec} and \texttt{exec\_shadow} have a
+\texttt{NIL} (\texttt{-1}) value when the function is called.
+
+%----------------------------------------------------------------------------
+\subsection{Scheduling}
+%----------------------------------------------------------------------------
+
+When the previous slice is terminated a new task to schedule must
+be chosen. The generic scheduling algorithm starts from the
+Scheduling Module at level 0, calling the function
+\texttt{public\_scheduler}, and going through the levels when a
+Module does not have any task to schedule. The Generic Kernel
+assumes that there is always a task to
+schedule%
+\footnote{To have always a task to schedule a Scheduling Module
+called \texttt{dummy} is provided that always guarantees the
+existence of a task to
+schedule.%
+}.
+
+When a task to schedule is found, the function
+\texttt{public\_eligible} is called to verify if the task chosen
+by the scheduler is correct. If the task is not correct, the
+generic scheduling algorithm restarts from the level that gave the
+wrong task before
+%
+% Tool: such section does not exists.
+%
+% (look at Section \ref{SchedModules_TaskCalls})
+.
+
+%----------------------------------------------------------------------------
+\subsection{Dispatching}
+%----------------------------------------------------------------------------
+
+To find the task that should be executed really another step has
+to be done: the shadow chain of the scheduled task must be
+followed
+%
+% Tool: such section does not exists.
+%
+% (look at Section \ref{ArchDetail_prot_ris_condiv})
+. When
+the tail of that chain is found, the function
+\texttt{public\_dispatch} is called on that task.
+
+Finally, if the task has the \texttt{CONTROL\_CAP} bit of the task
+descriptor control field set, a capacity event is posted.
+
+%----------------------------------------------------------------------------
+\section{Execution Time statistics}
+\label{Kernel_Jet}
+%----------------------------------------------------------------------------
+
+The Generic Kernel supports the accounting of the task execution
+times. This is useful because the behaviour of many algorithm
+proposed in the literature depends widely on the accuracy with
+that the task capacities are managed.
+
+To enable the Generic Kernel to account the execution time of a
+task, the user should use the provided macros for the Task Models
+(look at Section \ref{Modelli_TASK_MODEL}). These macros modifies
+the \texttt{JET\_ENABLE} flag into the \texttt{control} field of
+the task descriptor.
+
+The Generic Kernel can store some data about a task. In
+particular, the mean and the maximum execution time of a task and
+the time consumed by the current instance and of the last
+\texttt{JET\_TABLE\_DIM} instances.
+
+The prototypes of the Generic Kernel functions are described in
+Figure\ref{Kernel_Fig_Jet}.%
+\begin{figure}
+\begin{center} \fbox{\tt{ \begin{minipage}{6cm} \begin{tabbing}
+123\=123\=123\=\kill
+int jet\_getstat(PID p, TIME *sum, TIME *max,\\
+\>\>int *n, TIME *curr);\\
+ int jet\_delstat(PID p); \\
+ int jet\_gettable(PID p, TIME *table, int n);\\
+ void jet\_update\_slice(TIME t);\\
+ void jet\_update\_endcycle();
+ \end{tabbing} \end{minipage} }} \end{center}
+
+\label{Kernel_Fig_Jet}
+\caption{Primitives for execution time handling and correlated functions used
+internally by the Generic Kernel.}
+\end{figure}
+
+In the following paragraphs these functions are described:
+
+\begin{description}
+\item [\texttt{jet\_getstat}]This primitive returns some
+statistical informations; in particular, the informations are
+stored into the following parameters:
+
+\begin{description}
+\item [\texttt{sum}]is the task total execution time since it was
+created or since the last call to the \texttt{jet\_delstat}
+function; \item [\texttt{max}]is the maximum time used by a task
+instance since it was created or since the last call to the
+\texttt{jet\_delstat} function; \item [\texttt{n}]is the number of
+terminated instances which sum and max refers to; \item
+[\texttt{curr}]is the total execution time of the current
+instance.
+\end{description}
+if a parameter is passed as NULL the information is not returned.
+The function returns 0 if the PID passed is correct, \texttt{-1}
+if the PID passed does not correspond to a valid PID or the task
+does not have the \texttt{JET\_ENABLE} bit set.
+
+\item [\texttt{jet\_delstat}]The primitive voids the actual task
+execution time data mantained by the Generic Kernel. The function
+returns 0 if the PID passed is correct, \texttt{-1} if the PID
+passed does not correspond to a valid PID or the task does not
+have the \texttt{JET\_ENABLE} bit set. \item
+[\texttt{jet\_gettable}]The primitive returns the last n execution
+times of the task passed as parameter. If the parameter n is less
+than 0, it returns only the last values stored since the last call
+to \texttt{jet\_gettable}. If the value is greater than 0, the
+function returns the last \texttt{min(n,~JET\_TABLE\_DIM)} values
+registered. The return value is \texttt{-1} if the task passed as
+parameter does not exist or the task does not have the
+\texttt{JET\_ENABLE} bit set, otherwise the number of values
+stored into the array is returned. The table passed as parameter
+should store at least \texttt{JET\_TABLE\_DIM} elements.
+\end{description}
+The function used into the Generic Kernel implementation are the
+following:
+
+\begin{description}
+\item [\texttt{jet\_update\_slice}]updates the current slice of
+the running task (pointed by the \texttt{exec\_shadow} field) by t
+microseconds; \item [\texttt{jet\_update\_endcycle}]updates the
+execution time of the last instance. When this function is called
+the last instance is just terminated.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Cancellation}
+\label{Kernel_Cancellazione}
+%----------------------------------------------------------------------------
+
+The POSIX standard provides some mechanisms to enable and disable
+the cancellation, and to set the cancellation as deferred or
+asynchronous.
+
+For more informations about the cancellation functions look to the
+POSIX standard.
+%
+% Tool: table does not exist.
+%
+% In Table \ref{Posix_Tab_Funzioni} there are some
+% primitives that are very similar to these of the standard.
+
+The biggest problems in implementing task cancellation into the
+Generic Kernel are the following:
+
+\begin{itemize}
+\item The kernel does not have a private stack, and works simply
+disabling the interrupts into the contexts of the tasks in the
+system; \item The cancellation functions for a tasks should be
+called into the stack of the task, so it is not possible to kill
+another task immediately without changing context; \item The
+Generic Kernel should abstract from the cancellation points
+present in the system, because in general it is not possible to
+handle all the internal structures introduced by a particular
+cancellation point.
+\end{itemize}
+The solution to these problems is proposed in the following
+Sections.
+
+%----------------------------------------------------------------------------
+\subsection{The task\_makefree function}
+%----------------------------------------------------------------------------
+
+When a task die the flow control of a task is switched to the
+\texttt{task\_makefree} function. This function have to call all
+the cancellation points function, and the key destructors.
+
+The function can be called into the cancellation points (the
+\texttt{task\_testcancel} function is called, look at the file
+\texttt{kernel/cancel.c}), and at task termination (look at the
+\texttt{task\_create\_stub} in the file \texttt{kernel/create.c}),
+and each time a task is scheduled (to test asynchronous
+cancellation).
+
+The function does the following steps:
+
+\begin{itemize}
+\item It checks if someone is waiting for the task termination
+(with a \texttt{task\_join} primitive); \item It verifies if the
+task that is terminating is actually using a resource handled with
+the shadow mechanism (if so an exception is raised); \item It
+calls some cleanup functions; \item It calls the thread specific
+data destructors; \item It frees the
+context%
+\footnote{Note that the freed context is the running context. this
+is not a problem because the \texttt{task\_makefree} is executed
+with the interrupts disabled, and nobody can use the free memory
+areas
+freed.%
+}and the allocated memory for the stack; \item It calls the
+\texttt{public\_end} on the Scheduling Module that owns the task,
+and the \texttt{res\_detach} function on the Resource Modules
+registered in the system; \item It verifies if the end of the task
+should cause the whole system termination (look at Section
+\ref{Kernel_TaskUtente}).
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsection{Cancellation point registration}
+%----------------------------------------------------------------------------
+
+The last problem to solve is the independence of the Generic
+Kernel from the Cancellation Points. The objective of the
+cancellation point registration is to write the code for a
+cancellation point without modify the primitives that effectively
+kill a task. The implementations can be depicted with these
+points:
+
+\begin{itemize}
+\item The blocking of a task on a cancellation point is
+implemented through the \texttt{public\_block} function; \item The
+task state of a blocked task on a cancellation point is modified
+to a value visible by the Generic Kernel (usually these names
+starts with the prefix WAIT\_); \item The functions that
+implements the cancellation points register themselves at their
+first execution calling the \texttt{register\_cancellation\_point}
+primitive (this function is defined in the file
+\texttt{kernel/kill.c}). The primitive accepts a function pointer
+that returns 1 if the task passed as parameter is blocked on the
+cancellation point handled by the function. \item First, the
+function that should kill a task sets the \texttt{KILL\_REQUEST}
+flag of the control field of the task descriptor; then, it calls
+the registered cancellation point functions to check if a task is
+blocked on a cancellation point. If so, the registered function
+reactivates the blocked task calling the \texttt{public\_unblock}
+function. \item The architecture of a cancellation point should
+guarantee that when a task is woken up a check is made to see if a
+task is killed. If so, the function internally calls the primitive
+\texttt{task\_testcancel} to kill the task.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsection{Cleanups and Thread Specific Data}
+\label{Kernel_Cleanups}
+\label{Kernel_pthread_keys}
+%----------------------------------------------------------------------------
+
+The POSIX standard provides two primitives,
+\texttt{pthread\_cleanup\_push} and
+\texttt{pthread\_cleanup\_pop}, that allows to specify functions
+to be executed in the case a task has been killed during a section
+of code delimited by these two functions.
+
+The implementation of these two functions has been done through a
+macro similar to that contained into the rationale of the POSIX
+standard.
+
+Their implementation is contained into the files
+\texttt{include/pthread.h} and \texttt{include/kernel/func.h}.
+
+The Generic kernel provides also the support for the Thread
+Specific Data of the POSIX Standard. The implementation of these
+primitives is not complex and can be found in the file
+\texttt{kernel/keys.c}.
+
+%----------------------------------------------------------------------------
+\section{Signals}
+\label{Kernel_Segnali}
+%----------------------------------------------------------------------------
+
+The Generic kernel provides a POSIX signal implementation derived
+from the Flux OSKit \cite{Bry97}.
+
+Two aspects need to be described:
+
+\begin{itemize}
+\item the implementation of the signal interruptable functions:
+
+
+To implement these function a registration call is provided in a
+way similar to the cancellation points. Each time a signal is
+generated, a check is done to see if some task is blocked on a
+signal interruptable function. The registration function is called
+\texttt{register\_interruptable\_point} and it is contained into
+the file \texttt{kernel/signal.c;}
+
+\item the correct delivery of the signals:
+
+
+a function called \texttt{kern\_deliver\_pending\_signals}
+(defined in the file \texttt{kernel/signal.c}) is provided; this
+function is called into the macro that changes context (the macro
+\texttt{kern\_context\_load}, defined into the file
+\texttt{include/kernel/func.h}). That function is usually called
+after a context change, so when a task is rescheduled the pending
+signals for that task are delivered. Note that in the current
+version if a task is preempted by a task activated in an
+interrupt, when the task is rescheduled there will not be any
+signal dispatching. This IS a bug, and it will be fixed in the
+next releases of the OS Lib.
+
+\end{itemize}
+Moreover, the OS Kit signal implementation is slightly modified to
+handle the POSIX message queues and the POSIX realtime timers.
+
+%----------------------------------------------------------------------------
+\section{Task Join}
+\label{Kernel_Join}
+%----------------------------------------------------------------------------
+
+The POSIX standard specifies that a thread return value can be
+read, if the task is \emph{joinable}, through a call to the
+primitive \texttt{pthread\_join} or \texttt{task\_join}.
+
+In this section the implementation of the primitive
+\texttt{task\_join} is described, with all the modification that
+the implementation has done on the Generic Kernel.
+
+First, the information about the task type (joinable or detached)
+is stored into the flag \texttt{TASK\_JOINABLE} of the
+\texttt{control} field of the task descriptor.
+
+Usually the POSIX threads starts in a joinable state and then they
+can be detached. The Generic kernel follow this line when
+implementing the \texttt{pthread\_create}, but with a difference:
+the default attribute for the task models is
+detached%
+\footnote{Note that this does not impact on the standard POSIX
+implementation, since the task\_create is a non-standard
+function.%
+}.
+
+The \texttt{task\_join} primitive implements the POSIX primitive
+\texttt{pthread\_join}. It is a cancellation point and it register
+itself in the Generic kernel the first time it executes.
+
+The main problem in the implementation of this primitive is that a
+task descriptor correctly terminated can be reused until a join is
+executed on it. The problem is that in this way the Scheduling
+Modules should know the internal implementation of the primitive,
+and this fact may complicate the writing of a Scheduling Module if
+special task guarantees are implemented.
+
+The implementation tries to avoid these problems in the following
+way:
+
+\begin{itemize}
+\item The Scheduling Modules prescind from the task tipology
+(joinable or detached) and simply inserts a task that terminates
+in the free queue when the descriptor is no longer needed; \item
+The \texttt{task\_makefree} checks if the task is joinable, and if
+it is the flag \texttt{WAIT\_FOR\_JOIN} in the control field of
+the task descriptor is set. In any case the context and the stack
+for the dead process are released; \item A call to
+\texttt{task\_create} that tries to alloc a task descriptor that
+waits for a join and whose descriptor is inserted in the freedesc
+queue simply discards it, setting the bit
+\texttt{DESCRIPTOR\_DISCARDED}, in the \texttt{control} field of
+the task descriptor. \item A call to \texttt{task\_join} on a task
+that is already terminated, inserted in the freedesc queue and
+discarded by the primitive \texttt{task\_create}, inserts the
+descriptor in the \texttt{freedesc} queue.
+\end{itemize}
+This way allow the Scheduling Modules to abstract and remain
+independent from the implementation of the join primitive.
+
+%----------------------------------------------------------------------------
+\section{Pause and Nanosleep}
+\label{Kernel_nanosleep}
+%----------------------------------------------------------------------------
+
+The Generic Kernel supports a set of primitives to implement a
+task suspension. The differences between them are the following:
+
+\begin{description}
+\item [\texttt{sleep}]This primitive suspend the execution task
+for a number of seconds. The task can be woken up by a signal
+delivery; \item [\texttt{pause}]This function suspends the task
+until a signal is delivered to it; \item [\texttt{nanosleep}]This
+function suspends the running task for a minimum time passed as
+parameter. The task can be woken up by the dispatch of a signal,
+in that case the residual time is returned.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Mutex and condition variables}
+%----------------------------------------------------------------------------
+
+The Generic kernel provides a set of functions that are similar in
+the interface with the correspondents POSIX functions that handles
+mutexes and condition variables.
+
+The extensions to the interface of the Resource Modules described
+in the previous chapter are used by these primitives to handle
+different shared resource access protocols in a general way.
+
+Le estensioni apportate all'interfaccia dei Moduli di Gestione
+delle Risorse descritte nella sezione precedente vengono
+utilizzate da tali primitive per gestire i vari protocolli di
+accesso a risorse condivise in modo trasparente.
+
+In particular, the proposed interfaces are the following (for a
+better description look at the POSIX standard):
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int mutex\_init(mutex\_t {*}mutex, const mutexattr\_t {*}attr);}}
+%----------------------------------------------------------------------------
+
+This primitive can be used to init a task descriptor. The attr
+parameter should be correctly initialized before the call. It can
+not be NULL.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int mutex\_destroy(mutex\_t {*}mutex);}}
+%----------------------------------------------------------------------------
+
+This function dealloc a mutex.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int mutex\_lock(mutex\_t {*}mutex);}}
+%----------------------------------------------------------------------------
+
+This function implements a blocking wait.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int mutex\_trylock(mutex\_t {*}mutex);}}
+%----------------------------------------------------------------------------
+
+This function implements a non blocking wait.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int mutex\_unlock(mutex\_t {*}mutex);}}
+%----------------------------------------------------------------------------
+
+This functions unlocks a mutex.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int cond\_init(cond\_t {*}cond);}}
+%----------------------------------------------------------------------------
+
+This function initializes a condition variable.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int cond\_destroy(cond\_t {*}cond);}}
+%----------------------------------------------------------------------------
+
+This function destroys a condition variable.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int cond\_signal(cond\_t {*}cond);}}
+%----------------------------------------------------------------------------
+
+This function signals on a condition variable. Only one task is
+unblocked.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int cond\_broadcast(cond\_t {*}cond);}}
+%----------------------------------------------------------------------------
+
+This function signals on a condition variables, unblocking all the
+task blocked on the condition variable.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int cond\_wait(cond\_t {*}cond, mutex\_t {*}mutex);}}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int cond\_timedwait(cond\_t {*}cond, mutex\_t {*}mutex, }}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{const struct timespec {*}abstime);}}
+%----------------------------------------------------------------------------
+
+The task that exec this primitive blocks and the mutex passed as
+parameter is unlocked to be required when the task restarts. There
+are two versions of the primitive, and one has a timeout to limit
+blocking times. These functions are cancellation points. If a
+cancellation request is generated for a task blocked on a
+condition variable, the task will end after reaquiring the mutex.
+This implies that each call have to be protected by cleanup
+functions that should free the mutex in a correct way.
+
+%----------------------------------------------------------------------------
+\section{Other primitives}
+\label{Kernel_Altreprimitive}
+%----------------------------------------------------------------------------
+
+In this section a set of other primitives are shortly described.
+They are implemented in the source files contained into the kernel
+directory.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void task\_endcycle(void);}}
+%----------------------------------------------------------------------------
+
+This primitive terminates the current instance of a task (look at
+Section \ref{SchedModules_Lifecycle}).
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void task\_abort(void);}}
+%----------------------------------------------------------------------------
+
+This primitive ends the task.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void group\_kill(WORD g);}}
+%----------------------------------------------------------------------------
+
+This primitive send a kill request to all the tasks that have the
+group g.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{TIME sys\_time(struct timespec {*}t);}}
+%----------------------------------------------------------------------------
+
+This primitive can be used into the applications to read the
+system time. Its behaviour is equal to the \texttt{ll\_gettime}
+but it is executed with interrupt disabled.
/branches/new_sharkdoc/vol4/kernel.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/models.tex
===================================================================
--- branches/new_sharkdoc/vol4/models.tex (nonexistent)
+++ branches/new_sharkdoc/vol4/models.tex (revision 1676)
@@ -0,0 +1,474 @@
+%----------------------------------------------------------------------------
+\chapter{Models}
+%----------------------------------------------------------------------------
+
+In this chapter we will described in detail the Models used in the
+Generic Kernel. For a general description of the Models see
+Section \ref{oview_Models}.
+
+%----------------------------------------------------------------------------
+\section{Data structures}
+\label{Modelli_MetodologiaOOP}
+%----------------------------------------------------------------------------
+
+The approach used in the definition of the kernel data structures
+is similar to that used in Object Oriented Languages.
+
+In fact, there are many situations in which the kernel needs to
+define data structures that can be thought as a \emph{base class},
+which will be extended by the Modules that use it. For example,
+the Kernel has to manage Task Models to know the stack size of a
+task, but it does not have to know fields like priorities,
+deadlines, and so on. Such data have to be stored into the task
+model, because they represent a QoS specification for the Module
+that will handle the task.
+
+For this reason, the Generic Kernel only defines a C
+\texttt{struct} that contains only the information that it needs
+(and that is common to all the derived structures). If a Module
+needs to extend that base class, it creates another
+\texttt{struct} whose first field specifies the base class
+type%
+\footnote{In this way the derived struct will inherit the fields
+from the base
+class.%
+}, whereas the other fields extend the base class.
+
+In this way, both the Generic Kernel and the Modules can accept a
+pointer to the base class to access the required information.
+
+When the Kernel primitives are used, a pointer to a derived class
+is passed instead of a pointer to the base class. Because the
+first field of a derived class is of the base class type, the
+pointer passed addresses the correct memory structure (the C
+structures are stored using the declaration order), and the
+Generic Kernel can safely handle the generic part of the
+structure.
+
+Viceversa, when a Module interface function receives from the
+Generic Kernel a pointer to a base class, it will cast explicitly
+the struct to the correct derived type, getting the extensions of
+the derived class.
+
+As it can be seen, this approach is a way to implement single
+inheritance and polymorphism in the C language.
+
+%----------------------------------------------------------------------------
+\section{Task Models }
+%----------------------------------------------------------------------------
+
+The Task Models are implemented, as described in the previous
+paragraph, through extensions to a base class. In the following
+paragraph base class is described with the main extensions to it.
+
+The Task Models that are included in the official distribution of
+the Kernel are declared into the file
+\texttt{include/kernel/model.h}.
+
+%----------------------------------------------------------------------------
+\subsection{\texttt{TASK\_MODEL}}
+\label{Modelli_TASK_MODEL}
+%----------------------------------------------------------------------------
+
+This is the base structure for the Task Models. Its definition is
+showed in Figure \ref{Modelli_struct_TASK_MODEL}.
+
+\begin{figure}
+\begin{center}
+\begin{minipage}{6cm}
+\begin{verbatim}
+typedef struct {
+ WORD pclass;
+ LEVEL level;
+ size_t stacksize;
+ void *stackaddr;
+ WORD group;
+ void *arg;
+ DWORD control;
+} TASK_MODEL;
+\end{verbatim}
+\end{minipage}
+\end{center}
+\label{Modelli_struct_TASK_MODEL}
+\caption{the \texttt{struct TASK\_MODEL}.}
+\end{figure}
+
+In the following paragraph each field of that structure is described.
+
+\begin{description}
+\item [\texttt{pclass}]this field contains an identifier that represents the
+real (derived) type of the structure. The \texttt{pclass} fields of the derived
+class that are included into the official distribution are included into the
+file \texttt{include/kernel/model.h}. The \texttt{pclass} field is a 16 bit
+integer \item [\texttt{level}]this field identifies a particular level to which
+the task must be inserted in preference. 0 means ``all levels'' \footnote{We
+recall that the Scheduling Modules are organized in levels. The Task Models are
+used when a task is created and they are passed to the Modules to find a Module
+that can handle the Model. All the Modules accepts Models in which the
+\texttt{level} field are 0 or the level number in which the Module is
+registered. In this way it is possible to distinguish Task Models that are
+related to different Modules when there are many Modules that can accept the
+same Model.}.
+\item [\texttt{stacksize}]this is the dimension (in bytes)
+required for the stack of the task to be created. The Generic
+Kernel provides allocation and deallocation of the stack of the
+tasks (only if the parameter \texttt{stackaddr} is not specified).
+\item [\texttt{stackaddr}]this is a memory pointer that can be used as stack for
+the task to be created. If this parameter is specified, the \texttt{stacksize}
+field is ignored when a task is created. The memory pointed by
+\texttt{stackaddr} is not deallocated at the termination of the task
+(deallocation must be done by the creating task. There is no check on the
+dimension of the memory area pointed by \texttt{stackaddr}.
+\item [\texttt{group}]the tasks in the Generic
+Kernel are divided into groups. The group of a task is specified
+when a task is created, using this field. A group is a number that
+is common to a set of tasks in the system. This identifier is used
+by the primitives \texttt{group\_activate} and
+\texttt{group\_kill} to activate or kill a set of tasks in an
+atomic way.
+\item [\texttt{arg}]the body of a task created into
+the system is a function that accepts a \texttt{void~*}
+parameter. That parameter is passed at the first activation of a
+task and it is specified in this field.
+\item [\texttt{control}]this field contains a set of flags that represents
+features of the task to be created and represents also some particular states of
+a running task. Flags are set by the user at creation time or they can be set by
+some primitives. The defined flags are:
+
+\begin{description}
+\item [\texttt{USE\_FPU}]This flag is used by the OS Lib to notify
+the system that the task uses in its code some floating point
+operation. This information is used by the OS Lib to guarantee
+that the FPU state is saved at each context switch. \item
+[\texttt{NO\_KILL}]If this flag is set the task cannot be killed
+through a \texttt{task\_kill} primitive. This flag is also used at
+the shutdown of the kernel (see Section \ref{Kernel_TaskUtente}),
+and it can be specified only at the task creation. \item
+[\texttt{NO\_PREEMPT}]If this flag is set, the running task cannot
+be preempted by another task, but it can be interrupted by a
+device handler. In other words, the scheduler is disabled. This
+flag is modified by the primitives \texttt{task\_preempt} and
+\texttt{task\_nopreempt}. \item [\texttt{SYSTEM\_TASK}]If set this
+flag marks the task as a system task. It can be specified only at
+creation time. The fact that a task is or not a system task
+affects the system shutdown (see Section \ref{Kernel_TaskUtente}).
+\item [\texttt{JET\_ENABLED}]This flag can be set only at task
+creation time and when set specifies that the Generic Kernel must
+register the Job Execution Time statistics. \item
+[\texttt{TASK\_JOINABLE}]This flag is set if another task can wait
+for the task termination through the \texttt{task\_join} primitive
+(see Section \ref{Kernel_Join}). \item
+[\texttt{STACKADDR\_SPECIFIED}]This flag is set by the creation
+primitive if the \texttt{stackaddr} field was specified. At
+termination time, if this flag is not set, the stack space is
+deallocated by the Kernel; otherwise, the stack space is left
+according to the POSIX standard. \item [\texttt{TRACE\_TASK}]This
+flag is set if the tracer has to monitor the task events. \item
+[\texttt{KILLED\_ON\_CONDITION}]This flag is used in the
+implementation of the condition variables. This flag is set by the
+Generic Kernel if a task is killed while it is blocked on a
+condition variable. In this case the task must be rescheduled to
+reaquire the mutex linked to the condition variable. \item
+[\texttt{KILL\_ENABLED}]This flag is set if the cancellation (in a
+POSIX meaning) is or not enabled. \item
+[\texttt{KILL\_DEFERRED}]This flag is set if the cancellation (in
+a POSIX meaning) is deferred (the cancellation is asynchronous if
+not). \item [\texttt{KILL\_REQUEST}]This flag registers a
+cancellation request made with one of these primitives:
+\texttt{task\_kill}, \texttt{group\_kill},
+\texttt{pthread\_testcancel}. \item [\texttt{CONTROL\_CAP}]This
+flag is used in the Scheduling Modules to tell Generic Kernel to
+generate an OS Lib event when the running task terminates its
+capacity. \item [\texttt{TASK\_DOING\_SIGNALS}]This flag is set by
+the Generic Kernel when the task is executing a signal handler.
+This flag is used only in the function
+\texttt{kern\_deliver\_pending\_signals}, contained in the file
+\texttt{kernel/signal.c}. \item [\texttt{FREEZE\_ACTIVATION}]This
+flag blocks the task activations done through the primitives
+\texttt{task\_activate} and \texttt{group\_activate}.
+
+
+The flag is modified by the primitives \texttt{task\_block\_activation} and
+\texttt{task\_unblock\_activation}.
+
+\item [\texttt{WAIT\_FOR\_JOIN}]This flag is set when a task
+terminates, but only if a task is joinable. The flag is used to
+register that the task is terminated and it is waiting for someone
+to do a join on it to die. \item
+[\texttt{DESCRIPTOR\_DISCARDED}]This flag is used in the
+implementation of the join primitive, and it is set by the
+primitive \texttt{task\_create} to notify that a task descriptor,
+whose task is terminated and is waiting for a join, has been
+chosen and discarded for the creation of a new task. \item
+[\texttt{SIGTIMEOUT\_EXPIRED}]This flag is set for the task
+blocked on a \texttt{sigtimedwait} primitive, when the timeout
+event fires.
+\end{description}
+
+\end{description}
+
+The internal data structures of a \texttt{TASK\_MODEL} should be
+used only into the Generic Kernel and into the Modules. For this
+reason the system provides a set of macros that can be used to set
+the required values in a base class object. In all the described
+macros the parameter \texttt{m} is a \texttt{TASK\_MODEL}. The
+macro are described below:
+
+\begin{description}
+\item [\texttt{task\_default\_model(m,p)}]This macro initializes
+the Model \texttt{m} to a default value. The \texttt{pclass} of
+\texttt{m} becomes equal to the \texttt{p} parameter. \item
+[\texttt{task\_def\_level(m,l)}]This macro specifies the
+scheduling level \texttt{l} of Model \texttt{m}. \item
+[\texttt{task\_def\_arg(m,a)}]This macro specifies the parameter
+passed to the first activation of the task initialized with Model
+\texttt{m}. \item [\texttt{task\_def\_stack(m,s)}]This macro is
+used to specify the stack dimension of the task initialized with
+Model \texttt{m}. \item [\texttt{task\_def\_stackaddr(m,s)}]This
+macro is used to specify a memory address pointer to be used as a
+stack for the task initialized with Model \texttt{m}. \item
+[\texttt{task\_def\_group(m,g)}]This macro is used to specify the
+group of tasks initialized with Model \texttt{m}. \item
+[\texttt{task\_def\_usemath(m)}]This macro is used to specify that
+the task initialized with Model \texttt{m} uses the mathematical
+coprocessor. \item [\texttt{task\_def\_system(m)}]This macro is
+used to specify that the task that is initialized with Model
+\texttt{m} is a system task. \item
+[\texttt{task\_def\_nokill(m)}]This macro is used to specify that
+the task initialized with Model \texttt{m} cannot be killed. \item
+[\texttt{task\_def\_ctrl\_jet(m)}]This macro is used to specify
+that the task initialized with Model \texttt{m} requires the
+monitoring of the job execution time. \item
+[\texttt{task\_def\_joinable(m)}]This macro is used to specify
+that the task initialized with Model \texttt{m} can be passed as a
+parameter into the join primitive. \item
+[\texttt{task\_def\_unjoinable(m)}]This macro is used to specify
+that the task initialized with Model \texttt{m} cannot be passed
+as parameter into the join primitive. \item
+[\texttt{task\_def\_trace(m)}]This macro is used to specify that
+the task initialized with Model \texttt{m} is a task for which the
+system tracer will register some information about the events
+related to it. \item [\texttt{task\_def\_notrace(m)}]This macro is
+used to specify that the task initialized with Model \texttt{m} is
+a task for which the system tracer will not register any
+information.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Used conventions}
+%----------------------------------------------------------------------------
+
+In normal situations the final user never needs to instantiate an
+object of type \texttt{TASK\_MODEL}, but objects of a type derived
+from it. Also the macro described in the previous paragraph cannot
+be used directly; instead, there are similar macros redefined for
+the derived types.
+
+The standard used in the inheritance of a Model from the base
+model are the following:
+
+\begin{enumerate}
+
+\item The name of the derived class is obtained from the name of the base class
+by adding a prefix. For example, the task Model for the Soft task is called
+\texttt{SOFT\_TASK\_MODEL}.
+
+\item The first field of a derived structure is a structure with name \texttt{t}
+and type \texttt{TASK\_MODEL}.
+
+\item The specific parameters added to the models (e.g., period, wcet, etc.) are
+inserted as normal fields after the first field. These fields represent a
+specification of the Quality of Service required by a task to the system at
+creation time. The Scheduling Modules can be structured in a way that they may
+use only a subset of the fields of a Model \footnote{For example, to create a
+Soft Task Model it is useful to insert two parameters like period and mean
+execution time; these parameters are mandarory for the Scheduling Module that
+implements CBS, whereas they are ignored by a Scheduling Module that implements
+a Polling Server.}. This approach limits the growth of the number of Models and
+achieves better independence of the applications from the task models
+\footnote{For example, an Application can use a Soft Task Model specifying all
+the Model parameters, without knowing which Scheduling Module is really used,
+e.g. CBS or Polling Server).}.
+
+\item The macros defined for the \texttt{TASK\_MODEL} struct and described in
+the previous paragraph must also be defined for the new model. They should be
+rewritten with a name derived from the old name, like the example below:
+\begin{center}
+\fbox{\tt{
+ \#define soft\_task\_def\_level(m,l) task\_def\_level((m).t,l)
+}}
+\end{center}
+
+\item The new model should provide a set of private macros similar to those
+provided with the \texttt{TASK\_MODEL} to handle the new fields of the derived
+structure. For example, if the new model has a field called \texttt{period}
+(that contains for example a reactivation period), the new macro should be
+similar to the one shown below:
+\begin{center} \fbox{\tt{
+ \#define soft\_task\_def\_period(m,p) (m).period = (p)
+}}
+\end{center}
+\end{enumerate}
+
+The five rules described above simplify the definition of new
+models allowing the user to cut and paste the code of a similar
+model and to modify some prefixes.
+
+%----------------------------------------------------------------------------
+\subsection{Examples of Models currently integrated into the Kernel}
+%----------------------------------------------------------------------------
+
+Currently the Kernel defines a set of Task Models directly derived
+from the base TASK\_MODEL class. In the following paragraphs they
+are briefly described (for their definition look in the file
+\texttt{include/kernel/model.h}).
+
+\begin{description}
+\item [\texttt{HARD\_TASK\_MODEL}]~
+
+
+This Task Model can be used to model Hard Periodic and Sporadic tasks. A Hard
+Periodic Task \footnote{The \texttt{periodicity} field of the model must be set
+to \texttt{PERIODIC}.} is a task guaranteed using an activation period and a
+wcet \footnote{Worst Case Execution Time.}, whereas a Hard Sporadic Task
+\footnote{The \texttt{periodicity} field of the model must be set to
+\texttt{APERIODIC}.} is an aperiodic task guaranteed on a minimum interarrival
+time and a wcet.
+
+The Model allows the specification of a relative deadline. If not
+specified, the deadline is assumed to be equal to the next
+reactivation time (as in the classical task model proposed by Liu
+and Layland \cite{Liu73}).
+
+The Model also allows a release offset to be specified. This means
+that any activation should be delayed by the given offset.
+
+\end{description}
+
+A Module that accepts tasks with this Model can raise the
+following exceptions:
+
+\begin{description}
+\item [\texttt{XDEADLINE\_MISS}]This exception is raised if the
+task misses a deadline.
+
+\begin{description}
+\item [\texttt{XWCET\_VIOLATION}]This exception is raised if the
+task tries to use more CPU time than declared.
+
+\item [\texttt{XACTIVATION}]This exception is raised if a sporadic task is
+activated with a frequency greater than that declared.
+\end{description}
+
+\item [\texttt{SOFT\_TASK\_MODEL}]
+
+
+This Task Model is used to specify the QoS required by a soft
+task. A soft task is a periodic or aperiodic task, which is
+handled by a server with a given (guaranteed) bandwidth (i.e.,
+which allocates a budget Qs every interval Ts).
+
+A soft task can specify, using a specific field, if it wants to save or skip
+pending activations. A pending activation occurs when a task is activated before
+the end of its current instance \footnote{It may happen when the reserved
+bandwidth is less than the maximum task's utilization.}. The Scheduling Modules
+can choose whether to handle or not this situation. Pending activations
+influence the behavior of the \texttt{task\_sleep} and \texttt{task\_endcycle}
+primitives.
+
+The Soft Task Model has also a field which contains a wcet. This
+field can be required by some algorithm that requires this
+information (for example, the TBS algorithm.
+
+Usually, the Modules that accept the soft task model do not raise
+any exception.
+
+\item [\texttt{NRT\_TASK\_MODEL}]
+
+This Task Model is typically used to support non real-time
+computations performed by tasks without temporal requirements.
+
+Typical Modules that use these Models are Modules that implement
+scheduling algorithms like Round Robin, Proportional Share,
+priority scheduling, and POSIX scheduling.
+
+The model has also a field to specify whether a Task have to save
+or skip pending activations.
+
+Finally, the Model has two other fields (\texttt{inherit} and \texttt{policy})
+used in the implementation of the POSIX scheduling algorithm \footnote{This is
+one of the (rare) cases in which the Task Model depends on a specific Scheduling
+Module.}.
+
+\item [\texttt{JOB\_TASK\_MODEL}]
+
+This Task Model is normally used by an Aperiodic Server to pass a
+task to a Master Module. It is not explicitly used in the
+Application code.
+
+This Model extends the Base Model with a deadline and a period. A
+Job is a single a task instance which starts and stops without
+synchronization points in between.
+
+Typically, an aperiodic server inserts a Job in the Master Module
+to ask for service. When that task ends its instance or it blocks
+on a synchronization variable, the Job dies and it is newly
+recreated when the task is reactivated or when it resumes from
+blocking.
+
+There are no fields that specify computation times (i.e., wcet,
+met) because the Aperiodic Servers that use that Model generally
+handle a budget.
+
+The Model contains another field that specifies whether a Master
+Module should raise a deadline exception when a deadline is
+reached and the Job is still alive.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Resource Models}
+\label{Modelli_RES_MODEL}
+%----------------------------------------------------------------------------
+
+The resource Models are implemented in a way similar to the Task
+Models. The difference between Task Models and Resource Models is
+that it is not possible to group a set of fields common to all
+Resource Handlers. For this reason, the C structure that
+represents the base class of a Resource Model contains only a
+field that provides information about the real type of a Resource
+Model. As done for the Task Models, that field is called
+\texttt{rclass}.
+
+The Resource Models available in the kernel are used in the
+implementation of the Priority Ceiling Protocol and the Stack
+Resource Policy.
+
+In the case of Priority Ceiling, the Resource Model only adds a
+static priority of the task to be created.
+
+In the case of SRP, the Resource Model only adds the definition of
+the Preemption Level of the task.
+
+The Resource Models contained into the official distribution of
+the Kernel are included into the file
+\texttt{include/kernel/model.h}.
+
+%----------------------------------------------------------------------------
+\section{Mutex attributes}
+%----------------------------------------------------------------------------
+
+The protocol used by a mutex is decided when the mutex is
+initialized (at run time).
+
+To implement the mutex initialization in a modular fashion we
+derived a structure, called \texttt{mutexattr\_t}, from a base
+structure similar to that used in the Resource Models
+
+We derived a set of mutex attributes to be used in the
+initialization of a mutex (a mutex is contained in a
+\texttt{mutex\_t} type, which is similar to the POSIX's
+\texttt{pthread\_mutex\_t}).
+
+The Mutex Attributes are declared into the file
+\texttt{include/kernel/model.h}.
/branches/new_sharkdoc/vol4/models.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/vol4.tex
===================================================================
--- branches/new_sharkdoc/vol4/vol4.tex (nonexistent)
+++ branches/new_sharkdoc/vol4/vol4.tex (revision 1676)
@@ -0,0 +1,51 @@
+\documentclass[american,english]{report}
+\usepackage[T1]{fontenc}
+\usepackage[latin1]{inputenc}
+\usepackage{geometry}
+\geometry{verbose,a4paper}
+\usepackage{array}
+\usepackage{graphicx}
+
+\makeatletter
+
+\usepackage{babel}
+\makeatother
+
+\begin{document}
+\thispagestyle{empty}
+
+\begin{center}{\LARGE S.Ha.R.K. User Manual}\end{center}{\LARGE \par} \vfill{}
+\begin{center}Volume IV\end{center}
+\begin{center}S.Ha.R.K. Kernel Architecture\end{center}
+\vfill{}
+
+\begin{center}Written by\end{center}
+\begin{center}Giorgio Buttazzo (giorgio at sssup.it)\end{center}
+\begin{center}Paolo Gai (pj at sssup.it)\end{center}
+\begin{center}Luigi Palopoli (luigi at hartik.sssup.it)\end{center}
+\begin{center}Marco Caccamo (caccamo at sssup.it)\end{center}
+\begin{center}Giuseppe Lipari (lipari at sssup.it) \end{center}
+\begin{center}Tullio Facchinetti (tullio.facchinetti at unipv.it) \end{center}
+\vfill{}
+
+\begin{center}\includegraphics[width=2cm]{../common/sssup.ps}\end{center}
+\begin{center}Scuola Superiore di Studi e Perfezionamento S. Anna\end{center}
+\begin{center}RETIS Lab\end{center}
+\begin{center}Via Carducci, 40 - 56100 Pisa\end{center}
+
+\pagebreak
+
+\tableofcontents{}
+
+\include{kernel_overview}
+\include{models}
+\include{kernsupport}
+\include{scheduling_modules}
+\include{resource_modules}
+\include{examples}
+\include{kernel}
+
+\bibliographystyle{plain}
+\bibliography{../common/retis}
+
+\end{document}
/branches/new_sharkdoc/vol4/vol4.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/kernel_overview.tex
===================================================================
--- branches/new_sharkdoc/vol4/kernel_overview.tex (nonexistent)
+++ branches/new_sharkdoc/vol4/kernel_overview.tex (revision 1676)
@@ -0,0 +1,824 @@
+%----------------------------------------------------------------------------
+\chapter{Kernel Overview}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\section{Scheduling Architecture}
+%----------------------------------------------------------------------------
+
+S.Ha.R.K. is a research kernel expressly designed to help the
+implementation and testing of new scheduling algorithms, both for
+the CPU and for shared resources. In order to achieve independence
+between applications and scheduling algorithms (and between the
+schedulers and the kernel), S.Ha.R.K. is based on a \emph{Generic
+Kernel}, which does not implement any particular scheduling
+algorithm, but postpones scheduling decisions to external
+entities, the \emph{scheduling modules}. In a similar fashion, the
+access to shared resources is coordinated by \emph{resource
+modules}. External modules can implement periodic scheduling
+algorithms, soft task management through real-time servers,
+semaphore protocols, and resource management policies. The modules
+implementing the most common algorithms (such as RM, EDF, Round
+Robin, and so on) are already provided, and it is easy to develop
+new modules. A scheme of the kernel architecture is depicted in
+Figure \ref{oview_Fig_KernelArchitecture}.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=8cm]{images/oview_Architecture.eps}
+\end{center}
+\label{oview_Fig_KernelArchitecture}
+\caption{The S.Ha.R.K. Architecture}
+\end{figure}
+
+The OS Lib layer implements an abstraction of a generic machine
+capable of exporting some services, as for example context
+switching, time management, interrupts handling, and a subset of
+the run-time C library. For detailed information about the OS Lib,
+see \cite{Abe00-1}\cite{Abe00-2}.
+
+The Generic Kernel provides the mechanisms used by the modules to
+perform scheduling and resource management thus allowing the
+system to abstract from the specific algorithms that can be
+implemented. The Generic Kernel simply provides the primitives
+without specifying any algorithm, whose implementation resides in
+external modules, configured at run-time with the support of the
+\emph{Model Mapper} (see Section \ref{oview_Models}).
+
+Another important component of the Generic Kernel is the Job
+Execution Time (JET) estimator, which monitors the computation
+time actually consumed by each job. This is a generic mechanism,
+independent from the scheduling algorithms, that can be used for
+statistical measurements, for enforcing temporal protection, or
+for resource accounting (see Section \ref{Kernel_Jet}).
+
+The API is exported through the \emph{Libraries}, which use the
+Generic Kernel to support some common hardware devices (i.e.,
+keyboard, sound cards, network cards, graphic cards) and provide a
+compatibility layer with the POSIX Real-time Controller System
+Profile \cite{POSIX1003.13}.
+
+An Application can be considered as a set of cooperating tasks \footnote{In this
+document, a process is a set of computations performed in a private address
+space. A thread is a single execution flow in a process. Each thread is
+identified by an unique ID, plus some specific parameters. The term Task is used
+as a synonymous of the term thread.} that share a common address space. There is
+no memory protection implemented into the Kernel. Intertask communication is
+performed using shared memory buffers accessed through some synchronization
+mechanisms (as mutexes, condition variables, semaphores, CAB, message queues).
+Each task is characterized by a Task Model, some optional Resource Models, and a
+body. The body of a task is simply a C function with the prototype \texttt{void
+*body(void *arg)}.
+
+An Application can use the following sets of functions:
+
+\begin{itemize}
+\item The functions exported by the OS Lib;
+\item The Generic Kernel primitives;
+\item Some Module-dependent functions;
+\item Some functions exported by libraries, device drivers, or the standard C
+library;
+\item The library implementing of the POSIX standard interface.
+\end{itemize}
+
+Each Module consists of a set of data and functions used for
+implementing a specific algorithm, whose implementation is
+independent from the other modules in the system, thus realizing a
+trade-off between user-level and in-kernel schedulers. In this
+way, many different module configurations are possible. For
+example, a Polling Server can either work with a RM or an EDF
+scheduling Module without any modification.
+
+Currently, S.Ha.R.K. provides two basic modules:
+
+\begin{itemize}
+\item modules that implement scheduling algorithms and aperiodic service
+policies (Scheduling Modules);
+\item modules that manage shared (hardware or software) resources (Resource
+Modules);
+\end{itemize}
+
+All resource access protocols, such as Priority Inheritance, are
+implemented as a mutex module whose interface is derived from the
+resource module interface. A POSIX mutex interface is also
+provided on top of the implemented protocols.
+
+Each type of Module provides a well defined interface to
+communicate with the Generic Kernel (user programs do not directly
+interact with the modules). The interface functions are called by
+the Generic Kernel to implement the kernel primitives. When
+modules need to interact with the hardware (for example, the
+timer), they can use the service calls provided by the Generic
+Kernel.
+
+Finally, each Module has some unique identifiers to allow the
+implementation of some consistency checks (for example, a module
+that implements a Total Bandwidth Server cannot work with Rate
+Monotonic).
+
+%----------------------------------------------------------------------------
+\section{QoS Specification}
+%----------------------------------------------------------------------------
+
+\label{oview_Models} One of the goals of S.Ha.R.K. is to allow the
+user to easily implement and test novel scheduling algorithms. In
+particular, the kernel has been designed with the following
+objectives:
+
+\begin{itemize}
+\item achieve independence between the kernel mechanisms and the
+scheduling policies for tasks and resource management; \item
+configure the system at run-time by specifying the algorithms to
+be used for task scheduling and resource access; \item achieve
+independence between applications and scheduling algorithms.
+\end{itemize}
+
+These requirements are particularly useful for comparing the
+performance of similar algorithms on the same application. In
+fact, module independence allows the user to configure and test
+applications without recompile them, only relinking them.
+
+Independence between applications and scheduling algorithms is
+achieved by introducing the concept of \emph{model}. Each task
+asks the system to be scheduled according to a given Quality of
+Service (QoS) specified by a model. In other words, a model is the
+entity used by S.Ha.R.K. to separate the scheduling parameters
+from the QoS parameters required by each task. In this way, the
+kernel provides a common interface to isolate the task QoS
+requirements from the real scheduler implementation.
+
+Models are descriptions of the scheduling requirements expressed
+by tasks. S.Ha.R.K. provides three different kinds of models:
+
+\begin{description}
+\item [Task~Models.]A task model expresses the QoS requirements of
+a task for the CPU scheduling. Requirements are specified through
+a set of parameters at task creation time. Some of the task
+requirements are mandatory (e.g., the stack size of a task), while
+others depend on the specific task model (e.g., a deadline). For
+this reason, all task models are characterized by a general common
+part, which can be extended by a model-dependent part. Usually,
+the model-dependent part abstracts from a specific scheduling
+algorithm (for instance, the concept of period or deadline is
+independent from a specific algorithm like EDF or RM). The task
+models have a function similar to the \texttt{pthread\_attr\_t}
+structure defined in the POSIX standard. \item [Resource~Models.]A
+resource model is used to define the QoS parameters relative to a
+set of shared resources used by a task. For example, the resource
+model can be used to specify the semaphore protocol to be used for
+protecting critical sections (e.g., Priority Inheritance, Priority
+Ceiling, or SRP). In other cases, the resource model can be used
+to specify a hardware resource scheduling algorithm (e.g. a File
+System Scheduling Algorithm). \item [Mutex~Models.]When a mutex
+semaphore is created, these Models are used to specify the
+resource access protocol to be used, in a way similar to that done
+with Task Models. The mutex models have a function similar to the
+\texttt{pthread\_mutexattr\_t} structure defined in the POSIX
+standard.
+\end{description}
+
+Each task is characterized by a single mandatory QoS parameter,
+the \emph{task criticality} (hard, soft, firm, non real-time, and
+so on). This parameter belongs the common part of the task model,
+together with a \emph{model identifier} and some other parameters,
+such as the stack size.
+
+Each task model is implemented as a C structure, in which the
+first field is the model identifier, the next fields are the
+mandatory parameters and the last field is a sequence of bytes
+containing the model-dependent parameters, that only the specific
+module can interpret. Resource models are completely generic, and
+depend on the resource they describe: the only mandatory parameter
+is the model identifier.
+
+Models are required to make the generic kernel independent from
+the implemented scheduling algorithms: since the generic kernel
+does not implement any algorithm, it does not know how to serve a
+task but invokes a service request to scheduling entities realized
+as external \emph{modules}. Hence, the generic kernel does not
+interpret the models, but just passes them to the modules; each
+module, by reading the common part of the model, can verify
+whether the task can be served or not.
+
+Using models an application is able to specify the requested QoS,
+independently from the modules used into the system. For example,
+an application that creates a task using an Hard Task Model can be
+executed on an EDF, a RM, or a Deadline Monotonic
+Module.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=11cm]{images/oview_QOSMapper.eps}
+\end{center}
+\label{oview_Fig_QOSMapper}
+\caption{The interaction between the Model Mapper and the QOS Mapper.}
+\end{figure}
+
+Task creation works as follows (see Figure
+\ref{oview_Fig_QOSMapper}): when an application issues a request
+to the kernel for creating a new task, it also sends the model
+describing the requested QoS. A kernel component, namely the
+\emph{model mapper}, passes the model to a module, selected
+according to an internal policy, and the module checks whether it
+can provide the requested QoS; if the selected module cannot serve
+the task, the model mapper selects a different module. When a
+module accepts to manage the task described by the specified
+model, it converts the model's QOS parameters into the appropriate
+scheduling parameters. Such a conversion is performed by a module
+component, called the \emph{QoS Mapper}. For example, a hard
+periodic task may have a model consisting of a period and a
+worst-case execution time (WCET); when a task is created with that
+model, the EDF module will convert such parameters into deadlines,
+reactivation times, and so on. In general, a module can manage
+only a subset of the models, and the set of models is not limited
+by the kernel. This is possible because the kernel does not handle
+the models, but it simply passes them to the Model Mapper, that
+selects a module and passes the model to that module. Currently,
+the Model Mapper uses a simple strategy, according to which
+modules are selected based on fixed priorities (see Section
+\ref{oview_Module_Organization} for more details).
+
+%----------------------------------------------------------------------------
+\section{Scheduling Modules}
+%----------------------------------------------------------------------------
+
+Scheduling Modules are used by the Generic Kernel to schedule
+tasks, or serve aperiodic requests using an aperiodic server. In
+general, the implementation of a scheduling algorithm should
+possibly be independent on resource access protocols, and handle
+only the scheduling behavior. Nevertheless, the implementation of
+an aperiodic server relies on the presence of another scheduling
+module, called the Master Module
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=4cm]{images/oview_Server_e_Master.eps}
+\end{center}
+\label{oview_Fig_MasterModule}
+\caption{An aperiodic Server that inserts its tasks into a master module.}
+\end{figure}
+
+(for example, a Deferrable Server can be used if the base
+scheduling algorithm is RM or EDF, but not Round Robin; see Figure
+\ref{oview_Fig_MasterModule}). Such a design choice reflects the
+traditional approach followed in the literature, where most
+aperiodic servers insert their tasks directly into the scheduling
+queues of the base scheduling algorithm. Again, our modular
+approach masks this mechanism with the task models: an aperiodic
+server must use a task model to insert his tasks into the Master
+Module.
+
+The Model Mapper distributes the tasks to the registered modules
+according to the task models the set of modules can handle. For
+this reason, the task descriptor includes an additional field
+(\texttt{task\_level}), which points to the module that is
+handling the task.
+
+When the Generic Kernel has to perform a scheduling decision, it
+asks the modules for the task to schedule, according to fixed
+priorities: first, it invokes a scheduling decision to the highest
+priority module, then (if the module does not manage any task
+ready to run), it asks the next high priority module, and so on.
+In this way, each module manages its private ready task list, and
+the Generic Kernel schedules the first task of the highest
+priority non empty module's queue.
+
+A Scheduling Module must include all the data structures needed.
+It can be thought as an object in an Object oriented language;
+this implies that many instances of a module can be created (for
+example, many TBS servers with different bandwidth).
+
+%----------------------------------------------------------------------------
+\subsection{Module Organization}
+\label{oview_Module_Organization}
+%----------------------------------------------------------------------------
+
+The Scheduling Modules are organized into levels, one Module for
+each level. These levels can be thought as priority scheduling
+levels (index 0 has the maximum priority).
+
+Modules are selected for scheduling by the Model Mapper by a fixed
+priority strategy. When a task is given to a module, the module
+\emph{owns} the task. The \texttt{task\_level} field of the
+generic task descriptor is used to save the level index of the
+Module that handles the task (see Section
+\ref{KernSupport_Task_descriptor}).
+
+Each Scheduling Module handles all the events that belong to its
+owned tasks. A task owned by a module is scheduled in background
+with respect to the tasks owned by a Module with higher level
+index. For example, in Figure \ref{oview_Levels}, the tasks
+\emph{scheduled}%
+\footnote{Note that the word \emph{scheduled} is emphasized: the
+tasks \emph{scheduled} by a Module are the tasks owned by the
+Module itself and the tasks that other modules have inserted in
+it.%
+} by the XXX Scheduling Module are run in foreground; the tasks
+scheduled by the WWW Module run in background with respect to
+those of the XXX and YYY Modules, and in foreground with respect
+to the tasks scheduled by the ZZZ Module.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=6cm]{images/oview_Levels.eps}
+\end{center}
+\label{oview_Levels}
+\caption{Kernel Level Organization.}
+\end{figure}
+
+%----------------------------------------------------------------------------
+\subsection{Sample scheduling architectures}
+%----------------------------------------------------------------------------
+
+The approach followed in the organization of the Scheduling
+Modules is very versatile and allows to implement different Kernel
+configurations. In the following, some typical scheduling
+architectures are described.
+
+\begin{description}
+\item [Fixed~Priority~Scheme.]This is the most typical approach
+used in the real-time systems (see Figure
+\ref{oview_Power_FixedPriority}). In this example, hard tasks
+(periodic and sporadic) are served at the highest priority,
+whereas aperiodic tasks are handled by a Sporadic Server. At the
+lowest priority level non-realtime tasks can be handled by a Round
+Robin scheduling
+policy.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=7cm]{images/oview_Power_FixedPriority.eps}
+\end{center}
+\label{oview_Power_FixedPriority}
+\caption{A fixed priority Module configuration\textit{.}}
+\end{figure}
+
+\item [Dual~Priority~Scheme.]This configuration (described in
+Figure \ref{oview_Power_DualPriority}) proposes a combination of
+modules which were not developed to work together at
+implementation time. In this example, the highest priority tasks
+are scheduled by the RM with a Deferrable Server linked to it.
+Other tasks are scheduled at medium priority using EDF with a
+Total Bandwidth Server. At the lowest priority level, non-realtime
+tasks can be handled by a Round Robin scheduling scheme.. This
+configuration can be used to reduce the jitter of some important
+tasks \cite{Dav95}.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=7cm]{images/oview_Power_DualPriority.eps}
+\end{center}
+\label{oview_Power_DualPriority}
+\caption{A Dual Priority Module configuration. Note that the TBS Module is put
+at the lowest priority level to prevent the TBS algorithm from using the
+background time left by other modules.}
+\end{figure}
+
+\item [Dynamic~Multiserver.]This example (described in Figure
+\ref{oview_Power_Dynamic}) shows how to create a complex
+scheduling architecture. In the example, some Hard tasks are
+scheduled with a set of aperiodic tasks, each one handled by a
+different server. Note that the EDF Module is designed to accept
+tasks from a generic Module, independently from the algorithm
+implemented by that Module. Note also that in the system there are
+many instances of a single module, and each instance can only
+manage the tasks that it
+owns.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=8cm]{images/oview_Power_Dynamic.eps}
+\end{center}
+\label{oview_Power_Dynamic}
+\caption{Dynamic Module Configuration.}
+\end{figure}
+
+\item [Timeline~Scheduling.]The example illustrated in Figure
+\ref{oview_Power_Timeline} shows a Timeline scheduler integrated
+with a fixed priority algorithm, such as RM. Note that S.Ha.R.K.
+does not force the developer to use classic approaches, like
+prioritary task queues. The Generic Kernel does not impose any
+restrictions to developers.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=7cm]{images/oview_Power_Timeline.eps}
+\end{center}
+\label{oview_Power_Timeline}
+\caption{A hybrid Timeline-RM approach.}
+\end{figure}
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Module Interface}
+\label{oview_Module_Interface}
+%----------------------------------------------------------------------------
+
+The interface functions provided by a scheduling module can be
+grouped in two classes: public and private functions. In general,
+a scheduling module has an interface that implements a specific
+behavior for each event in the system generated by a task.
+
+In the following paragraph the various classes of functions are
+explained in a general way. Each function will be then described
+in detail in Chapter \ref{CapSchedulingModules}.
+
+%----------------------------------------------------------------------------
+\subsection{Public Functions}
+%----------------------------------------------------------------------------
+
+The public functions are those fuctions that are directly called
+by the Generic Kernel to implement the behavior of the primitives.
+Some of the functions are directly related to the life of a single
+task (e.g. task creation, task end), whereas other functions are
+related to the module as a whole (the scheduler, and the
+acceptance test).
+
+%----------------------------------------------------------------------------
+\subsection{Private Functions}
+%----------------------------------------------------------------------------
+
+On the other side, a module can export an interface to the public
+part of the same or of another module. For example, an EDF Module
+can export an interface (smaller than the Public Functions) that
+allows a generic aperiodic server to insert tasks in the EDF reqdy
+queue.
+
+That is, Private Functions are called ONLY by other Public and
+Private Functions. They are NEVER called by the Generic Kernel.
+
+%----------------------------------------------------------------------------
+\subsection{An Example}
+\label{oview_Example}
+%----------------------------------------------------------------------------
+
+In this paragraph an useful example is explained to show the use
+of the various functions of a Scheduling Module Interface. The
+interface will be described in detail in Chapter
+\ref{CapSchedulingModules}.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=8cm]{images/oview_LevelExample.eps}
+\end{center}
+\label{oview_Fig_Example}
+\caption{Configuration of the example in Section \ref{oview_Example}.}
+\end{figure}
+
+The example (see Figure \ref{oview_Fig_Example}) considers a
+configuration made using two scheduling modules, registered in the
+first two levels:
+
+\begin{itemize}
+\item at Level 0 there is a Module that implements a generic
+Scheduling Algorithm; \item at Level 1 there is a Module that
+implements a generic Aperiodic Server (that inserts his tasks into
+the first Module).
+\end{itemize}
+Then, we consider two tasks in the system:
+
+\begin{itemize}
+\item Task A is a task created into the Module that implements the
+scheduling algorithm (registered at level 0); therefore its
+\texttt{task\_level} = 0. \item Task B is a task created into the
+Module that implements the aperiodic server (registered at level
+1); therefore its \texttt{task\_level} = 1. Moreover, the task B
+is inserted into the level 0 using level-0's private functions.
+\end{itemize}
+Both the tasks are scheduled by the level 0 public\_scheduler:
+task A because it was created in that level; task B because it was
+inserted into the level 0 through the level-0's private functions.
+
+When the scheduling procedure is called, the Generic Kernel
+scheduler will call the public\_scheduler, stating from that of
+the Module Registered at level 0. In this case, the level 0
+public\_scheduler will choose which task really schedule between A
+and B. If task A is selected, the Generic Kernel will call the
+public\_dispatch of the level 0 (because Task A's
+\texttt{task\_level} is 0). If task B is selected, the Generic
+Kernel will call the public\_dispatch of the level 1 (because Task
+A's \texttt{task\_level} is 1). To handle the public\_dispatch
+event that function will call the level-0 private\_dispatch of
+Level 0.
+
+
+%----------------------------------------------------------------------------
+\section{Resource Modules}
+\label{oview_Moduli_GestioneRisorse}
+%----------------------------------------------------------------------------
+
+Resource Modules are normally used to implement some parts that do
+not directly interact with task scheduling, but need some
+information that has to be provided at task creation and
+termination time.
+
+Such Modules are, for example, those that implement shared
+resource access protocols (they require some parameters like
+system ceiling, the set of mutexes used by a task, etc.), or the
+Modules that implements a file system that supports the
+specification of a disk bandwidth to be guaranteed to each task.
+
+Like Scheduling Modules, also Resource Modules are organized into
+levels, one module for each level. The level number influences
+only the order in which events are notified to modules.
+
+The only events that can be notified to a Resource Module are the
+creation and the termination of a task. At creation time an
+application can specify one or more Resource Models, which will be
+handled by the modules registered in the Kernel.
+
+Note that the Resource Module interface is not complete, because
+in general a Module will need a larger interface which depends on
+the resource that the module itself handles. Usually, the Modules
+extends the interface used by the Generic Kernel, by adding a set
+of new functions, in a way similar to that used in an Object
+Oriented Language when a class is inherited from another base
+class.
+
+%----------------------------------------------------------------------------
+\section{Shared Resource Access Protocols}
+\label{oview_Shadows}
+%----------------------------------------------------------------------------
+
+S.Ha.R.K. is based on a shared memory programming paradigm, so
+communication among tasks is performed by accessing shared
+buffers. In this case, tasks that concurrently access the same
+shared resource must be synchronized through \emph{mutual
+exclusion}: real-time theory \cite{Sha90} teaches that mutual
+exclusion through classical semaphores is prone to \emph{priority
+inversion}. In order to avoid or limit priority inversion,
+suitable shared resource access protocols must be used.
+
+As for scheduling, S.Ha.R.K. achieves modularity also in the
+implementation of shared resource access protocols. Resource
+modules are used to make resource protocols modular and almost
+independent from the scheduling policy and from the others
+resource protocols. Each resource module exports a common
+interface, similar to the one provided by POSIX for mutexes, and
+implements a specific resource access protocol. A task may also
+require to use a specified protocol through a resource model.
+
+Some protocols (like Priority Inheritance or Priority Ceiling)
+directly interact with the scheduler (since a low-priority task
+can inherit the priority from a high-priority task), making the
+protocol dependent on the particular scheduling algorithm (see
+Figure \ref{oview_Fig_Idea1}).
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=5cm]{images/oview_Fig_Idea1.eps}
+\end{center}
+\label{oview_Fig_Idea1}
+\caption{Priority inheritance implemented with an out of order queue insertion:
+(1) Ta blocks when it tries to access a resource; (2) Ta goes in the blocked
+queue; (3) Tb replaces the position of the high priority task.}
+\end{figure}
+
+Although a solution based on a direct interaction between the
+scheduler and the resource protocol is efficient in terms of
+runtime overhead, it limits the full modularity of the kernel,
+preventing the substitution of a scheduling algorithm with another
+one handling the same task models (for example, Rate Monotonic
+could be replaced by the more general Deadline Monotonic
+algorithm).
+
+To achieve full modularity, the S.Ha.R.K. Generic Kernel supports
+a generic priority inheritance mechanism independent from the
+scheduling modules. Such a mechanism is based on the concept of
+\emph{shadow tasks}. A shadow task is a task that is scheduled in
+place of the task selected by the scheduler. When a task is
+blocked by the protocol, it is kept in the ready queue, and a
+shadow task is binded to it; when the blocked task becomes the
+first task in the ready queue, its binded shadow task is scheduled
+instead. In this way, the shadow task executes as if it
+{}``inherited'' the priority of the blocked tasks, but no
+inheritance takes place, thus decoupling the implementation of the
+scheduling algorithm from that of the shared resource access
+protocol (see Figure \ref{oview_Fig_Idea2}).
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=5cm]{images/oview_Fig_Idea2.eps}
+\end{center}
+\label{oview_Fig_Idea2}
+\caption{Priority Inheritance implemented through shadows: (1) Ta blocks when it
+tries to access a resource; (2) Ta indicates a shadow task and remains into the
+ready queue; (3) Tb is scheduled in place of Ta.}
+\end{figure}
+
+To implement this solution, a new field \texttt{shadow} is added
+to the generic part of the task descriptor. This field points to
+the shadow task (see Figure \ref{oview_Fig_Shadow_Significato}).
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=5cm]{images/oview_Fig_Shadow1.eps}
+\end{center}
+\label{oview_Fig_Shadow_Significato}
+\caption{Meaning of the Task Descriptor's \texttt{shadow} field.}
+\end{figure}
+
+Initially, the shadow field is equal to the task ID (no
+substitution; see Figure \ref{oview_Fig_Shadow_Typical}).
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=2cm]{images/oview_Fig_Shadow2.eps}
+\end{center}
+\label{oview_Fig_Shadow_Typical}
+\caption{Typical scenario with no substitution.}
+\end{figure}
+
+When a task blocks on a shared resource, its shadow field is set
+to the task ID of the task holding that resource (see Figure
+\ref{oview_Fig Shadow_Blocking}).
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=5cm]{images/oview_Fig_Shadow3.eps}
+\end{center}
+\label{oview_Fig Shadow_Blocking}
+\caption{In this scenario a blocked task waits for a resource; the blocking task
+inherits its priority.}
+\end{figure}
+
+In general, a graph can grow from a blocking task (see Figure
+\ref{oview_Fig_Shadow_DAG}).
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=5cm]{images/oview_Fig_Shadow4.eps}
+\end{center}
+\label{oview_Fig_Shadow_DAG}
+\caption{Using the shadow mechanism a graph can grow...}
+\end{figure}
+
+In this way, when the blocked task is scheduled, the blocking
+(shadow) task is scheduled, thus allowing the scheduler to
+abstract from the resource protocol. This approach has also the
+benefit of allowing a classical deadlock detection strategy:
+cycles have to be searched in the shadow graph when a
+\texttt{shadow} field is set.
+
+Using this approach, a large number of shared resources protocols
+can be implemented in a way independent from the scheduling
+implementation. The classical approach, however, can also be
+pursued. In addition to this method, a classical synchronization
+mechanism is available (see the User Manual for informations about
+semaphores interfaces).
+
+%----------------------------------------------------------------------------
+\section{The Generic Kernel}
+%----------------------------------------------------------------------------
+
+The \textit{Generic Kernel} implements the primitives which form
+the interface if with the Libraries and the User Applications.
+
+The term Generic is used because the kernel is developed
+abstracting from the implementation of a particular scheduling
+algorithm. This means that it does not provide the concept of
+priority, deadline, task queues, and so on. All the peculiarities
+of an algorithm are encapsulated in the Modules, interacting with
+the Kernel.
+
+In general Applications use the Kernel through the generic
+primitives, asking the Kernel to handle a task set. The Kernel
+tries to handle the tasks passing them to the modules according to
+the Task Models specified for the tasks. Any module modification
+that does not affect the Model interface, does not require any
+modification to the Kernel and the Applications.
+
+The generic kernel divides the task set in two parts: the system
+tasks and the user tasks. System tasks are used to manage external
+devices (like keyboard, mouse, file system, etc.). User tasks are
+tasks that belong to the Application.
+
+Moreover, it distinguishes between scheduling and dispatching:
+
+\begin{description}
+\item [scheduling]is the activity by which the Generic Kernel asks
+a module the indication of the task to be executed; \item
+[dispatching]is the activity by which the Generic Kernel orders a
+module the execution of a task.
+\end{description}
+The following section describes some new additions implemented in
+the kernel to achieve modularity. They mainly concern the task
+descriptor and the task states.
+
+%----------------------------------------------------------------------------
+\subsection{Task descriptor}
+\label{oview_task_descriptor}
+%----------------------------------------------------------------------------
+
+To have full modularity, the Generic Kernel should not be modified
+when implementing a new algorithm.
+
+For this reason the task descriptor is split in several parts: one
+generic part, common to all the modules, and a set of parts that
+are dependent from the used Modules and are local to the modules.
+
+The generic descriptor part contains all the data used by the
+Generic Kernel to implement the generic primitives, like context,
+stack address and size, error codes, statistical information, etc.
+
+The generic part does not contain any information like deadlines,
+priorities, time slices, reactivation times, etc. These data are
+used by specific scheduling algorithms and must be contained in
+the corresponding scheduling modules. In particular:
+
+\begin{itemize}
+\item The Generic Kernel does not implement a specific scheduling
+policy. \item Each instance of a module has a private memory where
+it can store information about the owned tasks. \item Each Module
+uses the information stored in the generic task descriptor plus
+his private information, but not the information of other modules.
+\item Typically, an Aperiodic Server does not use the internal
+structures of the Master Module, but interacts with it using the
+available interface functions.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsection{Task States}
+\label{oview_Status}
+%----------------------------------------------------------------------------
+
+One of the consequences of the modular approach is that many task
+states are local to the modules. The Generic Kernel defines only a
+subset of the states in which a task can be, giving freedom to the
+Modules to create their private subsystem.
+
+In particular, the Generic Kernel defines only the states
+described in Table \ref{oview_Table_Kernel_States}.
+
+\begin{table}
+\begin{center}\begin{tabular}{|p{2cm}|p{10cm}|}
+\hline
+\multicolumn{1}{|c|}{State} & Description\\ \hline \hline
+
+\multicolumn{1}{|c|}{FREE} & Descriptor not used\\ \hline
+
+\multicolumn{1}{|c|}{SLEEP \foreignlanguage{english}{ }} & Default state in
+which a task go after creation; this is the state in whichthe task returns after
+a call to thetask\_sleep primitive\\ \hline
+
+\multicolumn{1}{|c|}{EXE} & State of the task currently being
+executed\\ \hline
+
+\multicolumn{1}{|c|}{WAIT\_* \foreignlanguage{english}{ }} & State in which a
+task is put after blocking on a synchronizationprimitive\\ \hline
+\end{tabular}\end{center}
+
+\label{oview_Table_Kernel_States}
+\caption{Task states defined by the Generic Kernel.}
+\end{table}
+
+These states must be integrated with other internal states defined
+into the Modules. Some typical states implemented in modules are
+reported in Table \ref{oview_Table_Modules_States}.
+
+\begin{table}
+\begin{center}\begin{tabular}{|p{3cm}|p{10cm}|}
+\hline \multicolumn{1}{|c|}{State name}&
+Description\\ \hline \hline
+\multicolumn{1}{|c|}{READY \foreignlanguage{english}{}}& This is
+the classical ready state in which a task waits to be
+executed.\\ \hline \multicolumn{1}{|c|}{BLOCKED}&
+This is the state of a task blocked on a semaphore.\\
+\hline \multicolumn{1}{|c|}{ZOMBIE \foreignlanguage{english}{ }}&
+This is the state of a Hard Periodic Task afterhis termination,
+when it waits the end of the period tofree his used
+bandwidth.\\ \hline \multicolumn{1}{|c|}{LOBBY
+\foreignlanguage{english}{ }}& In some implementation of the SRP
+protocolthis state is used to postpone the activation of atask
+while the system waits that for system ceiling to become
+zero.\\ \hline \multicolumn{1}{|c|}{IDLE
+\foreignlanguage{english}{}}& This is the typical state in which a
+periodic task is putat the end of an instance, to wait for
+reactivation at the beginning of the next period.\\
+\cline{2-2}
+\end{tabular}\end{center}
+
+
+\caption{\label{oview_Table_Modules_States}Examples of states
+defined in the Modules.}
+\end{table}
+
+%----------------------------------------------------------------------------
+\section{Initialization and termination of the system}
+\label{oview_Initialization}
+%----------------------------------------------------------------------------
+
+Before an Application can be executed, the user has to tell the
+Generic Kernel the modules used by the system. This is done
+through an initialization function in which the specified modules
+are registered and initialized.
+
+Normally, the registration creates a non-realtime task, that
+initializes some devices and calls the standard C startup function
+\texttt{main()}.
+
+When the system ends (because a function like \texttt{sys\_end()}
+or \texttt{sys\_abort()} is called) or when the last user task
+terminates, all the devices are closed and all the system tasks
+are terminated in a clean way.
/branches/new_sharkdoc/vol4/kernel_overview.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_Power_FixedPriority.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_Power_FixedPriority.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_Power_FixedPriority.dia (revision 1676)
@@ -0,0 +1,6 @@
+‹íZ]oÚ0}﯈ÒWê|:¥P­{í6©í;rˆ Þ9¦´{ØoŸIB!!¡%Á՘‚RÌÍ=¶sΑoì뛗˜ÏX$„³éÛ¼ž\G]ªïD ØP,Y^ +Ì©”³KËZ,€¾&Hr(™ƒ[¥ÈRA–9<1ŒÍ’hٖ·") ç Åx`†hük"øœEf•Ç9åÂxFt`ž>¥ÓÊÓX…<;rÏÐ ‹rÚxÆ¢Bäël+¤&Ïòw#&JT› O¿ø§Y—ò†u®ªŽÖ‚ȉ aÛ8#šM„ úîjöuPÝB7IF3.¤@Dnƒ„œSŒX†#Å7ÇIƈ*ªìˆóìYó¥kå‘5•ô˜âQôŠEÞ©Ûµg’â|œãáO<–¹x$b‘qfÜòsí#¶ih`þ°‹â+OƒJ¦æ;)ËoÆ “Ù,ÀÞÆÓ¬›…ºÔaXÎ,Tß›Pœe÷Áì9êçʁÀ†=@Ø SÆ\°m39ÄhÒô ÉéöˆÞc·È=Åd2•;’ƒ†“LùbTáñïkªÚæ­5 ³ÒiÏJ¯é||œ—ðW¼\þèåeãñtÌ<$3ÝöÌÔÎK헁v¿ìXù©¬|Ä/²‚–^[Zº=O#-ÏlàºNÏ. ÿÊO¯¼ìª¬\ÎC ´\9”bêžgZâJåÃ~ÆÔ°kjˆ+ËÄ'ÎdÞ²=ùÊç‚(åYmp¶$ðÞ"vˆ"©Þ%Vˆ´Ì¬Ù¬?íôÓH-ø',ÆÕϳy¼ßŒU.ýµš€ßÞ|­«¦Ü<p¾a~vu,6àt6ÐÌ
+ÔêŒ@§ÀöFè·XX +ǵp;hfAgŸcA[pl­5쿕Ž<ß=žšà©àoœqÉwfÐÄ ŠëÜ@§œ·vƒ¾ÖW*½¿²‚þjiðïÛ@'üFÂ/p©¾Ná÷Û
+_Õmš·ø–;|«R®VöÿOí—èԉ_§ø/PZk€‹`ý"@Õ¶wq<o¾sfÜ+åœ=’wnаè^|’8öÜ@ï„oûÊÏÁÌ ‘±ñ€…šýÎ:B·SpxO¸Å¿?îÃUÎÐú¼•Óò]ç 8éQÀ+§¯\B-œfh!þ=J{¾×x*BÎÁƒ\e`;ƒÊ!{vaÑ ÁåѬéçµÌ<¢˜MvÔ±A¿-Ä;G>Œ0æŒ)â(z'[®¿úǘ*Y,Î*þKž74ÖÿªeëaUÜëå÷Úµ÷®Ô\êPY¸ÙuzÌwxR8<<ù œÂ
+ý/
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_Power_FixedPriority.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/OSLib_event_periodic.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/OSLib_event_periodic.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/OSLib_event_periodic.dia (revision 1676)
@@ -0,0 +1,8 @@
+‹í\Ïs£6¾ç¯`ȥ퀌Äïõ&;Ûz餇îÝ#ÛZ‡.MýÛWb qˆ†Ž2OÀŠ’¾ïÓ{ÒC?}ßÆځÐ,J“Kÿt{õqáüwCñVã’L\Ýè÷Œí>Ìf ~Ì0K)ˆ£=ÈÈì_ÇxÆ ÍôÛ+M{^Á3,î•w1c4ZîѼ%7ú¯¾mhºOÖzQª,·Jã”jßè×_ó}VV3«ÔóBÝ;¼#´^ív—f/ÂwgEZêŸÏʔ¥2^(ÙÜ^v®‹G*oœêjzÐV#l‹é&JÎíP‚ã¢#ÐS/¼ÝÀR¶X¶*Û@”-v)eGìÜÈ2Mc‚“£{ÒÝN¶Â1‡ÊK +¯¨½¸}„t+=Š[5>æöbüHhùP¿ž˜¨¢,ZƤlç3Š¥Ë¿ÉŠ•äù‹ádéZ3µ?¢„è'!±t-ZßèZUöÕû×Æ;<«óo—F +ºÁ„–᝺¢­#Ú*_.ëuSþø8ÙÄäX?°\á;GŽøÓãÝ ®Ò$Yd?þu^9]Ü,†£ûøÀ¾ããJ‡‹a‰ÁqÅØ@(pª-jü¾ÛpƓÅC´f÷ç~b½úTž±Ç˜Ô+'É~[v氐úB¾³H¡þò%"
+‚ÀçG®ç9ó@Ûð‹‹n6™è„šÅºQ+Ó6'äÞC¥\ÍÑøé΄?ÿ¢շ‡ã…i¨Åè×4aM&Åý²ÈoéžFÜGšõ±sO¢Í}£¥–ïí&ª º¬.&rŸ´ÉÈsgÕÊúâÞÁ&ْæ±9úµ=Öè'H»¯@_®
+ðé$@G€a0%¸S*ÐYªÈR2 SœÞ2`ɕë$Öt诈߉ø–"þàÄo‰+ݾčP"ï¹ß/b~èÎC¸†øUVÚÓôµ÷ƒJÞ°¦4}h)ݞ5/b’l^~ø ¯‰‹ÝŒ²Öâõå²¥’¡#+=-ªMjüޓ†]Ga÷ »Ÿéªºþä\|Ì¡/€ !°ÿcAçQFǯöô@ë(ã-\‘ö¡‡À•·ThK#T¤{môôg+•unèN?…À±l>{L$„Â*†êCU¥B(™ìp]àÊu ðsàNc!þ4$€( è"uX)ºAß?ƒ"4 #3ƒ"Ìwæpܹˆýz茐BQmUsÔËEþÿoÕÃÞé&’ .Ïù´s¿rnW…Ïùþg˜Ï”F‡Tã½E(ÝÿÃû^Í9æœÌԔ#Uzgð@G®*p†GQàn(
+àtTá áõjëHãÿp. 9pĤJ:mì9JÆS{u™Òë ñùÂ-Ղиũ©ÉÈj¯Äaqð”8Œ­:ä“;RóÉa¾=䉄ò Uƒʝ åï3PUÛÿƒrÀžtnØ'nx£pûÀ +¸*àÀ·úŠÜ7¹`(ð‹òôKàwø¢KïqY†=MaGŠ¯f†?Ľ'w‰>x’v3O–CÛk­jYרî
+ïêƒÔݗ«îb¯ù)[Ÿ+¼ØkžLÆþFïöšUÊþx {á 5áD¼¦B.e –r›I8Ñ´;%]e@¥œŒµˆ‡¬^ޕz*÷^ŸŽ…€þXçBÔÕ\@¥›¼¬þé&’eæhʁeæXæ%`™
+XŽA˗|Ê´Ñ‹i‹CH¦tîRçŽôÈ^R'ŒÅ {ˆ”F©‹qp<û˜ŸàWSIOød,ÏIPIC$5ªÌ„7ëBq\x{U9ÙðöêVÏT
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/OSLib_event_periodic.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/LegoArchitecture.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/LegoArchitecture.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/LegoArchitecture.dia (revision 1676)
@@ -0,0 +1,12 @@
+‹íšÏo›0Çïù+½f~®K¦m‡MÚ¦¶ÃvŠLðoŽŒÓ´—ýí3?:¶\µ‘J
+zzÏ6Ÿ÷5ï‘W¯¯wD»B<ÁŒ.t`˜úëåäU„áKù·áp§Iš¤g }+Dür6;¹I `Ü xo$högÒh¦/'švì ‚¦×Š«PŽÃ½@…;´ÐC¸þ½álO#=·*ì֌0®]A²Ð/~f}V¸™UüÜá;†1âu·»˜%Xšˆ›øĤÅOz<²)¬iD7ˋ7öE>¤âBé«i ­AÄò +¦§q8‚$_Ëð­ÛU8?@¨:Q€«€“U̸à‹Ó !cAšÇ|ºÇI֐HTîšx€÷üò?¤[Ó#¿TËÇ,7ˆƒz[f¢v…TÌó(ÅXø ­E‘<_¤ä‘öB{Ë®õRGL]ÃÑBÿbV“¯¾ ҙ\爛~1ÃT·s
+€á”KѶmÞðîœËáCº!¨Xf#pÒ¶s ,ÔÿÛòØ- "h·Z3NOe )e8ÛÓiýÇìá{‹ðf+ڝ[]GžlÙaÕ õ÷çV³ÜÏJ;Ó úÓ©M[nɔØ(&ó¹béþOXZý±´Ôk¦UJ¦£\1­Q0Ÿ™ó¾dS¢Í EÓIÑ´ÌM_1š}&4²9$›ölúêÙôK6å~®N„óqáü†®EN_:½é\)œ–1wÒMÝs\×¾”hºvúð™v +ҕ¨­w_j6mw4ë«Tìê-˜8&x +…\sMފÉ'rÈ1JZ:3wÔë-cøɨhAz½0yÇö2$?®ÛϏs’÷µÎQí°u ’µïšÂ÷õÌìÓ/$xCw¨ùî ºß·f-¥Òàö•¹©(Ï ¦žae ¿-0 +ò³§¯ ï‘Ü!ñzòÉ­’ŒbÐE *xR R
+¼ÞÏ°ÎÔSYøË¢ßs§n!À3˾Ն§¯ŸY´—Sù>ê@¨²5
+J!ð‚®ÕÙ9JT•˜Ùù³Q‚£tT`ŽR0°|Â5HAÐW
+|ÙºJ{žá¦MW7{0—Û„<t ·f”®²áŸ5©JAŸ‰y7îë™èØ£Ñ
+rÎuߍ@vò¼"ˆnî¼ß7ĽËãÛ[kÉÐûW*žê q +Pfˆ¯:CêsjÎ!o̎ÿ=;ÀH ~ñË +D>G>Ê<`é<óãA1¶y¥EQ†qPª¼Äøqd¾ú4ÞDzçWu#Ä–õ`Þÿ5 ô¡Ž`;«ê%½iäEýü™õäÚ GcQßíß1YcMÿ0Èϳ_Q/'•ŸY/'É\uD\1
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/LegoArchitecture.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_Architecture.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_Architecture.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_Architecture.dia (revision 1676)
@@ -0,0 +1,12 @@
+‹í][s›F~÷¯ÐȯØ]nÉÎ$N;Óx2Óä݃$"Ó"Ўí—þö.]ÖÞR49~P"‡…ó}ßÙ=gY¦ïŸWÉè{”q–ÞŒ‘ißß^Mq¸ÌÃՈmL‹wìÛÍø¡,×ï,ëééÉL^Š°Ìr3‰Í"²þ +“$´ØNÖøöj4ڼ˰úÎ~ Ë2ge4JÃUt3ž…ó–yö˜.ƛ=Ø>ó,ÉòÑ÷0¹_«ÿÆVs¸µ;þ„½u¸ŽòCS«uVÄlsù²~µ¹ãøêó`;Û£`;¤ËÛëÎõÔj¾ì?nP§ÑræË8mÛÍ£0Ù\$6¼½ÂóÎtMtÍu‹ûu–—y—mó,K¢0ÝØ.óLjßv1ææS +Fü¿Åe™õ´ó[˜o5tjíÐ|.–y¼8M†Ö֎£ŸâEùpÿ¬ð6l,¾(´ø=.âY·2NKi“/‚&Eüô/¢¢ÇSííš]¬¾ ;Þ策N­#Ÿ&áK”7æ>î¥{Ôܳ†p±löw4/›KøR†é"Ì£_F³çñ>ÐØãQ¼¸¶÷—Üpfˆ‘½uýëlçÇ ‡—ôÚ]æf³Ck9kg˜.“hc‘˜Ô50û˜x¦íŽéº|gˆ’hu?Ïò´ld]›¬ùÓnøNEÌ=Dñò¡ì¶‡LÎk.²§ûŽpÞ/ɯ¹am`#„!$Š!O9†Ü†]òC0„E1(ǐ¿Ã²u(ifïõžÎÓa0ªã™Ï>ÔÇ3îv¿$¤Iø‘äˆ#Éׁ#¯–£GÈÕÒ1ò£àaäŠÃ¨r³$1»;IB(ñ7ý‡£‰\–< ,ZäïE Ûz@p“AÒ×è¹ì€’/
+%d3¯+ƨØ`0®çM2)
+*lU_ùNUVW{p¢ã|ÎÑö.ïԉæÖ>¹èÏ_FŸâYG>úDŽ«+#™¥å±ùê·fó¯Ùc3>X"¶_á´/Ïw¾Ù6Þ@áºàplú°
+a×bÆÃ$^¦«èõݎÒÇÕù÷ãU®N9Q.ú†êþÏFëœ ³½ùß°Ô; /ñ¨LDÊsN¾O +d7A›#£úgpAð÷ˆuØâù՟ë¹%ÀÈd'y9‰„ËQŒ+®¡z˜CMÏ'†ßE6¬%Ø7‚!FFÖ/ÍCƖه
+`$7#‘D˜ôóÑ3]o×5 b:„Þùøa½NâyX²{ Œ<
+à#7… ¥®á(¦#-RÇ +]Ó·½írXlüŠ€„'¡äæ ÏÙ8ê'¼P´ã``Ú6&MӞА›„Â%zªœ„A+ÒB荞†p›ƒÂóúi{Ì$ގ ƒ-¡~1à¡` À>nöyìÃêهöìÃÀ¾ `öI°Ï‡ØìƒØ÷?±OxÚ ¢êÙG÷ì£À¾ `öI±Ojî U>±Ý7ß«f³ûÍì;ÕyüÁ͞ùƒÝק0€½¨JòRÛ‘ñYyDDA3—­2?ÀylÀÀÿ¸ù'>OÆ3°­šޖt“Ú<ðoèükƒøÇÍ?,^TN¿]țP ß%T{RÜ#©Põ}Ï`ß÷  ïy¹Pè{žÅ¿OquñÏ_<Ç×±xŽ·[€‰ѓy–¦÷Qº¨[yV»%/‰9s¾><Oגs]†ª–²‹g®(ZZ±ýuôÀW­Î†Æ£2Ûøi´ß\ù¯µ&ܑ5IL¸âý!õOxo1A+Lz0AOc‚ò>$† Iyâ txÌß/Eu¹,8å2dô|&³’Uþ´­Èµ[“C“ÓÚ-5Œ’×~K’x]t:N¼~è˜Õ­U]Â@ÕJaÌnµ6oº®†õÂÄÿÖª*䇮='9V.]a¤\f™ÉíÃ¥•u(}¨ÒƌTxÙGl‰,9ëŠ(W]·ž¹¿©;Uܬ¦î³ +¯rü<ÃÖ`#7…kV³›¯:bƒnƒ!Þ.…ÁpÀÁ° +à7ÿ°D_T=ÿОøwQàŸd€©<BšÌp“ 0ѕàoý›«Ð›Ô½ dqd†#X×p„ùe3‘µŽà!G0ˆq/ @ŽEäؕ“c¢KŽÉAbÖÕ¦ÇägÎÌOFŒmbLÚbì€_„; Æ2oÒ.lbÃWOÅM9ÚiÞ G5°@³ß_ççz%Ó)YÄß[hxJ¥é~“ïwjIß<66°ºÛ¤ûûÀ‚ÎÍCñ·­£c]YÝ l'›ønvºñÀAޗÊÙâ*ª§SEw*-ó°úÉFЫª¡„$ÞfkêVÑV·j³(î`¤Ü‹Ðt^M¯áj©Õ/æC{U'ZT]}åd½F“ÄŒ5Ô£H«å ·uG@ÖûвÎ+뎄¬M²Nö²îê‘u²®EÖeÞíè’uҒõ!Öµîõ>4üì²>µ’ð%Êo¯¦Ö"—y¸º½úeb…Q
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_Architecture.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_Power_Timeline.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_Power_Timeline.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_Power_Timeline.dia (revision 1676)
@@ -0,0 +1,12 @@
+‹í›]s£6†ïó+rëâÓÞ¬½Ó´—Ûvfwï=Â(¶Z<BŽ“½èo¯ø°1œ,OݑgÂ|8‰÷<–tàó—×$Ö^K1%S–þev÷9Âð“ø[2˜h€¤ÙÞT_q¾þdšÛíֈßRÈ)3b¼1RdþãšÂÈÔgwšvè ‚fÇÊ£s†Ã +G šê!\ü½dtC"½°*í4¦L{ñT¿Î?ºYº1k~Nø^Ã5bM·Éš¦X˜ð·õ‘I‡Ÿl{`SZ¥Âˆ,g÷¿¸÷Å%•*_mÚ„'-19ŽÃŒ‹Ž°±½ë…ó„²IJ0Ùp:_SÆÄü8HHiŒ )âp¶Aý㤠 ©œjø€÷âð^ҝéQjäc/†oˆ•õTe¢ö‚SƨlçAŠÑð/´àeò|çDEڃöD_õŠ#–®áhªÿiՓ¯Ù +™èﴙ~kŠ /zÁÜÍ®^èr†MÏL\;$ËÞ]c⍀Ø<‚‰ay#Çð¼~áPŒ’ù‚2r “K´&w¿Å_·h/w€ïÂË?áÜèÙ1éŠnç-Œ?§Ú1oV"ì­J0\•Nßþø¸.ÃÝéÒ¹ºìÝ¥ÌK*Ó®Léºt+^úÒy©TùP¥3\•¾|^ú/ÇÒyé+^^W™?Ð+o‘¦;Tšöȑ(ÌË°m0² +Ûó}÷ÑÍ÷œb¯_XžõC#hsN۰麟ùlµfטØ~E/(Ö¬ŽÙí‰9OGÄgJx[¼ìxiò+Ý0,rÏç(ޛ^¢.ªw…Õ'D¾ÒäpeÄÊ?É©è’$¨ýÞ ²IÎë±ÖI©TxÃ!àJý}*1àÁÜbïV0úa &-™ ð‡ƒÀ—¯6ðok4`+ ôÀ¯ pÃ!\c4à×FÁm…~ÔhàZ K]MîÝr(Eº•q€Êü>™_גJ|™‰?šøbÊ&¹îœ•w³o·>¨rÿÿ™û +9©ä—™ü`ð3'@î*€÷»“ý"Ä?7´
+ðzFŒÁP´æ;b¢÷z +ԂÀõˆ.@G*€ë싄‚c/¸*ᜠÁƒÅ
+E›ì¹FńžLP%Ãk1Á¾ä +Ã÷Æûš!ð +ǵo§hø
+ãß)¡œ¼P@è U<¼œ !Œ„‰_,gr;•ƒ?(Ѿ‰ìyÈF Š=‰ 
+—'Âú)ôñU bÛ¸0øCM÷¹¥äo <Ú@Ì"z®`„èç<¿ò³ÚÓRè1ÉʧLD ºÉYOÒh£ÛfK*é9=ÏcD–§žäµŒñÐï<+üá JˆvzÄûÝ7ÚJ¤Dö֗Ð>§ùûZõíTwnV˹Ny.è<w—ɍ j&m±Ÿ¿¡6»«½Â6»û4SfÚ¸:
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_Power_Timeline.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_LevelExample.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_LevelExample.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_LevelExample.dia (revision 1676)
@@ -0,0 +1,10 @@
+‹íZËn£0Ýç+ݦæ&m“ªíH³èì#.ñŒ±‘q’¶‹ùö1< ”‘2"R"á\î±Í9‡‹ÍãÓ{H”â1ftª@WŸfƒGÃ{ù +8 @ãähª.„ˆî5m½^òCÁ8 x b¤ý„@Miêl (û |(`Җ·B!8v—)†hªºÐûp¶¤¾šEåq#Œ++H¦êÍ[úQµ<VÈs$w#ÄËiÈÅX†ˆè ¤&Oò»“GÅ2ˆ³›gû&ëRÞ°ËUÕÑZB`zˆÃ$ÙD˜`lnfár·kÒ5ïÇóˆqÁ!‡ .cAšá¾DÍqbI•c1ÎȞ5o)]+¬©¤ÇÀÄóN½ì”¨¬pŒ]‚òqîIŒ¹¿'rñ¼
+H}È}åVyaïêÎGtUÁþTý¡ÅWž™LÎw\–_Ä0Ù,8ý«Y7 u©]·œ™Ë¾C”e·ÁÄòçÁ˜ÝZÀqšÁ!‚¹Ç8=4“¯Mš~}±8і0v‹Ü „ƒ…8’4œ˜xÁÖó
+?­©j›×v$lÌJ£=+­¦óq>/-`oxéȟnyÙx<=3›1ó'zÔ4ÛRÓZóV¦i M`:£‘ý`§GVvÔ V$óP-×h¥˜ºë™V_…¸R¡ö­QôšjíÈ=¼ñQQ…—´ç!ßؒc©=­ +΁N• —CIu’XM ҂¾
+d¿Ò×ÓO; YZ4DÕ×ÑexٌUYš€ÕÞìNïO¹ +XànÏììèZlÀèm ™ +¨ÕA—F`·5£ÛrÀc{[ c`Œ®§xõÈ_&OáÊ3 Çbö–ÐÄŒ¾4øgŽà´v„ñ°ËÊ@¦··~ Ÿ[¯Ä zá7~K½ð»þ¨­ðeÙÖñZj²”ºYp6eA¯ýÿSû%:õâïRüw_ðÐíŠÀÐs» `ŒÀÄ_ϊÀs„8f>ö”WÄåì÷–Ðð9 _øzOxAŸ’ß1EÎ0ní “´`ïô‘é.ëƒi+ÙÌ2š¡¹èsžöü¢ñT,aòÞuV) +ìX+†\´»Eý9䜭ˣٱÏj™yN +ŽíÌé`ÜâÄÞßÙ£TG²;>pýÍ?ÊBª"y+AÒ_°t'WÙý+‹’ƒ‹Uq®•Ÿ«×ž»s©CeÝfÇé³Aá‹Ùà//B0ÄX%
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_LevelExample.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/cvs/Repository
===================================================================
--- branches/new_sharkdoc/vol4/images/cvs/Repository (nonexistent)
+++ branches/new_sharkdoc/vol4/images/cvs/Repository (revision 1676)
@@ -0,0 +1 @@
+sharkdoc/vol4/images
/branches/new_sharkdoc/vol4/images/cvs/Repository
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/cvs/Root
===================================================================
--- branches/new_sharkdoc/vol4/images/cvs/Root (nonexistent)
+++ branches/new_sharkdoc/vol4/images/cvs/Root (revision 1676)
@@ -0,0 +1 @@
+:ext:tullio@feanor.sssup.it:/home/cvs/cvsroot
/branches/new_sharkdoc/vol4/images/cvs/Root
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/cvs/Entries
===================================================================
--- branches/new_sharkdoc/vol4/images/cvs/Entries (nonexistent)
+++ branches/new_sharkdoc/vol4/images/cvs/Entries (revision 1676)
@@ -0,0 +1,36 @@
+/EDFstatus.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/LegoArchitecture.dia/1.1.1.1/Mon Apr 19 17:16:12 2004//
+/OSLib_event_oneshot.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/OSLib_event_periodic.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/archdetail_PI_schedule.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/archgen_oldHartikArch.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/example_EDF_status.dia/1.2/Tue Jun 8 08:21:22 2004//
+/example_PI_blocked.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/example_PS_status.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/kernel_quattro_insiemi.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_Architecture.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_Fig_Idea1.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_Fig_Idea2.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_Fig_Shadow1.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_Fig_Shadow2.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_Fig_Shadow3.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_Fig_Shadow4.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_GuestCalls.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_LevelCalls.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_LevelExample.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_Levels.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_Power_DualPriority.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_Power_Dynamic.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_Power_FixedPriority.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_Power_Timeline.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_QOSMapper.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_Server_e_Master.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/oview_TaskCalls.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/posix_filtro.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/resmodel_Gerarchia.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/schedmodules_eligible.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/schedmodules_lifecycle1.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/schedmodules_lifecycle2.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/schedmodules_lifecycle3.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+/schedmodules_lifecycle5.dia/1.1.1.1/Mon Apr 19 17:16:13 2004//
+D
/branches/new_sharkdoc/vol4/images/cvs/Entries
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/EDFstatus.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/EDFstatus.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/EDFstatus.dia (revision 1676)
@@ -0,0 +1,19 @@
+‹í]oÛ6†ïó+ ÷f†‡ŸbݤèÖ+ТC»ÛnÙVmŠdHrÒÜ췏’åÚ²¥Ô–L'F ¬ÐçèÐ|~œ£øÅ˯7aïÖOÒ ŽÎû€pÿåÅɋqà=×ÿ&‰wÓÓ +¢4u޿βéó³³»»;Þ§^'( f(õÏþóÂÐ;ӍÎú'½Þª±—yùµòª—eI0œe~/ònüóþÐý;IâY4îÏ[•íFq'½[/<ï?ûRüôÏJ3g;؞zS?Y7{3Ó@7Éî§Mìäÿ¯´)[¥ºQ4¹xöŠ=›ßRyai«îFd7^2 ¢M?‰ï…óŽ È%‹^ØÝÁдƒÐ´ƒÄ´ƒ ½šÆI–xA¶édÇ¡ïEs?Y2óÛûIG^¨‡ÊCÀÖ痿 +éFyÌ/­é±ðz÷~RÞÔ/K%önƒ4†~çŠÄâá?þ(+Åóùý»ÞiïsꏼÔï/1‚û½`|Þÿ€«Ú[ïmKwwº®¾iDYùi:lÙ +MÐdz8\·œè[÷¢Iè³>HA˜#ÚùñCÿæj'Ñ&DöFaþ.gכ¡,
+›GÐÁÁµL®³f¤íÌÿºat¿kmšäR€µÒnÁo>^^6Pøm6¸ûGY³üzÙä7?¼õ³`ä­ªtwO=_Óû¹ÝœT%V7>¢”q8ZGm|³v·Õé?Ýi~N¢¿þƒò£ÙM +E¢tIwîñlcÄWf/^˜úíÔ¤;0ô†qâe±Ì/ÎaޖîЕâ=7?Ž@(Ã|oÈ6€ŸGðƒþÓ»ËËß-áÛâ.“–ð–ð;žt%<å7HøÜü€ºˆ+%i’ðíنð4@¸?6á/ÿ´+øÖ|§I¥\GX¾[¾oÍwÚù|ÌÐhóâ"ª×C› ÁÁè9 +˜\ÇË"b’ò]ºè ¬ýæêãå«×Yâ·%>aHäÄçˆIJ¸…¾…þvÐg¡Sj’ú¹ý‘Ź¶sŠcL5
+þö!mG~
+£äçœSuäÿûÃû_ÞÚÅ~{ôSäR
+Î) æ
+–ý–ýÛ±Ÿwf¿t”IôkóJÃ\:h§õò÷¹ß:œm°/ò8Ìë=Dûo_¿³ÐoƒÁÄu#Š¥°Ì·ÌŸKô“èØKÆü¯’Q +ôEWè/jdLåsäBîƒ"ÁzŒ»\ïl]ÞöCˆ¢+?1ìYmv·í}̒[ÿj¤:ґߌq½Çi›]ˆÆW^’ÄwëƗڢ-_…~4yhš«À¯‹ïL¤[{È?x=®ôðO7&¶Åoz×Z/yi›ÖGUj½åoÏûlc,Ô¼Ê÷Bõ½}½qC{Q´ì\yQVE˜T40DAÍM…; ‹Z ìVŽ«Œèº&¾ÚÓ^Žm7Û«[`É]a%þX‡§"q·óN­L›tâ[nÚgÚE.“’ +(Ÿ ÝøìÝbmþ^W¹+•"ʪü±TN;¨œ<ŠÊUç›2ï/MVÙ‡ËR+ø€J$˜*¶¡Š€4¬ðšðj-΋0ÂBš—¹b’¹`eþX2_“ªØEæ¼&ex_:7:‹bîœj½KBá›Ö°¯‰¯î´¶L ’¤’÷0¡tíDoUì¢ý©èvÑ9{Ã>rëÄä\Ž˜›?ésJ–RŠ)ŽÚØëÕȚBbfeMq™¢Vև–5Ô·Á¤Iöúì´Âܲâ1ßˊ|KËyQ£Õ €0˜–gMt5­H~|'ò­æÔðJŒíBûÑ&`Þ¸'ÞùԌï[åä‰é™w.iVŽÉÚ6©õC=q!XžçRà:tþòégñGzäeþ!sø¿Æ³$ðó|0¿¯Œ+›³ßK¾» K\Aš}2™!&ÅB÷Pˆ¦áG‚Osûւ í£¸•±eI`” ©á'œÜ
+ (=.èUüÔËFז­JúÀ’à`$è\G•ÑÒg*
+¸% $PÇB½eݏB»&hG‚Êز$0J‚ÎÕs”9Øl¾])È|“ŒRA󂌕ƒ Py0°hŁÊȲ0ʁÎ%vÒ9£¹:W¹îœùY!Ð%ž>~ûÞ8 "ÿg˂6,¨Ž.Ë£,P{HܛÜ€Èa°Øš³àhö–Ÿ÷Ævw°wԗ ¼‡?y'Ìé1Á•Ã‹bÜ¢ÒÞE®4^Š[‰«¶8‚¾±•à–<•Ú¼.¥ò@¥ö ˆ›Ïp$W³bþò¶ýÓ Œ'3{Ø6P]vž79Ïw/,KᢈÉs€üaVîÂs2Ð~UY!­ýn_ØeM^[8Äì´¯§4¥„h¹¼Ò֓ÌÐÄ¿bÛÜÔ¿êä)=g‡SÁK:—öQaIŠçEq&ó$"„¢ÅLÁ€•Äkíwû…zS”5%÷Ü´dõJaö¯[<••:9Ôj»{ +žpÀl +^^Š»Hª +@µ¸p,‡jA”úIf—Ú­Jð*CË.´M­“Î%x Œ‚@ϗR.³ëFõÜ +Çm&ñF–í¾ù , v'Áüuñݑ'•/—¼8ùli’Rv
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/EDFstatus.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_Levels.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_Levels.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_Levels.dia (revision 1676)
@@ -0,0 +1,8 @@
+‹í›]oÚ0†ïùQzKï@? Zw»i›DۛÊ!.dsbähoöÛg’PHHÚÕÁh™ŒÔH¶ŽÎ‰÷<=ǁë›çk+Dӈ$#ݦ~3î]‡¼ä3
+c$éf4ÒçŒ-. +c½^ü’BF(ÀѤÈø +1†72ôqOÓö„ÁÍ\1 £Q°dHK`ŒFz§¿f”,“PÏ­
+»)Á„j+ˆGúÙSöэQòó†ï\ Zu/Hqö²80ið³¹îÙV)7Jfã³OîY~KÅÄÎWݍ6a1¤³(9ŒCÄùFØ`howáãÙ°ìTv€(}\Ê(ŒØa€Œ`’Çat‰Äã¤Sˆ¹TÞZˆõÞóéWI7¦G>UÉÇ,†/ˆ7u»ËDm¥Q€Q±Î½#ÁO4eEò|g0 ! +µsí–<ë;Ž˜º…#ý›YN¾ê6pg|¿Ójú-H”°|¼þÞÓlڅ&×APõLù½Ãd†QîÝ^ßâ—+ë˜^ßå±p£øqJhr“c¬&s¿ŽB6?\Ñ«`ܾç(šÍY³sÁûNçdýXCø÷3ªòÆN‚š´ÚkÒžlU:ÀݪÒždU
+¯Géòxº´ÛëRº*Ý+}éªìª&-ÑlúUé´W¥/Ÿ–þŽ–CéÿÃ} ”yReþ@ϬFšn[iÚ}G¢0ÏM`ÛV߶çûœ|$–mö¡´ÚÏVlšžgÖ©–ì*Mí´BX3:Û7ú†ˆO$auñ6ó…Ég²¤Ï=£Mœƒx¯µúxˆ²¨Þ–Hˆìð£.Èþ©ˆ™}Úâmè,‰Qý³AÉ2þ؎Õ6¤R!൅€%—C0¼2Àò€åt‡_I¸ä븻»SÁ€¥8p2ø­90”Ú>q÷î–<RW _(ñKZR‰/3ñmß²™7gÌÛ&ÀÛ*÷ÿÏܯÈI%¿Ìä¡úH=žÊê öêÿA>êLýÿðð P Xÿ—Ä¥X “G`/›^é$ÀïØIÀd2Q$$¯8pXæ@àÊ/
+œRQàv¬(¸¿¿W(D«Š‚“ÁÀjÿ’P. Š×„[ä¯ ;Cƒü5¡¥P öšP‘àt$°Û“À—ϯôu¿[_°Ä8 šƒSQÀiOÁ)ê¿T ºU8ŠbPDž$ÈÇÙ/YƽÒO]ƽ?Žþ&à6
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_Levels.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/example_PI_blocked.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/example_PI_blocked.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/example_PI_blocked.dia (revision 1676)
@@ -0,0 +1,15 @@
+‹íKoã6Çïù†÷ªÐâKµ“E·§Z ½…!ۊ£®,’²IöÐÏ^R¶cË9¤ÈB&‡]ȒG´õÿÑÙ!9ùò²Jßã¢Lòìnˆ‘;ür3Y$ѲˆVq2+?‹£»ácU­?FÏÏÏ(}-£*/Pš<¡2ý¥i4†÷7ƒÁî͋¨Šä±x%ªª"™=Uñ ‹VñÝpÍ¿-‹ü)[ 7WˆkæyšƒïQz7üôPÿ +GÛ·ÞÞÁÞ:ZÇÅ¡©Õ:/qºz]Ÿœ>ó~ùïÁyqE).Ȗ÷Ÿ~bŸ&£íÁþýÇ +:k´ZEÅ2ɚv‹8J7’ €ì>áûÎlMm-lMÊé:/ª"Jª¦áYž§q”mlWÅS¬n»œG©x̗ŒÕ->$U•·´ó!JËk +ŒÞÔ|–†Éè·I½ÆŶ_÷  +¾'e2Kãí׳5–Ïþ‰çՖ“?ª([DÅbp;øš¿ ÷݂;$‹»áoãÏ* ‰GSR¶Î“¬Ú>mêøˆï?ê¹zÎâlvh°M²eora—ñ1áÈåNˆ¸â=â4^Mçy‘5û‡Ž-¯­>'‹ê±Ùú7ík˜{Œ“åceÄ^ù˜?OÏtÁíö£x´”„µ•Äm(‰í•ä[S%YPÑV’oCIÞ^I¡5%ù $ J¢ÚJ
+m()xSÅ֔‚’,(‰é*‰b J¢î^IԖ’tZJºª$®­$7Ý{ÜԚÇMÁ㶡$O[I6<nº÷¸©5›‚ÇmCI¾¶’lxÜtïqSk7Û†’m%Ùð¸éÞãfÖ<n
+w7%ý¿Tg¤jÞ\'0.%ì#ߗOÚçžÇƄ B°¸O}¨v¯J~ރ;'7ŽÎŸ{>uú¢qÍA†c–æóoñâLšãB˜û\ ;ϪcûòµíéŸó§"DŒtlŸµ-.ÿ~³MA\…Šå:‘ulû0»åÖzÆ£4Yf«øô뎳§Õû¿“¬‚q±~®€9Ø5N¡ˆ‡¾èÒ·D2Ä\*o$ûE¤ ,¶ê`T†Q?ÝâY‘7aôú #[õ0*蟱
+¬Àè7a ú #[õ0*èô£®ÃŒÔí/Œ`lÕÀ¨ £~ޔ؀‘â&Œ¤¿02€±U£2Œú©g+Ú àÐp8Àت€QFý콕mph8Àت€QFý+Ú àÐp|€±U£2ŒÚ5$ÌJ‡68¬Çœ`lÕÀ¨:©K»ÇuÃÞº²‚ËG!㺘 ËÒwÓÕ\Êí¾Vʅ±áZ.þk¹ˆvíuBÃ:rëB®‘º;çuW¸9êWo¾¾L+èÓ/êúsÕ©•Úe#˜8˜˜¯ªÄ²@W–³+YÝ©Jtµµc7]¤ë}Ď]»ôA<j×¼‡À9Ûuæc¼9ÿ‘Þyê!„yõƒ‡$NåßÐÍ_VôóÊ\jWA`O:ÖÆ;z‚_vÂrÐ<Æ!ÂTÞ¦Cèß™‚ßõY“ÊLjCHX<ÓD
+›¼þecy‡þNæÏ«[Äð‘8tûÁ!ï¡oCoËa€\ˆ[ôÄ f•]°¨Ì¢×…ÅÀ‹øÆÄEÌ'2Ñ?’¢¬€Ç뢕yÔ®„`Žj@ìzé<
+Cì`¼!’#× +岇^êF‹-b€¡âå0}üC<Ù_“,>cÐ!¸jF†0—,b>–Á.½Vª&šÅ?¦u+ß×Ým9éËÁ,¿øVrtú=Ýd¦ò‘5š{¡Ë>ÿú»ÙbEþ|þ.TÓÚ4³å¥ä…‹]³-)‘«Vçy– Y •—îx÷êàQ!W4¦ÃA•oVƒýé£/ãÄZ·Ü˜þ‚#Žj’ÿº'ZçÅä2c¯N‹kE:ZÅ -`†SbYªv8Z¨Û°Eõ—Ê æ#}b(SûQÛh¡Gªá>„8R-zOJEÜEÓÁ>²™¸ ø‘íüÃ>ü`2p›DeIK úMûíƒ%2ÚÔ êÅ(í°ó‹y‰Œ.ÈãrN~P—¦ƒ ä88|¼ØCKAN?g—N’@.,
+х]h<Á…K?¬ÃQ¡¢v5ðÛ¢zYË`´ˆ~ü”1ä¤ í¬F³Ãp»M/1„i¾-b •1ô:L¸Í϶'!Ûc ßõú‰á-,^Ú¢àPs,èwðMó¾©
+²ýPÐÆH°Ñì“s^Ë ±}ŒèÃ0ðYsˆä˜[ :x¡y/ô +¸ÀpÍfŸ,&Ö•ß‚£rï¸Æ­ÛöœÚØwn±ùIjõÆSÒ03R—]`³‘uuÇ nºô‚~ÄÊ Öe“×üžA\ô_·.ò¥­ö¨³™LýžÎ|,âR æñt—0ܸ¬n(Ӊ;$¸=½ó„ëó¶O‚\/€÷qO/X/à
+™ô؉6Õ6¸Ö.ÏÀãÚ@S¸bn½h½î³áˆi´ü_†}ÀÍÒi‡­MÏ[Àa]J-+©E_+Éüªqêí¾¦£vý±.;šï“‚Ú]Ø,üIý±ÜÙE®/ÔG<ùë[‚¿Ð NÞNj~Šñ˜Cv->ò©çÐ>¦ð€É&)¹#r2J£×¸¸¿™ŒI´,¢ÕýÍq¤ܓ
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/example_PI_blocked.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/OSLib_event_oneshot.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/OSLib_event_oneshot.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/OSLib_event_oneshot.dia (revision 1676)
@@ -0,0 +1,16 @@
+‹í]ßo£8~ï_èkâ`cóc³íªw§“Nº‡Û÷ÈI¼)w"CÒí=Üß~Ɛ¤hSÀhÙºR«B§lÏ|þÆ3&Ÿ¿|߆Ɓñ$ˆ£;ËüróyÐOâ{ÃéÖQ’]ݙiºû4›===ð9¡iÌAìAÂfÿÑ0¤3!43ïo ãekšÒì^q—¦)–û”ݲ;sIWÿlx¼Öf.UÈ­â0æƁ†wæí7ùeΊff¥v^i{GwŒW›Ýîâ$"éóîB¤¡ìç ™B*BÑæþößæTÜ8·U÷ JÒ-å› ºÔà +ó@ÀCÇQx¿‚¥j¡j\µ‚ Yìbžr¤—J–q2åzR¾gíõ$+
+Sy­#ðŠÖóÛ'“ntüVÅ¥¾>3^<Ô/gO4A,CVôó…‹ÅË¿Ù*-œç¯”FkÊ×ÆÔø#ˆ˜yË4‚õù§Uö¾ê8ˆÖĀ'UÿÛÅA”æÃ0…ÖÄ9EÓ@45¾\VÛæâñi´ Ù©}`‘ >™#œýêˆí®â(Z°h-ÿº@øÍNç7óéh??°ëüøN'æebe“ãgs¡úÉ)÷¨öïíž@x<[$ésȪÚY´ßæã~gý+ûžÖÌ:ê:ëÐdâ*œw¡Àò]ወ8ž‹Kß²'n~ÙNošEEk• +TdšÐ[®ó%¹
+%ø½¼²N4èúGi¦ì~!òk¼ç 1³.zY°y¬ÕÔ°$½_EÙ¤®1«6Z$o¬Óó’PZò«›"±‚o¢-«Ÿž³G_;hµk¹R°;£€¥¬³ÿ[ãñ}íú­\ßҎ߻ã7>ÜÝñNû
+]ßNÆÉ!™ Æg ]ÀSMûª}jh‹ˆ'XPÎã§fêG:¶¼Y´I/GöèÃðºªx
+ÖÝ4ôcÀ¤³»JÍ:Ât ûu…éb¿îÖë*´]¬m÷ÂvøªÆtq`¯'m×ÎlW(´ðµÛvzµç¶X‰è䊽fD]\o+s=¨]ïڀÇíÅ÷ˆÒGn{àSØ#·=ÈXBªcŸv±OÙ¬tô£¼È#D-}$Ü\€%
+¸ã@¦Q 
+TÌJ£€ÊÒô'«LLæ /0™Oe â2“å^Õ •Ly˜ 잘FŠç?Û8p'"ËÈßÜίrfø㯜‡Ø£Å8ßÿ+Æ^¯
+­V…Š™éEA)*t.‡€X-*ý( ǃ
+_™h×X†ø×à@%,ì ,&ÖèЊ3báêT³9ÀBb½ :@ໞÐ86t` [í58ôŽ‡aâIعš†¨e8KIB2'2­ƒÕç$ÉÁ$éKêŒz¯æ‹{0_G¹ùÚgóu1_ç +óÅ
+ÍW'Õ¯7ßî!¤}qÏu›ú8Ë«#™Ww²š¦ ¸Ú© uÉi¤MøjvúؑvÔîH{G žz°áJ¯¶¬°¶áë#d·VZTNÊKȸ–lt(Ü*&ú`ɀe^?0 ¶ÈìCE‘…ˆå #)²0Œ@CA{(ЅƒmŒùÝ›ª=c Ñéqvìt˜SƕNÕ Œ¦Ê¢aî‘ÕGL•WÙȹ/Šlà0E6ð­fôgÌa6JãY`Ç>¥Ëp~5–lÙo,IeŠL×ØôQc£eõs
+CipàËØàT€ +el@tlð!bèØ`0,°ûyÚTÞ(Àz£à½ŒFƒÁ``йÁQš9 òPÖ1qàÈ3Yú…T?78:i0˜û“Ü_)°ëú'à„à˜h€ S¨a % h0TÂu.„A€¨Ý5Îeæ›ÆBÕ0{ÆÕ>5HŒ~׸{‰Rh•H Ô$ð#‚šF½Ü_) œBÉûŽ,Ð# DZâ€fƒ!A÷txŠKI³‚±üɀ¸Ì*K5øɓŞ.%ðåV?0 ˜XÀ}A
+¦\l¬ÀÖxÐ41x?"ä×òˆîoJQtó?ygª¿˜l
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/OSLib_event_oneshot.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_Power_DualPriority.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_Power_DualPriority.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_Power_DualPriority.dia (revision 1676)
@@ -0,0 +1,12 @@
+‹í\]o£8}ï¯@ô5u0¦ÓŽ¶;»O³»ÒLß#'qfˆ§içaû:|4…@ӎ†•#5äæ^lÎ9¾¾Üæ㧧Ul<žDŒÞ˜Xæ§Û‹ó ŽW†4 ÉîèÆ\
+±þ0o·[?'X0âh2þÇ1K£±y{a¯̱À»sùY,¦A ŠWäƜâُg:73«ÜnÆbƍGߘ—éËçnÆ%?oø^ã5áU·«5K"i"ž×& +~vï¯lr«DÑÅíåoîevIù‰½¯º m "V˜/"z‡gaƒÀ.fáôSÕbÕ¸êQ2Y3.8ŽÄa)c1Á4‹#ø†´“Ìp,¡òÖ@à;¼g§_ ÝHìT…i¼?ž_Ôݞ‰Æc”DӘäã|E16ýNf"'Ï7éó¹qeܱ's¯#–iDóó«L¾ê4Hgr¾“*ýÖ,¢"›oôên6ÍB“ëé´ê™ËkÇt“Ì» BoåÛ5 å\ùÖ.‰Éj2cœŠI£IÝo£¹XŽè0nßK-–¢ÙyËëN–l;©Qø㌪ùñ‚­1 »cÒžjT:À-PéO1*[Gã²?\ÚÝq©•î^+‘rT“°-›~ET:ÝQ‰Ô«%Ú«e | +G@#ó¬È¼'O¢šnWhÚ#G!0¯,`ÛpdÛCȽvÓ#';jVìæ¡´ºŸ­Ø4ÝÏt§Z²«lj¿GVÃÎöýNCÄFE]¼ÝùÜäw¶á‘äÞ¸Kœ
+ÛZ¢ ª£Àj"-~Ôy]±ÒW·@rº +RoݬN›±Ú +©RðºŠT«>@^ð"ǵ‡£_±4þ‹Q&fZ ڈÔjp65@Õ Pº‰’îÝB
+d¤¡È€&~+◰¤‰¯’ø~Wâ»@u©yWi.¶^‘hîÿ?¹_“&¿Jò=ì|¥E*„Žð‹]€å„2¤? ø›Qã«äÎÕ}´"ZZnJӂ R©­Y;°HÿÓº5
+¥: $#øó8"‰0><#JŒ?#ž- -…iY8,@«]p•&
+2EpÑS$
+¾Ô(C$QøLçx*Góp9ÿZZj‚«“…ÞU¡¡¨‡~ @õómßw*ï»ôÓí_àé6´{X¬B…À”é«ãŽ‚—r6ð’èH{τÄ͝¼ )dõzÕm½
+õjÕ÷jE~Jt|‘Û«:qèܖCř¬¸+sCïچ ص±:-ãMÉÏIzé§ ¨¦+¾ÃÂyës£e¯¡ó æœm«#Øc®«çILèâ­Å×A×G–÷wG˜1J%\$¦“½/>1–’ »A ,mÜ6öŸÊÄèàNÕ|×É¿k5~· på‚ze«Û[åúªž®2ÙÌÙ¤–¬åñÔrñ&ÞÈk=qš´=¶ kmŬmJ½½î¥j×¼·´¨e½¥ƒ)e½¥P'ÛízKumè|cÔ] zðJ=æhX=æ¶Öv: ŸKüî*àŸ#@¥|ÀV>àhh§º±ä|JtW‚P½¥| V>àjh§º²
+dÇ鏠Ü^”~%åöâ?ÊF˜4I
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_Power_DualPriority.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/kernel_quattro_insiemi.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/kernel_quattro_insiemi.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/kernel_quattro_insiemi.dia (revision 1676)
@@ -0,0 +1,4 @@
+‹íš]oÚ0†ïùQz›%±ÚBµn»˜&mí®+C\ðêÄÈ1¥Üì·Ïùh!_…:u5¤ ëèœûõãsB.¯žBj<bML`»æÕ´wt.¿ ŽBCDqr51—B¬Îg³ÙØt#Á¸MÉڎ±óQŠiä˜Óžaì;@ÉX>Š„àd¶؈Pˆ'æ Íœ­£À̬r»9£ŒˆN̳ûôc:¹§àçß+´Â¼ì6\±˜H±]ULü$¿{6¹U,¢Åôìsÿ,»¥|`ç«îFƒˆñ‰ªq8F4›hàó,¼=ÀLwª;×€Äw+ÆGDTƒÌ£EYÁ×X=N<GTJåµD€º÷{";pÿ÷ˆÆÇ$ +¿ìš·îÀ'Áë°`ÑàeC±¼{Ò4]™÷­&ï$&3ŠëîžDâÝÜo[ºo»ÎkàøÀJm<-s3çPâe»c3ȆJ‡S‚¢-æ¹ûëݱdäsœoú½Y`³?x.òônŠÄã“q͞ÌÝ¡êš &æ/·8=儤3 ŸÊü¬Øn-PN·ºŽM®g³²g.ïE Š3ï®=XÉÏôlw`¾üU‹‡)ïæŒGÕ£õ=ÒIݧ»¶šÒË9[ø^b²XŠfçÀSs/Ù殦à9|ÀÔïDg'BeU‚¶ªô¬FUÂD•ýD• S%ЬJåtŽQ%p5ªÒ?EQ~£”¬d%R&l+Ì¡åk¦Ÿsâ¦Âô4 S9£„9Ð(Ì¡~a–ÊÙ÷Pæ-~5²ôÚÊr¨ÅÓ¨L`¡m8ðýþÅÈ#ËË.ÔbŠdJË¥]ɦiAÓþ¸`Wj¥Dz(~ˆZêWÊã¦fˆE¢.d2ž›|akNäÞsÚÄ©l‚CmÄÛCuuŒ¶T¢¤^êâì?‘qÓO»@²^D!®_­Ã·MZmý¯ý¶(ðµžPž=Žåõ 5<ÜlcÃÞWN’iïh Bƒ‚¼:èDÁ uo?LÐ=ÖYxI]0Êqݤ0nzùÿãà{2.í¥ÂmW!¨2¡¢³Ž :¹à·æ‚«
+#Ûí dëpJTȋ„ê8p;| †­ŸXªÏì|odsø¶à ¡àv:(=3(¨ªC€NŒÞP;dlúgÀÓA€Û!@°CÀÇ `ܺ#ðõ2ô  +ãIQà珮Pìü†Ðúm , õoÄqƁlã'ÿr§ðN‡]5 Ä’°:ǁì:}‡pÚ+¼d8íý1óÕúg/
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/kernel_quattro_insiemi.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/schedmodules_lifecycle1.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/schedmodules_lifecycle1.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/schedmodules_lifecycle1.dia (revision 1676)
@@ -0,0 +1,14 @@
+‹í\_o£8ï§@ô¥'¥Œa³éêö^Oº‡Ý÷ÈI¼ »"pšöå>û™?)@HÁf“•Š°fÏÌoƞÁŸ¿¼l<噆‘øShºúåéîóÒ%Ÿøÿ*$…ð£ø×T]3¶ý4ï÷{Í{ BÍswZDÇÿÏ#c>h¬>Ý)Ê1%a$¾—Ý%Œ…î|Ǩⓠ+ªs²øµ
+ƒ¿TÓQÙ¸Eà¡òL¼©zÿ#ùSÇ™qÎÚ[²¥a™ìfD.Â^·'CjèÄ×£1Ù¨ˆòWO÷š÷é+e7rZU/Z˄mH¸rýS>!%^:P³áaÞÏ`.›'›A(›ͶAÈBâ²S&ó ð(ñS>,ÜÑö|¢ñ¸©œ\@=½ýfÒµî‘Þ*ùcÂÏ#¯4Ì^êkî‰Ê³¹sfr¹X0ÿI,sžoŒøK.•Gåoקj$ºª¸Ë©ú^ô¾ò<pj|£²ÿm×gÙ4X#œÏDÝ<ÔўÏˤCþöÄ_y4#¯9hdñËXšŽF˜_Ú±[¾?£þ2y÷Ë%:}/8æÈ¥áó•¨åO”5×P¬G®p…UɟNÕaOˆ¦·Sµ_`_ƒ—
+3ÌÀ’i(¶ƒø2F7; ÝÌA蟆!ò$ô÷Oe:`î@zMÝ՚ÕÓíhGë`?«ˆõÍØZîßg•5軚¥92%Z¥¡4Š/S³c›´ecSAžªÇ--+b$d3†Á¾Ìú»MF½3í™GýÕ9ÇÐ5»;“çkæ!Æx®Æ +©¡·ØÚS/¶ß¢H]D\±èàZc ¦€èjʍ® ãYV?HVId^y–ÿ,kã. §\´Æ]Ðõ»‹»ËÛ¢ÄéeQÒä.N»Wàë\:‹Ø«GÛG~1z·LSzÀ4ò€éô0͆€y;zÿN_X…Þq÷,ߑ¨vŽ±xdkY–9Áà3žþhǓœp‚ÁÅMÏҘÚ8–÷¨J;Ÿ )øðøGÍè™}±¦?ŸU±ŒïgCþ
+v¡ËW×ã.|N–¹M[pïgQ4ªFÃjÃ"Ù$¯br¼{®'ÝÏ]ùZ­›Ü¡/±ÊK© ` ú@—õ¡-óàûàh؈Y&¿¯
+–n´%l±Vð­À d`ȄG@.( ®aì¼ÁD„àvà€çžÊƒ= A+$(Ùր2‘ˆ(QòXL Œ[Y#sŸ“Uà mb` hÐt®T?B©•êGCs€=B<êšnsŽ·‚ßIôKù9à@(Zր2÷ŠAçÖ(µ¸ûý¡¸ÚWmõ|iUo+ïõ@÷’:’[R7ó’:îKí¨¡¤Ž?€â;WН°d·)&uÁI\%uAɊ/ŠT…—ŠÜ®—ýžNE$ÀDS°S0óêp[¸¬W±½@C¯¢@Œê\¾6F@æ>Œ›|@|q“OÒê#£Š"U>·†ŽÅkéXXDN~xh!ê+Җ¤ªÌÁzµ}5.‚ÎUY,Ó¬Óp_˜†0 +ËÅ4cÀ´w™°# _4¤ç‹0_:ؽ,Κ0nßúšŠ¨IÕ|ÌàÑRÁî'˜ +­¤7¤ýš:²q[î!à,pR˜XÉûFšm…`(¶*Mk(H‚Î…{d¶›I÷@æûÒ¶BçæÚ
+Í ZAѼ0
+†ˆœÐ‘ßLôÎmÁݺ^°ÚñÜÀà u—ñ€}á)` J=a A¡ž¢¼4È[  +Z¡AѼ0
+H@k¡ÔÒrÖ[̲ÞB€n’ÞBw‚–½…Ǧ5 Ô­ãî_¢Ë-ƒ¦Ý…Y´¯*(l(‚ +cË°è#@­¥¿¢òÐk(ÕÒfÃÌpoV€šjáø#hßñý¡!ý0Š´x”žFÑGñ65ô@ã#º}jÊÝ&‚za›ˆ»ÿî;ðÝ'¨æ°MÔ[>hè×þÝÁÑQ~èZ¾;s”ø½Gù@Db`ÉO Ì£ÄÀê'1°šÔϹ›P„ŠP_*BÙR®¡¦.֞T$âC.¹*2T„{SjRn-v’^76e‚ëÉÝÓßÉøOw…òŸîþx{ôc
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/schedmodules_lifecycle1.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/schedmodules_lifecycle2.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/schedmodules_lifecycle2.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/schedmodules_lifecycle2.dia (revision 1676)
@@ -0,0 +1,12 @@
+‹í\Ks£8¾çWPä²[•Å膙q¦vöºU{ع»d›Øì`pǗýí+ æe$1öF©ŠSFJ7-}ên}-øòõehÏ^œøQ8Ӂaê_ᆲ|ò‰ý®c²ÕX‡0I¿Íô +¥»O“Éáp0‚cBh¿7oò/ 2a&ú㝦
+XJÒkÅUBiì/öÔÓB²õfú‚,¬ãh®ô¼WÑoQ¬=“`¦ß?e?ú¤3©È9#{Gv^\»ÝE‰ÏºÐã®Ñ¥CNúyҧ蕰Náúñþw|ŸßRq¡”Õv£Jè–Äk?lê‰=ä +¾ŽÂû,d+d+ˆe+ð“ù.ŠiL|ÚT²ˆ¢À#a®‡Æ{o¸ždI•s†€áҟ|J£žû"Ar‰ùå·UóÞ¸ŽýÕùXéÑ!åà¯èfþ"i¸réGIҟýÄ_^ÛÝû!&þÈ)žwž÷þÊKzfºÚ§CÒ¦è6é3¼ÞïR òKµà”©Èы ñßÊ°¤c\,ú“QˆÿxKZ˜÷7%áŠÄ+í7íO?ôô2ªšºæ¯fú_fu|ê1iÌû4h•‰¦uƒ›3Ù%{±¨‹ŽÙݓpx¹xÇp­›}|Ø0­‡)û¦n…áÜ WÙ½_nQ³Ýjp¸ß.wuÅm+âœÐÔ 6Dl“š¤²EÛ°iOÁÁf™Fl–®•­3Ýj"´&4¿œcép}‹^Z°`˖ˆ-€RpY)¸ É./ð¶óe‡ÍÄMˆ=™ü,(4mz +<¢7ž¿ÞÐnÙ`˜ìdæ-ÙtöÒîæ߇Ê—ya M©.¸o>:#ù¼ªI-íÎÍ;½¦}-ÿ ŠÿJv˜ÐD<&–î1QŽÝQÂ1>MÖîþDh66œlfç =^]²Çôå¢ñ(~ ðsXºŸCeøuGñsgÁÄÚ?8˜¾{/´L–ÏL™h†6ôl¶aÁTeö}˜^šE#fT7µ>]yPÆÂUúÕ»•Ÿì]n:h»3[ð.Â%
+i›ÂôzÑåhû,aðèidŽ}TÅûUTu¸†(ɸÝ65§¤¯™ýð)"¿·^ûì”ËúÒ1k¥¤º[@\‘ë
+¦Wám¹ǖÇeà)W0ÄÔÀ¥\WÐNðL¹=#•àÓ7‚á1žáö(‚GÜÆÇᆥ\N"ûl8£Ð;=”6LHÙö0“æ$Ž£C÷®qJž^¸>·ØLÃáUѳœû5ˆÉ×\ËÉålÓy€¯éšc œ®ìëõ§k¿°]Rÿ™¤là¯*i”´U¦r6™Ñ˜²6,=kCeýc ^ÐéáE2·£‰»È‹ä–,PY²@c•,POÉaÅ2·¦*
+ðMR¹%hU¸%d*šù¥)Žâ–F£™Y¤úT-9![ñÌÇ Urqςø‚©ô,3;³…áHg¶P©‡áíÙšrœÙÖÏ9åÊ}4‚M”Ì*oUìŒQnª‚ô™ÜuzäÈõ™Ó×2rÆ)ƒT +jmWeë+ƒpÆÕ `Š
+]»—©€Õ‡äf,§U–µ¨ªËGÛÂ8ªê2ÚƐ%béY"*w0#ðäU“ZÛUÕ¥MÜ5},·†‡Ë«†‡{jxØQU—Ö\š|“\¦Õ­0­«ªËÇISjàRyŠT_D©¾Û†ë‚Ò°Èbº7UuQn`PÅ×ñ¶+û û¼ûʲ…?
+wzž¦âÿ·G¨!°d²yùo¯dȟx»2¯`òÔI„a¿šŠÆ-.béñT:ñ’D°Ì‘"àž²šeÞàËc¬Î“RßùO¸ŽL€9†kc;=OÀþàÏ0Ldá'ýƒlÙP«×50ôèÔM>wɞ-5©“ïÖ&Ž9ùUãZÚáMO>w؁_fhañä-´X#…–ªI-íÖí…¶ÊåIèw Òrå —sǘ{Õ»Þ$ä.AÚrÁô†¥± d_ókc¯·úˆø«r_"ÂrÈ2žœZa°ÃՍ0+ßIòCó¯2¨àp
++E«\æòïÙ[Ëï*¯5¼û…J֍Ùc
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/schedmodules_lifecycle2.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/schedmodules_lifecycle3.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/schedmodules_lifecycle3.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/schedmodules_lifecycle3.dia (revision 1676)
@@ -0,0 +1,9 @@
+‹í[Ksâ8¾çW¸œ+klù™˜š™ëVíaçN ¬€6B¢dÂeûʏŒã&¶å„§*TYîúÚ-}úºÕ†/_Ÿ÷D{B<Č.tË0õ¯Ë»/†Ÿäÿ–ý& +h]-ô‡OÓéét2È9„‚qƒà£¢é¿8•FS}y§i¯(`4–ŽB!8^Ò(Ü£…¾†›Ç-gGè‰Uj·a„qí ’…~ÿÿéÓfšÃ¹€}€ċ°û ±4çCɤ'ú|e“Z…Òˆn—÷ߜûä‘ҁ «êAkˆ=ä[LË~8‚$™`øàeÞî`­ÚQ퀫v€ÃՁqÁ!e'kÆ‚4ñ#øµ÷n ‘T¹ˆÕý Ážÿ’ðš’á_»æ­;pËqpyæ,jPN8»Õ³¢éJÐϊПpˆ×U==¦¢7øsGø®ë|Ä
+V:oSƒ´KͦMí® *$§ØgÄSøïYZÒÒ9N7ý«Y`ëÐF¤áý- + ´?´?1Ez–UM]ÃÁBÿËÌÏO1"‰&Õ§4A–-¤3™.¯döz]„æòé!Ý”Â[Æܝxòã³å¦;™Évþ6ŒÒ¢AüðׇTq´ +™÷›CÑs՞¸Å!'I.cX@Êîh;¹ð=ä: &×ÙÒµìîBwË-€&à ›® ×wö\Á.«vy*ÙeGìr#vЍ]ˆ ýjÃ8-—n½ÄãÇi¡ÓKJð;@ïÞîD=¶Õ;ܱӪ¢žn®_ª…þm¬¬=Е–(=‰žm$zùÊ÷móæEoÖ·èÕÐËîAõåªgg9u>HNu.æTg2Gz•ŽreW¡8TDFÒ_í ¢UNZå(×*;K¡óA´ê"™äýߜL?ѳ¨ “Ûƒ2Y¦Úrßžäp=Ïùly† "—ñu;¿"šŠRÎÈ 6uµLÜKËÙÚnPlv5Í· 麶 £¢Êa4žšü`GŽeÑ9íâ§Tý55Þî"O¬+ÈÕÆIÜ¡­róºukÆÝA‚·tªW'ÛÖ×ÎYe£@©x=ä¥RLÃöÝ_RlóÜۑ‚5a›ÇQÚè@Y£¨ÔYW˜+íÐȓ¯ +&îK=`s˗'ãøòã‹ÀO>jxT6*ãÕ¨*Ϙ~çcÚ~Ø<{†zÐг޷öqûóÎu¥§¶·*sIÚ®ð Îªw™Jò¾ó¨$CZAÎÙ©žIvGäAt{éE†iø]]4¼*iöÐOye™=ì[å~°Ùl>/Ç,ßÀ’äF*¬#ZíZ9j5–ʼhu~|µüYÖÈ÷‡jäû +|läW§Ð›Ô¶ïÜ\'ß6ÇNþo”Xü±ƒ7\féü}ƒößí¸N
+²ó»=Ôù=RÅ}0žß«ÙäôY<åuŠ›Õ)³AꯡNy6õ´äîí,yò}8ïý—\
+ŒwÃKîõ3<å9ÃÍr†7HÎðr†÷?ÏÉuü£ƒå]îW Ë»ÿñô=^˜7
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/schedmodules_lifecycle3.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/schedmodules_lifecycle5.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/schedmodules_lifecycle5.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/schedmodules_lifecycle5.dia (revision 1676)
@@ -0,0 +1,14 @@
+‹í[Kâ8¾÷¯ˆÒ—]‰ ±çôÀhg®+íaæŽ x ;ÁAŽišËþöqtȋÐI5;A)¶Uår•¿r}Ÿ>¿ì|噰РèLš®~ž?|Z{ø£ønÞ)b +£§™ºå|ÿq:=š
+1˜æ{-$Óÿ°ïã©4UçŠr)`9ŽÚÒVÌ9ó–NŠwd¦.ñê熺V“Qé¸UàLyÆþL}üÔi*fš“sEöï +ŠÝíƒÐCøi_R#'ú½“Ž
+Å º™?þe<&SJ2YU­UÂw˜m<ZÖÃö“…€šÏ«ðvKÙ
+|Ù
+˜l^¸ØŒ3ìñ²’eøÓDgÒ^O¸Â¾•k†€¤'ͯ!]»=’¦Â~ŒõùøDX:©/ÙNTž½Ð[ú$µób‹ËɊ§›çÇtÙZù üíQ¢f@¢«Š·ž©ÿèùÝW\!M,xXÜûÀ£<]cbg+Q·u²—Ë¢h&féÆ'©x ¹æÄ?OÀÐtsb‹ŸvúV¥ B×ñäo7©¢Þjr¤RØ#V<,ˆËz”­ðQäIá—UÉzgjÉڒФ9qü +‘ð%x©ÐC X2E`Fa·@ >Ù-V£åÄҋ=±ü£·æÛ²Mgôp:ˆÞo³åõ²A;Ùá68.*²}3ºV'ü·Ee +>Á®a ¡T|‚>!4>åM*÷#4$>Ù}ãSM$ ʐP(ËTî ™Ê¸š©Œ‰Ûn
+âôC!?ù¤¨žÐÃ.‘n ‚F`HG”%&w¸êwÑ?~ÿN^x…ßÍö;ÐåM +ÛeOÀÒL©ŒŸÛéåÑR”8_ÆÔ%ó¸Ô͍+TÅk/Üc¾ÚÖÔÆW*¦•?Ê«Fí鐯ÁyâÔ5í¢§tüi*ÎÞ®"X7W%1R¥æ’YÑãO7E¢”ÝЩöN¶­o]³Ê¢V*X=¤©Pu +9æ+@¤YÀ¼#( >>8Ð
+‘5â€L°»â€+•¢¥Ÿ'æù< k.pDi?¾øŽÃŸŠ7¢@ÈÅՈ2ËA§sY —r3¾ÅW7ðA@okñûaÜÎG@W.èh b€ù]͉üîHgÜë~ý-óŽÐ¾ÀŒÇz·£Ž’>¡›k ¹®9]U4pðÍú9¶½‡àE2ƒ×ÔL˞Àô䂠f $‚ùNN.+q +óçx|iUÄäÂk<¿ÈLd óE+Rùl¤¿òÙ ÄgçMªì¿{>À/—Årr„6B#¡ýûä€BpI@jè|™}û»$³×́ÊؼIýæý—±Àè! XÒ³¿™e{ìo5d{ï˜wäøm#ëx5šÜ“w¬@ӒšfšÖ  i5€¦Õ4p÷ˆl÷p¹lÉ}¿DQõÊ,Z0‹ðzTA÷Uµåf¼‰eËcE/•tæEÛÓÆàw {|»öývm;Ñù^ +S& "Ítí‰q~ÅÆÐ /Ûïàv}d%Z1Ó¹ I‰ÛNBÉsü×±ùCî¿eó‡_—§Q:
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/schedmodules_lifecycle5.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_TaskCalls.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_TaskCalls.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_TaskCalls.dia (revision 1676)
@@ -0,0 +1,12 @@
+‹í\]oâ8}çWDék6ÄIœé´£y؇ÝÕ®4óŽ xÀ;&A‰)ӗýík;i)!i©Qé D"ëžØœ{¸÷ú&?ý\QçW5)‹øûévôqNÐþ^ThåðE-ŽnÜ%cëãñv»õé}XYù”lüÿE”¢14voGŽóÔÀ1$εgc™nv
+´Â7îÍ~,ªrSÌÝfT;nVÒ²rî½q¯¾Ë—;n͌÷ì<c{Ö¸êš]­Ëšð!ì~}0dÀŽø|2¦UóAÅâöê×øª¹¤öÄÎV߅‚°ª¤8Ä©0¢ÍB„~>¬Â릦¨i€Ê4©'ë²b"ìdZ–£¢ÁaÕ«ãÔ3D9Už›8Âzsú‘Òƒîќêø£Ä£èWíE}Þy¢sGj2¥¸ç+§ÿàkç+CÅUsççsùÓÝéHà:d~ãþì;_w¸1¾Þu×ýÖ%)X»
+>ôòÝJ ­Ãñé´k»âWŠÅöcèe~¯AèCèèP +S¼šÌʪ8ԓÓLHlɜ-'õÈ a{‰ÉbɆ'j¶ëe¹ôÈüËnÕ¯ô㕉 ´‰™z¹M23á¬ä1¼Ž‚óPScJGq3Ò²þ;¡ªõ·ÈÏP›Ÿü§ôb“üÔô"!¡—p’¥§ÆŒŽ“N£ô ß=#]z†|9¼Ì =9§gº£' óSgJÇð3û_Ðs(µ žÔìžâ..6«Æz|æǺÌ7KûX +’õ > ëR>·„?#á¿áŸ¬‡ñP[롍†Ê!ÿçNR/öS˜$ñu˜ùqqLy¨†ËÄZtP»¥£Î˜!ºÈ¢ÐÞ¸nýh½¦d†_õBÒ3å…ÔïeÁú0ÅùvȗrSîÛcœ/{©’ñzˆ}rC0YnìÃyZ‡ äKQ²(V¸ÿçÙùö±‹Ö[2ª‰¶$FK:<ËR/óÃF rDâoP¾}-ø +ó¿[2ý]‘aä×V”$acVL
+Bª-±B³ñAšæOð…\‡‰†ÀхiÂï˜ÇâÔꁒìSÌ
+‚IAÈtATúÌV×?1B“0€ÐO"x!ùÂ7Tÿp¾ Jml ¤ì²j`R +r]5H G"]xˆ +šláR"ƒ¯³%žoD'ÁèϒÁVT!±±ÁÙÔh·„@Ã;GÂ~ÚV$Vóýí«u~çïÐÉzÿI¼ÿRà>ï×î» Eôfx;!óèÅüCtÞD"XÌñfeQLp1—xÝ´ƨn‰ó ªªr;¼›iZžP\,žÛÍ üLâ…ý—NDãð$4ÎÏ@ãlGcÖFgáq~òþ«¥òI©¬ÝÊ2O½uê¸V³Ð‚É^ƒŒk± q&L«gHdåøMpX»),¥8—-‡9õ×ÁT++–À'MŠõ{l2ž³&¸ù<õ’'=6AÄ1/¤flr¬´mÖ¡•ÍŽÊ€~kM&4˜Î+® ¾/” çJÀAӋ¨™‡V Ԕà€YV ŒŠv[Ì™Œæe±Œ ҇mt(c‚ìRb‚È*ŠtieeÀ¨ d§Èm +×g©G‹/)"ˆ­(é°ñÀ9… ?ų€Ù­3 ·2ÐÀ]†X P’€FY +0©¡vóLìÄäí§‚²‘N]Hõ}ßßg’õ{£~¯Ý6“~ˆ°µMsË6ͽëŽÙ}:Yï7êýúÝFgØðánK ³‘ÿ;Þ°»çՀHÿ¹3F·ÐÈîù¿ãŽy{»Œ‚ß7Çòy«·£½²ÞŽþîðÄɆY
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_TaskCalls.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_Server_e_Master.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_Server_e_Master.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_Server_e_Master.dia (revision 1676)
@@ -0,0 +1,11 @@
+‹íXMs›0½ûW0äê
+°±±“Ø™¦×fzhï
+V+$Fˆ8É¡¿½Ë‡cóeÇfz3f±ì“–·OÏÜÞ=‡L{"2¦‚¯t ™úÝztëS| +¿@âPƒ§W+}«Ttm»Ý±—+!£ Š‰ñ3† +2ôõHӎøXát¬ÅJIê&Šh‡d¥»ØûH‘p_Ï£Š8O0!µ'ÌVúÕcvèF‘Æ(å9‘;‘մa$b
+!ê%ª…´äIÏG1ET A<X_}µ¯ò)‡\MmQ!–åuI0Ë 1A‹É¾
+—¸C°¡äÐ4ÞDB*‰©ªƒ¸B0‚yŽ£dBºãÄf@•S ±Þ‘=~£tk{äC•~Ìð~!²˜Ôý¡µ'S—‘bG-&ÜßÄSEóüT˜ûXúÚí^<ë1uú+ý‡Yn¾j Ô;®¶_$(WyœñìP‡¶*´¥vÝjf sÇ<`$Ï>GËÙ؆Ӎµ@ælì YG8ÂH¸ñ„äu1ùˆÕdéwÔWÛúŠÞcõȽ%4تöäÔqæñVì6 +¾§šeÞ8°3+­þ¬\ Áy¹@öž—ì˳ó‚>©Ùš¿È³jàæ¤/7-¨ÇØ2dgª’“ñMfó¹}c9ȶ€˜]wƒUi-* U£V‰i{§™+ÅUÝø=*|êi?‰„ò·x·;z ô£àª 8/B¾‰DRhD£N­Ι‡Ë!Ê {˺Àd¿ èØû›ÙÑÌVÀCÒü~OÂ˪Öh»U…釨Â|ÐM ö«¹5ž!'—›.2»üÿeáÇ
+œðƒðF>5¡³&”8ö)
+ãbÉ+0ä;å¤Aìþfv[÷€Â0¿º0½qR[ FÁéæ’×M6ïKVS°3–žY‚tŠq*—,þü“s¦ÙDӎ¾Va©6XJ±«f?кî +#<8½€E³Ez'†'8ZBëĵeGÛBË¥= ·”È>_h‡»¥šµ?;-žµZŸÝ+EeBUQȯ³4ëQé Îzô³VÞ·
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_Server_e_Master.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_LevelCalls.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_LevelCalls.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_LevelCalls.dia (revision 1676)
@@ -0,0 +1,8 @@
+‹íZ]sÚ8}çWxœWV¶ü‰K¡³íÃ>´;}h߁UЮY„䥿}%Û +ÁØ ±P'Ù13 XsçKœs|¯Äûw[êÜbQÎf.¾ûa>zŸôNý­Ú:*€újæn¤Ü½ó¼Ãáè}$€’=(°÷QŠ<ä¹ó‘ã<N#‰ôX=Š¤d¹—Øah‹gî­þ] ¾g¹[EÕq+N¹pn¹7?ʗëÕi¼“<OäÞ¡Í´Û/ˆ
+‘÷»³Ž<úÿ£˜:ªPAl=¿ù3º©n©8æj»ÑN¹EbMØ9ŽÀˆV €Iðk^°´ +@mÛ¤X츐y²äœbÄ*)ö¸?N±BTQ婉À ²WÔî”G5ÔÐc‰GÑ=õM}<*ѹ%YR\Ïó‘Äøò¼’µx¾IÄr$rçç#¿s>â»ÉgîWÿT|ÍePÉÔzMùí8a²þ:Lj+ѵ]ɗËfn¡î±5Åõ*ƒ,VQ<…!ðã1ŒAÜS¼]¬¸`ç~r •’ËÍù¤X +ro0Yodwò¤_îbË›^VíNïy؛˜Ð”˜0Cß&1“Š™Y< +Қ™¾UfÌè"fú™ÿ˜˜2S9ØxbÕ4cå—
+B›f¤ìr ¡ejMérf¹€×Áή¢0¼(ä=ÅMÌöÛ*{t]âÇw²…ù¡q±Œa`ӓ3¦™¦{'É4ˆ@À±*ôe?\©—¢ÚlQ1]l)›“¸FŸòV*#«Ñg¬äF;z–'*ÙàœÉ6X=^‡|â{A”Â=œ3=W4¿â”^P¬HÙضÁ<îxýòe¤ZŒ5Ûâöoç(îK׬µÙ°j‘q‘æÛ-Ò'©*Ò´þ#ÝADa¨߈|Á·˜:Ÿ¥Å`}Ì A¯Á lšAlj‰rn«eq&©.R]d†º4H߄|[mp¾×[R£¿¹ú€CècMŠ +Ž`ÓsG°Û''ã´Ô4ÕHå§×oƒòû)2ÿêÂÿBn~jÜLôsÚê¹B½g•ÄS8“X?ž€+Îس¼œÀ‹¦Õ‚Øà‚å $?to…†™³õS[u>˜˜B<³ø<Âuh<1¦1ÔͦMk+ºhÒÅáo`qsVç!ŠÀÅüÀâkVa™1‹õî¾m;ŽŸéó­ª9S—™þêÕ^M‡¢¬×þÌ9³†Â̦@ÿ4«G8êɒ¥G8ê=ÒF¼‘-Û`0‚^F‡S›&P]—?›N~C6ý‚4˜9*
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_LevelCalls.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/example_PS_status.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/example_PS_status.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/example_PS_status.dia (revision 1676)
@@ -0,0 +1,13 @@
+‹í[Qs£6~÷¯`|¯œŒ$$àìä&×I§¹›Þ4wÓGŒ›ƒ+ääòÒßÞÛ±Á86:î~ȃ>V°ß§]ízôþÛ"4¤J‚8ºêcdõß_÷FÓ@̔Xp2JÞÁÑU®õòÝ`ðøøˆÂ§DèX¡0X¡Dþa(pÑ Ý3Œíà©Ð"=†o„Ö*˜¬´4"±Wý‰ðÿš©xMûë+à?ce<ˆðªÿæ>ûô›áƒçñGð–b)Õ>Ôb'œÖO˃Ó%ãÓ¿{çáŠ.ˆf×onì7£Áæ`7¾hP)¨^5 ¢<®’"\O’ —lgx>è¤ +а +PÕhŒ—±ÒJ:<‰ãPŠh­ÕJVÇN|Âk>f0®Žxh¿`罓S†ŽÏÞ\ʆѠ@·Q(ž¤ÚXðaG4ã!H‚I(7gOþ”¾Þðä맏Æ[ãk"}víTÁêÁôªÿ›µ£Xqª€o&Ù'Ù2"½yÙ¦½›fÙ$Ëà&“}4fŠhÊgÄ!Gœsb›¼¶ åbìÇ*ÊkÂkÌÍ ƒ©žçMÞúŽ½¶´è\³¹.G%Õð´ü–*ªdá|C2Ì]³'•?ÿ~{["–GÈRF—8ÒEðô»Íé_dø uà‹}Ɯ~ð$ OÓBn=à¼Û}ÉF”RLL†ößüla,Þaµ´²O=p¼Y´‡^F«E‰ð“¾¢Jï’ñ*ç•/ ä9ð`B1‰•Ð ]µGƒµ0ÖQI\W%±erÄÊ5è3„¹g›nÕœVË:fŸ̵µß¹`Þ}¼½ýÜ)æ?Ä\Û1ätŠù](æÒT¨)ÈæòK$“Ô•ÌmØ´j2äâ×FØv-:Äq+uIn׫ú|£h,£ifv…‰U9Ì¥u¼ê¬ÔƒOƒ¦èËrm|kUÖðh:Jŏû€;КhãPF³cëBNrªÁ¾°ÚœDM_!8øl’[¶ßspð4µ‡Öq–)»³æÞjÉ8¼‡óã¬}³Œxåhí(ÅF6N³®:žx:\¡ˆ¥< ÈŠ\Ö"çŽÎ¤ +RÂZ¡ˆ
+syÇ»¦xWà9—w^~mwv]ÞQb: +“ +Hæ®sS̆”¤lƒ<Áõ0nmyû˓dÞÉ ã¡œyÇ^Ë1\¾¶ñ&¸ò%M¥ÉÂê’ÅÉn:&tåX˜ƹ=„xÌÃ.Ü&;¼¬Ä҇ׯe›™åOñJRµ“Wâ6²Ê‚Güˆéäë¸ÈkŒ^U]?%2D¸î©f\$9”C¤H.‹ð¿A|Bš=¹Xê'ãï•\uì|ÁG:rV%§S—œñYG•ž‡MoÃMŽ,˃›d‡—EMˆŸ:w†Ž…Õê>níê¸Õ< 3Ì!öy71AµHãuòꆟ*üd3Þtá'>ö.K~>ߍÿ¸ùõKW:ÜpC–ͨ‰1, w5 ï¬ô!þV"Ÿ^mùOi<ه”ƒåÙlH²Òmh«ñÊyËO (& +k'«ja2Ç%ž/wé5ãú½jžI›w'†\Ç$›½#J¦½^àÖÑ'‘h©zwþ\NWi;dïS ÿtéê‹>҅Ê« ¸~“Ô¦;Äm¾S
+#‡f}'œ +‰•UC0ò\‡´Q{,›Æat‘…n¾*‚»rHK%G~nÉÑm¡äxl1¬Ý_ƒÓܱyžQÆÖÑ=ç)Ó¸ +‡ôwˆv;·Q¬n÷öØîmÞKºÕ°êjX»çyƒ§ÎBqNÔJl@çYÀvEt9k£?àèT
+mVÕ6ˆn=üO×C÷hë[Ó­4Ø~Ŗm~U㜘ifç¹îsïemP%gþa`™vÒ Ö±ä‚›h
+Q#n3ú«ÝEƒYó4‚8h²®b¹ÄÉú+/n+<ÃòCþ’PÊeòw.â«LÊÚí4@·é8ÏÎHélÛi¼Œ”^GÊÿÛ¶dÎ5~tRŽÙ/á¯{Ï?‘¿îý ƒSáïB
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/example_PS_status.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/archdetail_PI_schedule.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/archdetail_PI_schedule.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/archdetail_PI_schedule.dia (revision 1676)
@@ -0,0 +1,6 @@
+‹í[K“£6¾Ï¯ ˜+Áˆ‡õÚ[»[¹l¥’ÃæÖV‚%—Ç3{ÈoxÌ0 „\qW™²AÕ-©¿¯ÕÝ?=îbí±S2ׁiéŸw# ?ˆï†Á&$ý7×·œï?L&ÇãьŸÈ)3c|04ùÆ1œˆF}q§ieä0½W܅œ3¼:p¤¸Cs}×o=HÏ[íÖ4¦L{€ñ\¿ÿ‘}ôI!fR‘óŠì=Ü#V»ÛÓ‹&üiÖ¤ENz-µ)Z%¢Ù,î?»÷y—Š'YMmUÂwm09×ÃŒó‰°ÍÀ~ž…·+X©V«VÀT+ÀÉrOgós%+JcI®‡³ê¯'YÃX@嵁€ ¤ç·_ ÝJüV™¾>!Vtêˉ‰ÚNð*FÅ8K£«¿ÐšäùÎ!‰ ‹´_´/ôQ?ùK×p4×ÿ°ªä«Oƒ&æ;©ÓoO1á…9Ò<´ÍB›èÕª.™‰¾C²‰Q1Çfè–¸Ì\Óò [\úiC1Ú-ה‘s_2Ä`2ñGñíù€^€/!z‹ðfËÛe÷ìv²¥ÇeƒïæS³‹Ÿœx"ÿD¼’@’ÀW‹I_ Òö¦Sǟ¥ª²ßn?…<‚šºúXkÓfÊli«´«­‚-kà+ž±EÕJx“¢ô~Ñä+=0,¨6‘Ñsú.'üvU uƒ©Ž,NjÒR ¬ì#§H¬X²CÍÆAä°{۔5®]J™oK3ß1l…ÌwM 4„ŸÙÀ _¬I7Âÿ_´>üŽ4L´ï(ÿ¹f˜ã5C/çPÁÛèT:GÚ9X†«Ô9¸îÔp
+ç<Óó\ýAçð;Y\ŒFÐË#T@6z„A<Âo˜ àÊ箾êÜušæ®vš·~ïäuM Y"e]¿x@ +»<Œe¼ª
+–jӄ'Óë¶V‡q:Ç<Œu¦XÇQm`—Ìã\Å<N—yœ«Ô?|é@ǘ*´ŽeÚ¡kxÏqŽé[Sáån$ÌùÆ°¦WXS†ÔÕ¨¤ OÿP9ýƒ
+ýÛ¡¿=Ò¿ýÑþס(O`+ç?ȋ ÿA^½þ;#ÿûñŒuÎ+U5€ô–¼£6=³MeÌÀ›9fegêìÌéÈÎÄó¾;÷$ZBÆè±®ý„GRò2FdóÚÉË dUtœ=èÖðFð6Ÿ&Ò{÷žÚÕËÍJ iaæKV.;QÒ<㑒á`)½±ª…ep‚%°¯‚ËP).—áR~OÓVZëË ix.=¹=ŒË`Ù<#,‡ƒ¥ôƚUÖ @¶Œ,CÉý› qÙ{@—àÒýïá1!ËzÖv–±­²Ï-B¿-û’Þºô +O!ô§iò妹—Ÿæ^¾úÔ«2ž¦Ç=÷ÐW”z•d«K¾ÊJ®~µ¡Wzk70…èõSô¦—YU,õð­ ¨éq߃#~‡<|ù“ Ê&Ø/o£¸ÊßFqÞUéàs´ > àk+-ø¾T'¼«'œ÷V4{¯Èåƒí©Ò`û¹ú^£ø᫬}Œ¨W€úüöŠîâ®òïâî_£*Ù¹?
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/archdetail_PI_schedule.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_Fig_Shadow1.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_Fig_Shadow1.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_Fig_Shadow1.dia (revision 1676)
@@ -0,0 +1,4 @@
+‹íYMo£0½÷W zÍÌGBÚ&U»?`íp‰·ÆŽŒIÚËþöu€mI¥ÚªD
+ÖhžÇ¼yz7·/ ÕVX¤„³™©ßÎ/n"‚®Ô?(ÑTK7w3}!åòÊ0Öë5 ¯)’\J2bã¢*ÈÐ皶› BmÖÊU$¥ A&±ÆP‚gz€ÂçXðŒEzUƅœr¡­é—OùO7Ê4Æ^ž#¹—h‰E5m²ä)Q!òuyҐgs݉)£RÄâùåsYl©\ØæªÛh#ˆLˆ ;ÄÑâ ,àYÿNá|€ oÚ7€è€¤þ’ )‘‡ ç#VàH‘áö8iˆ¨¢Ê±Bà;²Ëo”nlb©Ò9E¯X”›ºßv¢¶") (.ëÜi1üÆ¡,›çA"!i?´{þ¢ouÄÔ5Íô_æ~óUA%SçVÛoÉ “åãíœCÓ)4¥‚jf¡öŽXLqyÆ`êŽLu¹ž×¹ÀtÛ¡aŠ?ä‚jÉG“§_“H. úǗ è²÷&ñB6gwÚåN|í×(üéŽ:¥8x_ ˆdis +&ŸÈ_,oÍyؕóÎÈî‘óö†óVÁyÓ9Šø}r¾u1ïá|ŸŒ‡mûéƒ9&'ñ‹¬!¥Õ”V¤´€é)u–;;×.˜BOq4¿k‡*7ÇPÁ¬Z¿JLÓãÌMÝ^\Åÿ=¢ôY# +ðˆ3h|âLÖÁmÖːŸ<DµÑç N™ó!ö)u’Vm ò1¡dw~0ó_7 eØb–àúgƒY–œwbµÖ­W °»JÀxäô(N.v)“\œ¯"éE|=H@ Ø£Õ =:S§«ÀžÇ±í<?e ƒÃDö&2·3ïûÉàv&ƒŸ2”Áa*û/¦²qgböëÉà¾)ƒƒ+û6® ¶ìÓ&³IgpÛëûhs<y{A=0µí¯ó†æ!M¢ôyPƒVjP!Ø ¢w"¬‘¯«x½š‚ €®²P™Uxîh¬.m§Æ|Ì¢|ëï.¨†vۂÃL¬°‘TâfÛÙR[Um>‚¯«™·,´;fö)fñ17n¯+Ä ¿¡ÚÅ}þíy~±÷qz~ñ 8j’"
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_Fig_Shadow1.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_Fig_Shadow2.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_Fig_Shadow2.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_Fig_Shadow2.dia (revision 1676)
@@ -0,0 +1,7 @@
+‹íX]s¢0}÷W0øʆoĶÚi÷ìCûÎH1ې8IÐöeûF «"h…ò°3uFâsr/ç.ÜÝ¿åDÛ .0£ Ý–~¿œÜ¥Þ¨oÆa®©*vg }%åúÆ4·Û- ïJÆÁÈü ¦
+2õåDÓR(án­^…Rriæh¡Ç0yÍ8+hªWQu\ÂãÚ’…>})?ºYØG8g°×px6_3Uˆ|_Ÿ„tàìŽ1u”PA4[N¼iµ¥zaÕ¶ÑN™CžazÊÃ$U!:U¸ž ›€ŒMÀÇ&À"Z3.9Äò”$fŒ H+É ÔŸG$(©œKÄþzµüOҝíQ-5ú±ä#ðñzSûNÔ6Xà˜ :σcño”Ⱥyž$¤)ä©öC{doúÞG,]ÃéBÿe7_³
+LÕ[4ÛoÍ0•uŒƒ:tU¡ :Ž›È\íҌ 
+ÝsßØnCàû†,¿"(Æ驗|E2%ü§rušÐ‡^f`ÈÞWg+ٍîõÃ+¶ZþrG]ÃR>â0ŅèÎÁÁüj±’xoÍÛC5ïwvšw*Í[¾á)ᏩùÞÉ|Fóc*ÞîÛO_¬ù+5ùŒÞd‹(¡¢ oDQzÀ
+ÃŽÞí ÌíP)³<ëÇ*wehp6G¿FL×å,‡º£¸Æü'V0eێðÌdÐAø¨l£Û­×!?YÁ±j;sÏI\B®§8–ÔEYõ¡(ÚHŸ¬ò3ŒH +lÍQûµA´È¯«Xëè6ª¸C-@Ý* gDPŸÁÌ°÷&àºêFõŸ˜ÀSiÚ3¯ßNÐÇ êúö‚/ñ‚ž´X7Ø
+F¸3®æÛW>AêןÍg}Ÿ(MË>Øéß3£çP˜|ƒ¢ •g‚º§Nø^h‡=çZšFs¶mâï%éDŽ¢Ù¹‘ÜC7iè¿ÌÐì‘ê¼|Õ±œ½ YNþõ“%Î
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_Fig_Shadow2.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_Fig_Shadow3.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_Fig_Shadow3.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_Fig_Shadow3.dia (revision 1676)
@@ -0,0 +1,9 @@
+‹íZÁn£0½÷+½²L mRµû{ØÞ#ÜÄ[ǎŒÓ´—ýöu€¶ &XjµD
+
+Öhžgx3¼±rsû²`Ö3‘|dCàڷ㋛”â+ýI¼°´Ï6w#{®Ôòj0X¯×€½fX ]Œ þbÆð@ +ìñ…em;H±Â›µr+%ét¥ˆÅñ‚Œì)NžfR¬xjV¥]"˜Ö3f#ûò1ÿ؃ÒÍ`ÇÏ'¾—xIdÕíb)2ªMÔërϤÁÏæºeSZeڈÏƗwÁe±¥ráÃWÝFAÔËåû8’`V$‘÷–…Ó¦¦˜ii€f“¥JbªöA¦B0‚y£äŠ´ÇÉÌ4U> á½X~§tcyK•zÌñ~%²ÜÔýG%ZÏ4£SFÊ8·JLLÿD•Åó[ažb™Z?¬{ñbô׶h:²¹»ÅWMƒv¦óUËo)(WE\€œ­L4å¡ÉùtZõ-õî1Ÿ1òæ?@Ž bt„\ԍ0²˜$Bòýnržpr€5MÕ|?¤7ÎÄ\Ï ÍU³ï ïl.֓š¸¦NA)?‘8¥«¬9„ü‹É[³ve}àø9ïkº;^Áy9&¾IηæÆ#ƒŒ‡} ΟÈÉò¢jHéu&¥î]žÑV< …apÏ5Kó»v¨j“ˆ
+fUþUlšh.ìvì*ðž‰ä‰¤ÖΞÔà'¡öQpUºY/M~Š•¤ºü]pö
+á9b—ZGЫ +H>2ÔÁlÏnþé¤Åی/HýÓ!|µ8-gµ2Îh3ð»6ƒÐ ¶‚¸‘çøe+‚Fú5õMZA6Ç©X÷M MØ¡Uß jÔ k€žÑÁ JÍ'3ÏÛÈTÓ£YûxŽÑ©ÐíG³¯0š¡Î´µN19i€ Ï<¸9“0=Ÿu‰¨ÑΩÊÂÎäŒõ£4)Ìà -e¦ ôÒìÿfUnõêÌd+žå=eò¸z áûyçäÇßìÀFÿêOlÚw„°?²1ÐîdRÓ¢® +!2* †j©/×ÐrB}i;/p>!<Í·~t@5ìôÛœ¬ä3™¤4Ó&¤Y|¶ì®:¶ –R¬«ž?Xèwô<a„Ï>Óä.ˆºBPý‡ÎRqç÷äдdF Ö/Ƽ6´^Ž}=ÝEÅ„† ¤Ú¾…d¶Fô¤ +㨯”sVJqŸÿuc|±óߎñÅ?þ@ Ñ%
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_Fig_Shadow3.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/archgen_oldHartikArch.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/archgen_oldHartikArch.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/archgen_oldHartikArch.dia (revision 1676)
@@ -0,0 +1,12 @@
+‹í][oÛ6~ϯœWM)‰’ê&EÓuÐvšb¯m«¶6Y2d9—=췏ºD¶|IRGˆ¼ N,çˆä÷}<$Å·ïî‘v¤«0‰/Ä0ï.ÏÞNCþFüÎR¾ÐDx•¿»̳lùf8¼»»3¢‡ϒԈµ±
+†ÿò(âCQh8¸<Ó´mSžñüZu•gYŽ×Y Å|\ Æ|ò÷,MÖñtP–ªÊM’(Iµ[] ο?ƒaefØ°ó„í%_é®ÙÅ2Y…¢Hö°Ü+rÄNþºU¦*µ…âÙåù{û¼¼¥êÂÆÖ¡=ê$[ðtÆû~ҀGeCP㏭ðrch´ƒÚA¸ºY&i–ò0Ûw2N’(àqé'Kׁ¼ŸÕ„G*OU„<Ãzy¹†ôQz”—vøXø‹øCV7uµa¢v®ÂqTõÜ¢X2þ+˜dy®3Oy:Õ~Ò®’ûÁFǴN/¿›Mòí6ƒ0&Ú{µK¿eÆYÙ
+¶¾Õ›ÇZá˜éñx×r*îÇ³((­[†ïèD¼Œ˜a:ºe8Žœ·
+7“$÷µ¤ÊæïÂi6߯P +|Óó œÍ³ã¶‰!Ù.«yrws@ą́Ã"?Ü@P“D“ “NI¯ L2Ää+À$UŤŠI·Æ$1»¥‡ | ´ÔoK¶=ž?|[†-`YŒßù ìø-]Ÿç“@"“ž2mud2h\:…\¸$680YOaé(UPú:! zéÃ8)“À´€©R%Ë['S§£û€È´sdæð¹.MàSº6ÊA骂Ò%«AéwJAù
+@é©Ç–Ä_³´¶¢K¾l)[!œõ´‰L_].L¶ 0ýNâKãËW²¨nª˜Àà´7àt;§ƒà|%à$-Œé ~)Sø¨×2‰¾f$_%×åàù-¸ÏáSyû‡˜:q@ê–S¬dºc#ñ—ÙNî3+ç6ËcÇénvÎN™cZäÝ4Êí¤èü¦ÙZ€ç ŸÌÃ88’¯óDÇÏߓ8;ä7¿^ù¬ÓP0q¨âg?Jy¹‹&Àž27EZ×!GÛù^fñ£æˆGá,^‡û'ˆ×‹—µÚÁTXU°Ôã}HEpuÛ ‚ýöHø)ÿ{ýB€Ì—a~HÈzPÖ+ïmŠ¨NwgRŽGuVŒýöÈ3l⠏n?àS ãu@Fö …ZªŽzª"1a—T|¢ûa€aš~¾MB{1'¸þúª€”
+4@…*L=3TXCüžIÀÇ/(2à¡t'n Q…ÞZ"@H¹8XÅ´'kƒþE@2 8èL¼"
+½ý¿%~¿dàÃÕ5ʀd,€2Н ømìRè<ó-ÈSÍû$¿}ý†B »?ˆJЙPå”+BuP|Ãv™Îª¥bµu·/;…ŸÃqf¢HiAZ( B@Z `ç”Ùu¶± ×býIx¿\Fá„ÿ#ÚÅ@60À¨ +1 ê‰ØèR!õmVZà®Ét«/Rh@
+ùÊÿ²-ØÇù¤æ¿W, +ô†ÿ†a È%¢t%¶ús(,ÐÅÁíÀïY`!ÿeøï#ÿ;ã¿rÒ ñ@@˜dî ¿9pÒS™ßóY ̧°Ì'æSdþ‰3Ÿ"ó;b¾‹c>2Çüÿ!ó•³ ìt_˜¯™ï#óOœù8ÏïŽù­$z OÏóH™ñ3ÊSè-<öä»A¿ŠÖ¿ã)nùKçz(ÝHe¶6
+¨ˆ?*\õDû’QÀ6˜û ÜWOþc:…ü†°°_~T¸BîŸ2÷›`BîƒrŸªoõƒR¿êG>ÿÔwø‘÷ñÞja¹6Þ÷6ñ¾‡ñþɯ÷c¼ß:÷?‡qpˆû¶úc\è£"Y}|©+ýëIÇ7A<-îüÙõQ¨nîPÔE´öjOn?Ñæ¢òc‘É@˒²;´ÍÇy7 +wgÞ±Ú Z8mŒA5æÔgçtƒF}}ì¶û,ïcÃÔ;ƅî¶9ÊÕë¢gž$(1u¯›®q[Ø1ñ@¿0íçT©Oöé oš5:8Ÿiç”å/Ï'Ï_žý,ÁýGo‚
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/archgen_oldHartikArch.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_Fig_Shadow4.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_Fig_Shadow4.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_Fig_Shadow4.dia (revision 1676)
@@ -0,0 +1,10 @@
+‹í\Msâ8½çW¸œ++,ù{2ÉÔd®[µ‡;%°¼16%›Ìaû¶d'€m Xhk’QªBÀ¨º-ñúéu«Éç/OËÌzd¼L‹üÖÆȱ¿Ü]}NRú ~çœ.-—âÕ­½¨ªÕ§ñx³Ù ì¹¤UÁQ–®QÉÆÿÒ,£c4¶ï®,k×@B+*®5WiUñtº®˜•Ó%»µ§tö0çÅ:OìzT3nVd·ivk_ÿ?ö¸13Þ³sÄöŠ®o›]®Š2…!Õóª3ä€ñ¸3¦U |~wýÕ»®o©¹°µÕw£TKÊçiÞõÃÍê… ("/«p¾ƒ©n™n\·ƒ´œ¬
+^qšV]'Ó¢ÈÍk?_³á~ÊÍ*Ç&‚ß`½¾ü
+éƒáQ_jÅ£ô—Ñgƛ›ºßF¢õ˜–é4cÍ<wB¬˜þÃfU<W4O(O¬?¬ûâÉÞòˆc[irkÿåì_{À¬wÙ¿U‘æU½
+îï,Ä¡e8d{:m›æpó4Ÿgì-±?Â<Þ`‚xîÃã0‡,cËɬày—O.2!i“&Õ¢;©ÐÄ
+¦,/ªÃ¶½a¶ËE±™ôüé :ÇK½îN“t]žƒƒ‚öë‹5ÊëÂ>@EW#ðä"‘Ï=xÔ |•)½ú¾FèÃ
+ýà?œßÙSՃN¢ŠÎ£›."4‰ˆ7ÀΡ¬Š—ÃÜVb!ZNÛB°5æÐ*%ÞÞ¸–¼ÏŠÙK¬ï´|8  ¨…nyÕçT\o†|+Ö<…«øéÂ)ar¾‹}h†×2wèó²›T8òGͨ¸y¾dýË×Ëó–¬WÏiåW• "AëžÖÊì¯làáHìVïƒ +ÊMŠá!<І–a’ÕS% [v ‘€b™Ÿd%žÈՈ£9WS˜Ò[+vL¶ö+dk¾2ô%SE:ÁÉ|-”àwe¾kÎה&e¶KŠ´@ ‹Ï2Ö Ð¸–iQ-Ó£R¦ÅF¦}x™Ö—Ñi:É ¼Ìnê$yíԐA¾‹ÝëUpà™)á æ„Æ '\„¾òY%Dʔ€õÖpbńD¢Šƒý ‡HHK…q<4Èó Ë9‡3f֟ã +¹³5d“$-aª3vLŒz‘ïM$ódB9/6mû[\ºŠ–'Ëçǔºƒ"U'r7{<` à_vvƒ—w¬ċ8»Æ¶U²¶amßíY¯ŽÑ‹De¬•±fÍ"Œe b™U:˜ü +ý0Ô–qK1vD%܉£7,!E #›°Tñp™ãrçÅG¢¿öØT_è¯<Ó%òÑ»D”ÛD€Áý‘§w‹ðü‘+ODÙÑ×]uT˜‘):^²Î€‰z¡aäê­2ˆ>‘º/Ä»!Xö‰ÔçĞéùŠ »ø2­làªg3Àì¾Þ½JAx[>Gþ{ás¡À-l.Ð)[•[E¤’$ƒS¨7vöƒ ÑÛ@²†uJVÅ٘„íý$l¾z_¿é^ä#OàÃÖèmèWš‹ÉÖ.ªÏ‚ |åDdúšI9•-ä:B¡a‘Hdlò¥ÉØ>¾NëÁ˜‘jZi!TïïwDÕO°+·šb"o{'¬`ò6•ÿ¸ \FÀ²Ÿ‘?Ӝõ±‚zÈ£µ”#,¤¥è‰+¿¨ +ô7e?'§£ýêAÏqœŽçñ‰1dð÷&Íq³†(PnÐ DoA¿†!²eÊÕûóé}ÿhÓö¾áÝ®‰€ÿ»Êmú œý>(ïì>¨úµüŸ!wW{ÿTäîê?Âô5JH
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_Fig_Shadow4.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_Power_Dynamic.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_Power_Dynamic.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_Power_Dynamic.dia (revision 1676)
@@ -0,0 +1,15 @@
+‹í\]sÚ8}ϯð8¯DøS¶›Bg³Ý}êìÎl²ÏŒÔ™‘EHúÐß¾ò566Û¢eḠ‰Íõ½–|Îѕ®àý‡—U¨=c“ˆŽtú‡ñÍû9AïÄ߂¡•& hœô%çëwÃáv»ákŒxÄ@H6 ÆÃï( ÑP +õñ¦í;˜#Ž’sùYÄ9#Ó +ÇE+<Ò§höuÁ¢ +ë™Un7‹ÂˆiÏ(鷟ӗ>ÌÝ K~Žø^£5fU·«uaÂ_×& +~’÷=›Ü*Ft1¾ý͹Ín)?Qøª»ÑÆ |…Ø‚ÐÃ8 £0ë øÖ®Î0• ”€É@âÉ:bœ!ƒL£(Ĉfq8Ûàöqâ
+TŽ5Ä|ƒ÷ìôH7Ò#;Uác/D¯˜å7õP0Q{&1™†8oçÅ¢é<ã9y9¢sÄæڝö½è…ŽºFæ#ýo£L¾j7g¢¿ã*ýÖ¡<ëw°÷4›z¡ÉõtZõÌĽ#ºqæ݁;0ÅÛ½ÃØÀuۅÃ!^Mf£‡bÒGkR÷[2çËÃýŒÓÁ÷“Å’qZvL¼Œ¶“?Í©z™ lJ³;*í¶ýñv\ÚÀÙáÒorqÙº=
+™}"ÓêŽLé¸t
+½„ÒõR¡ò@¥Ý•P¾^ÂB/}éz •^^™Oø…×@Óé
+Mk`Kæ,ËXÀr!tîôÈΎڅåI?T‚Vç´›¦ç™ÎVKv•‰í'üŒCÍh˜Ý™ó4DüQ^/9Ÿ›ümÜv‰s@SÓ«óC”AuXmB¤ uAöWFŒôÕ-˜Š.è
+×?L7«óz¬vR*UÜ®"`úRÓ&áÞÉ ‰t-ôW¼oÃû2–ñev%¾d/0%ëK»ÁßÝ%ŠûÿOîWà¤È/“ü^çQß@‰Ü÷@ÍÝhoB`؁˜7^‰üQíÁœ»'²ÂJ +Ze%|)1)~b`Ë]¡²‹u€d•
+׳ðb!Á1×>b4 Åڟ„Å\ÉBKYP+’… Yp¤.]Cà8P(— ƒ\×!½ë†Ú–ð¥öo¬4˜®Ò„–šP‚™R™åÿv¥ø²«Y^Qe +¤WY}UËújY¦ÙÃhH«<'ø»$Öÿ˜W’Ä>=TÆ*5Tµª5P]&}5­Á“œ¿&š‹ü5ÑïZòת&ØJZj‚§Ò×þÓWüMà㡸N:ïÊ2ƒ´,-µð-f„Éë{Ë~²ÕlmŠ¿MÒ;?«=5›2Ì·˜XB¾Ž™ˆ@e“³[:Ÿ Æ¢mµ%ô쎞'!¦‹cI¹ü®!N¤ýoŽ0‹( Ў4÷‰¶”H¾Œ °Ï£t·V|*&L«æZ;¿Öh¼vÇäÊ +õJZ§Òz#­ ìd3¥dÒz§iŸ6ɊëÇikFŠ¸—%®ýSÉçö@>¿5~Î%LFÌ@¹äóO‘Æ>mOSÏRÄû¹#¦ìa¯i »oЖ[€É·hï*0Ùí«)Àd[´ÕRVË-Úªèr¹µ,¯»@ù:à–¾ª¯ë«–ҁv: öi]Jüî*à]"€¥|À»®|@-c·ÔµŠ}9%º+A _üR>\W>à(h§ªÂ}¶
+dÇéï oJ?84¾ù…DYfL
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_Power_Dynamic.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/schedmodules_eligible.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/schedmodules_eligible.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/schedmodules_eligible.dia (revision 1676)
@@ -0,0 +1,5 @@
+‹í[M£8½÷¯@ôeWJC`:Éhzö¸Òfî‘îÄÓ"ãtº/ûÛ×:á;Á¤!$Sð(S¯\E•3ûü¶õ¥WL#s(šüyq7óZS´•¸0ˆ>ñÑ\Þ0¶û¤ª‡ÃAñß#ÄBªød¯DXýù>RùEª¼¸“¤›=ÄP<ægc”¬ö KÚâ¹¼Bî˚†ûÀ“WðkÜЩôŠü¹|ÿœüd5½]=Ý_ƒ·C;L³PÛ].fﻒ¸âþø˜‘ó+"~A°^܁÷35œï/*T ʶˆ®IÇ¥ùÇIꊭÌðzÐU ~ ´P-w!e–^…¡QpÄftÛcG.ò¹™ëíŸ caƒžÏȏ.):SOl®ô†™Zp·™Þ1M5x:;šôJ"²òqúzR°põ»,õ“ï ¢žô ýK,Ÿ×M–ˆ7—¿ig'+N–#qÛDY7ۅ$`©¹'Öy¢UÓ¬‚[­²h”+Š‚µS{(Ž91ùáQ×͜XüÐînKx‰šW)^µžT°ßº»ìƒNX h¦­$f2 n2 õa3çl3 õe´¬ê%«µ×ï0›~ƒÙ`fFÆn°7»Á&»ÁáÛ͵ì|…4`Nt~x„Š/v6ƒõ $œ¿Â`@\é%¢4<dÁ0‡Oߌ ÚÒÇÁšmòïü#AÐ[ö@<1ÔÛ¸
+E¹ju̘¬VL֘§qd腭VCd°&ӑ®¦«)JW³ûcºr’r¾š _a?|5""—‘°&¬%JX`·œ—s¸é)vé@^õ’Ì ;`ÂN… ÛÆÎ˄5NA²¸ö–äu/É~ÍÇâHYAÊÚÂßÉZëðy™³Î9-е>ó‚‚öe!Y;Ö>…o¤uċfçEǜÀ¸´L±2*öñvé†4È÷XnÑ:l0M[ÇMð6˜¬7¬°^´áÔ©hb57"D9ô…ºUu]í†`m÷¬u=^÷ìÞbµÝP l9-wO_ñÒ#ŸŠ‹«™ñ0®}4%Ä»z癦
+äí+ÓÌëþ›Ú#gÅb6îÈÄ)açŸó0éÉèIà¶{2—#·€ê—b·ñ'…î*7†œî CN¯ãælÊ^A¤ÖŠ<Êðè~cUDîà€Î?$4ÅáV†ŠnZ|ԓ‘yµ{‹'›yPq;WA^eœdÃVîšÌž®(z‘Hž®š}=U;{€áãs©øk¸§„û‚*‚]"iÓF¤ëaó\häCØdÛ^8»—OK~bàÈ'ë`‹Ëïúœœ\ó6J{¨ºwDSÜ»^ÐtejX|E?:"LFÎ`ñ§ô×קïîXˊÑ[»£xç­ûT= +Œ<W]0 +ŒÀHFôǗÑë 1ºbëJÏôWìºL©%í3é)&…ž¾Ê”9ÕK²± >èÚ¤pK­m{ùó\ÏpÖ蕴yíËB{¤íh[—ó87ìæìz¡å¹Ž'`zLyœäØCMy¸ÝW{L|êY1&>mýQ×n(òvî<€À©uòH]SLÓ%ÿÁÈóyhݱº?ÎÔäoŽ‹»Óÿwÿ6[¦Ì<
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/schedmodules_eligible.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/example_EDF_status.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/example_EDF_status.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/example_EDF_status.dia (revision 1676)
@@ -0,0 +1,21 @@
+‹í][oÛF~ϯ”—. Œæ~©biã`¤hÑ&Øˋ@Q´Ì-E
+$eÇ/ûÛ;CҖ%S
+‡[­H‰-xxÈ9ß7ç6ÔÛ¾.£ÁufaŸ +€ÃAûÉ<ŒgÃ/Ÿ?¼‘ÃÎ_½‡Þ÷úß"õ–}Dœ™Wgë<_}?ßÜ܀è6óò$Q¸Y0þ¿EÞXh<<xôÜ˽ò +/ÏÓp¶ÎƒAì-ƒ³áÌóÿX¤É:žWGøI”¤ƒk/:¾¾,~†ãó·ã­cëE­¼UÞKY®’,Ôcùíjgl÷8ó5”é‘xqþú}]ž²z£Ñùó¥—.¸•^T^7½†™‘©a6]%ižza^ə%Ixq)*O×ASQ™ïEz©ƒš
+¸ ó<©Óâҋ²Z5Æ[fÔì,‹4œï1ÀC»G݄óüjúµýŕnÛ ¸³p÷:„qÞRÂm# ­îí:œÙ¾»ûpp÷È«jt¼GõÍð·ô×RZäÝi%ìÇ + +ª{RYzùÙdö¿ÀÏ+­¿üüiðfð% |OÛà†5‡ó³á/pÏi!Yw—»Jîo¶F'q šÎš4›ÝۍŸ{ñ"
+¶eM8@#Ù\fË©Ÿ¤ñ=ß>AÁBXaޏŒ›Ì¬Ä\áâ*ÌhM…äÁ×|š¬óL[‹“Ô Ó«\ä͒ÔËõŒ?YšQm2 ="ÕbmÛYù>üvqÑbí»Lâ»Ó˜?—Þ2Œnφ^zÑpå·ڰˏÿ3ˆ®ƒ<ô½¦W¸gò ½ƒ:ÀP@Ó֍˜ÅÄ%i«‹Ÿ¦Rôj¶ˆ—Áý= âõò |9ÞPK šA¶4£/PÌ\ð̽° "€™ÉPÌ ×XkylTÏ5ιæ÷O¿v‡l\›7î0Õ`[ª!Ðp‚Ð ×l¤Mr¤,ää{5{Ïæ¥Ùæâßrl¨ðlH‡Ù†Ø² +R€²vA5•¨ ¦&ä¡NXÆR½ÃíÆ=üÿ0ý×»Ÿ»C3XÓ Ù,X'H3´Í@wÔFÚ³2WÃ9®: ¢¸­{´uDØîùíâÝûÿtŠ|`áã`(I—ýւ€ÈH‡£Âÿ”ÂŒ¯ÃGˆgÜc§äA‡ôþγpÎÇ÷Ÿ:Va¤— âߐo~×ðž{é\“λԯ!nK8¦†$ÜÔ¥´AÑÒ¨R\La“W r‹ÜZOƒx^èxXẴ²°1€uzLça¦¯Â™äˆÐWÔ<¬‹çS/M“›G¦@¬EL£ ^Ôð¥N6²ê©÷€(3 zrµie»o ®´ V'E-t°=Ò»™©9U‡ íCȃ
+ïƒó>
+Âzí%eªÐ‘óO ”–GDr¢M.à ©+4lë\#˜A/웠`Œ(AzP²} PHëÆVò­ l^`f•À,¨†€#B5,$ƒ‚¸ÂŮڵUiö6€…Rˆª‡`Aía_ʺúUfñ•£ò—ŽÏ0Âdˆ$Ál¢ÅcŠ„ Ù(ÅÎV‹­w1S‰¸yX÷mLp!±B=&abÇÀyL°9Ç‚-A!܁‚"…F:¦£“&¾@HØDy0!öbB²‘+ç D„d=,ð€à¼P»¢¥· iÓQL,,¹‰&ÆÅáR gÑÄFáºî.¶†ZÖ`…CP 5¾]hž
+ÖÝBˆ֖#ā¤n" ¢Mˆëõ@Œ¥s
+YžB!â,’¨Ñ|O«ªrå7!}õËÄáe‚ÙƒÖ¸ZOÇg“•¯A‡uw‹Ò™×Ä +…s ƒe:`G¨?øzºóÀaõÁOÖihör7k?•ƒO¬@ 'Õl§ðï]|Øgùö +E:߉‡D1v?A˜¬+=†Ý{šC®;fùvSxšvo]çǘ ÓQFUŒ?Áª,Åôµ;³òrÿªK¦o9‹§iûÖ%gŠ€£¨¸„µå—"cø]2x»©;M{·®+dh™ä„í5ÇãÂèÅfQý Ãúu´çßúQ0z•­’Ô›‡~—ð`=µ§ ûª²0ýƒ®
+Êx„ `,u fڏ‰ƒn¹?V³xš¶¯Úì1ÀX6ë¦ÓˆF…Ù3©ŒU&]‰Ž‚ïL5HÃdþNEÀmfô»O1l·‹Xºª3 ç¦DÌ/z‹ ”¦åå¬u[gýR +ú(¨TªïCµ©û–;ú<õŒÚe‡àîòCÚ7ªòCš¥àQ<¤U%‹uн‘ÅDž¤„íËÅT{1zEՑ• ³3Q{E>1b.ŒpÞ;I/ç$µ˜Ò“ô‘ìŸ}P>ÆѶ!f‚”D\1\ô}
+ꬫnKçÚíƒîúL‘¶(Ø·YmHhÑeJžÉ;¢-öéPc?Òˆ^¢õ/%ˆ4MD”! +
+Èqªw%äÑ«äò2 òN­¶3{Šâb­{ëNj [MF‰¯ÂÕÓ+Ú¨|ðØÑó+xÿüŠš½äÿýåç?vh79’W6év†[ø%@KjZf©“ðJ#Ðü1AfËà]£oÀ½ÔâÜjVO2‚³î¨Náè±.ZǼ á ŒÍÂLËÒ'v–æÞVzß~¬žhÕà „0҇rC9f¿AŠºm|߃ yì]´ú#X—i±Šk\¼Ô.Ú;wÙn§Ë· ¡ñ)ì‘áz+-f/S²o€pV¸<B¸IýU©^.›Ü½äaÑ7N>sf£Õlžd<Aì¿<ŸÅÍCŽ  %bU$ù °¼ .ð±zÇ:Um5},Œï¿rhûûˆÎ_ý Е‚qÖm
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/example_EDF_status.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/resmodel_Gerarchia.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/resmodel_Gerarchia.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/resmodel_Gerarchia.dia (revision 1676)
@@ -0,0 +1,8 @@
+‹í\[oâ8~﯈ҷ›à)íΌV#uÔÑìÌsd‚ Þ:qd;mهýíëÍ +r!¥tŒÔH„ãóù8çæÓã¼ÿðäí1Ž©?сÑ×?\Ÿ½ŸaøNþÍô4IàóèÛD_¼3ÍÇÇGƒ,9”‡GæhJ"S¿>Ó´ç fPÀè^r
+Áð4Hó¡‡&úº÷sFC¦ÇT K eÚ$ýünõÑ̈́™â³ƒwIJl½€r,IÄ2ȑ”ð‰®Ïh*.‰üùõùÃóxJɍ-¯¢‰–‚²9öó8 A/„eŒ­õ*Ô˜v +@º`]`î” ±ÈƒL)%ú1Ž`!jŽÃ]H¤ªì4ç~‡… {æ ¯"@|{c5u-pÎðl·¦(J¸<â™X8O-WÌ}Ù÷Ìñ” ¢Ùc_Œý²%û¶Ï9Ä3Ä÷<é4M §EBfî<KWU‚øV&8­ \"–°ÿs–´d£¶
+túrE"Þϯ7ÚïÚG9×·µ¯kx6ÑoûéµÉJ#9Iϓ[œ€nbdeÍ?Ä2ÖÓi–3“‡þœ ˜{߸õ¢Ë¸0öÀî kÔ ä9.e~>°Bžû•ÍæeÚØ«m ÀÀn°@x¾åCÃjÆ=“K¤2 †8 +™‹©Ø…9E .C4ÒÍb¸F³‡S9º¹…ÙkÍ9 ¹ÜÙüÀw"e¢X#(*@(¤±vµöÑ…j¾|k Š"5º£ ÅÞÑYåéY˜çÉ{õi†³ÝìÇIojªué“ɱÐ#â|ÈÝ»qÈ|Ä´d÷°#(ÛA¤m=‡&}ïÁ°äš‡;ÀÌV¼#5Æ‹eòC/ Zz+˜_V1W®åFiÃ]Zü„Ã&=5óƒRgQ ûâè>âŽô"8ŠS/doJ+³;Ð×£”¥Õ™p#ù´yZ²mdè«+\Né‚RMÛ#QË¡~ûòéà¸Ex—º7ŹÇþ¬ ¦Té÷‚•ø­×v}øþùoçëí§Ï7J+ªjEÝøb!l†t*€©¦˜rU]'ëyÜ€¢®Jkþ<ý϶¸ÐÙ¬ò ZW> +0êå¥Ãú§Äˆ ®¬1v4.ïU,~¶©J Ô² tYµ_ÿô$ٓ£ª ª
+ªª Ç­‚š¯²d„},N³ZªRïÓO½½£¤ÞqLÚo*•$x­p¥ïÚJ7¢áJ?N¾–$“]ÁèR…7ÞTxSîëÔÜ¡î½ò]Êw)ߥ|שù.Á–Ê})÷¥Ü—r_§è¾B_y/彔÷RÞK5&ÔiL°Ú6&؆ÕÆ°ËÆ;êˆ@¢Ö„!°zV߸ì²5¡¥P•Ng]À¶:lM+uøæ„oßoÜ~¼½qÞT—Â!zT›‚jSøk ?ȤEg†_,ÛV¶Ô­WÒ}³Öÿ-¾êzSº¹iþ*{†¿Ì’!Áÿƶ“ß< Ún.ebo£×,t¸{ƒ~ r,cÔ·é£fbᬨ+V)ÕÅ.9áá¨MK¡(ÃÈÏ¥É[×rS(qåã³ 1¶·p©ïKՊœ~.æ¬ÑПE¯I‘6"èê'Úö×TÃxùXŒé± ÿž—Ì„hÛÃÖ'bµÎ-Ãî'0Wò:€VõˆJ^,[9½ÛH>cP™¬¥tÊÒ»±tÐÂÒ­¶–_½¼éú,õv§ë³ÿ¸8tàP
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/resmodel_Gerarchia.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_GuestCalls.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_GuestCalls.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_GuestCalls.dia (revision 1676)
@@ -0,0 +1,20 @@
+‹í]ßsÚ8~Ï_ÁW×XþíÒ¤síCînz3í;#@%¾›±MÒôáþö“d§€ÁJ^7ÐÍL˜ØÑh‘ùôiWúvyóöÛ2ܳ¼ˆ³ôfHLkøööêÍ<¦¯ùï"§ËoâêfxW–«×£ÑÃÙ<´Ìr3‰×fÁFÿÑ$¡#Þh4¼½ ¶;˜Ó’Š{õ]Z–y<]—lÒ%»Néìë"ÏÖé|XµªÛͲ$Ë÷4¹^‘?ÃQÝÍh§Ÿgú^Ñ˛Ý.WYó&åãj¯IK?âu«MݪàÒÅíõîuõ–꛾½ÑV#å’æ‹8Ý·“3šTÂ6Cûé)ü¼)´Ú@m .&«,/s—ûF¦Y–0šVvÊ|ÍÔí3šp¨<7rBïÕínÕ­Æ|”öúÈòúM½ÛÌÄÁ}\ÄӄÕãܚbÙô_6+ëÉó©¤éœæóÁ«Á»ìÛpÃ#ÖpÏo†­ÝÉ×| ¼3þ¼‹æô[eqZ>}œžA¼Í£h{m½O§ÍÎsþöiºHؓ—[pÍÈÇô<Ãæ¨h%l9™eyºÏ( +IZxˆçåÝþ°~‡hô}ÇâÅ]ÙÞ¹¯Öwq—=L0ýñ™u˜ìG(*c“èb“FdBb“ø–܆ëK`“DÀØÔÒIØt´z?†Nå÷þñikã“?Åħ€¦áîtk>)(<5Ftu‚ÂÓ¾$x:ÚK»XCÈ¥]®íÁžÄƧΐNÁgø[À³-ºˆS6)ÊDŽ5 +°t½¬zwû@¾«‹|Ÿ;œ€¸÷„×@$-Oâš—Õt
+ê#Ä|˜ÿ̾•@ïiÓ½gx Þ2Ü<?0\3ð|ßÛ¡é:·)/Õì–âY4¬67mÚà"·†vÚ5w‘V«$žÑ’?õ–í¤g6Z¬~ÉÒòMq¿nò>[ç1ŸÜ#;{³ìØ~ÆϛØ×)S±"7ÙÙލ´äž!šÄ‹tÉ<›¹}êC;¸Ê¾6øFëü…švE‘Iáÿ‰Ë—Ï_oãÙÕ?y¼ŒËøžH J”°ƒ1$HB´ Á…u‹¹‘pŒ Œmß´mbpù¼8áOƝñù@‰v!†„I¡öþ¥%OJ@ƒ†Àtqü#‚qä;ÂbpŒð™_ïi’ w Äð…ŒÉ‘.#ð©
+¹a숐•ÀÑ!B†èL܃O³;6_ QÁÕßÿƒ!'¨pÂ. é€h«C|Aà1ƒ4P •±3¡œý*³¿‰'œÿÌÿ¿â”šÿÚ
+[è€OBÓ÷ —¿ +Ž#ä8¡¢½Y–¦–Îå~nX-mTOÆÒù„æyöÐ~¨ähö<IXºxîPÏ2C]GŽ +[èÆv'0Žz€q¸1_՜^p€c¢| ‹PîÊÚ¢ê"ªÓDgŽI¤”‡C™„œŒENÉ{ã:ÐÄU—õ"Š»D±¶@G|ÔñQI{üuÌÉOðq؈›Ã:´'¦¼Å‚ î48Ö܄FëSðî£Àð·7–Ãmž‰à†`Œ¬t†Ö€ÆÈ 4 ¯³ éèèÂâLÀ2yŽÆ/#ÎÜèy¤ÙÈjL°‡,$P2ÐÖØ¡Ô† +Ï<éð(­:R÷¥SPŸ°¿|*p
+”ŽÒ›¸B"%‚°›6>à6¤Wà×T@*¯ 8*p‘
+”¨`YHiìÚªbØ +X2-éh"}ÝI’°YÂÊã9)³Ñ~}6š­-‘…>@W?™f×!q•ŒfŸKDüa͊µ¥ê«`^¸‚Òé¢Î0!HO;d•¹µd—»;f"ôÊv. +Y–AÀA*I¥Œ:ҋ^ýmœ÷½„¿¶ÓÅÒ^ap«À é£À ÖüõõÛ:¨^&h«J|‘ ¬tá»2^')¿=dü> ª2~ϦFfüvñ‹ ¿ýÅdÚꥸF¤/Ø ¨«[°A•ñëbÊïoB
+ +ˆ!#€2BÐEÎ/tʯS‚´u.t€³_5å3~{ګї-\ª°Q*x¥A¥Â…Çđþ±éC©@v”
+•
+¿ÍYJøûón¾ ^©@¶”
+•
+—®T@è‘H.¬RüP*T*\øêJ…Σ_ö££¥:…£­Sr_CnŠ¿ª*RÈ+®fqŠ)û>9Z˜¢9¢ý֑ÿ¿"U¥¾ç+´h¹NXߢÓEP[·cA5¨U¥¯UÀc«Ê^;—rñ®‡*ëaT¸"BVjr´%RòK]`ca"¤QÄ{r%$ðeóšcÚoár”¸Š½€UL[ñ䪗ñ< ¿®\оɕ‹ØÙ(|\ÄT±¦p +;ªë„>²üöªºà¿‹œ.o¯þ(ÍG0(ƒ
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_GuestCalls.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_QOSMapper.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_QOSMapper.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_QOSMapper.dia (revision 1676)
@@ -0,0 +1,17 @@
+‹í]ßoÛ6~÷_!¸/ Ñ"©_nší Ö[önÈ6kk•%ƒ’ë¤ûÛGRJK–툺¤^ ¤Ð<‘º»ïãñŽ~óöf•X_Ïã,½bä ß^ +ÞÌãèµø]ðhe‰i.¯.‡Ë¢X¿¶Û-Jnó¨È8Jâ +ÊÙèß(I¢‘h4^ +,ëaó¨ˆä½ênT<žn
+f¥ÑŠ]§Ñìó‚g›t>,[UífY’qëK”\_}R?ÃQÕÍh§Ÿ}¯£5ãõnWë,E“âvÝhÒҏüû MÕ*ÒÅÕ«wî«ò‘ª÷}í{ÐV!Å*â‹8mÊá,Jʉ ($w³ðxSh ´- Î'ëŒ<Š‹¦i–%,JK9ß°îròY”U94|Bïåío*Ýj孚=*yItËxõPïï-Ñúçñ4aÕ8˜X6ý‡ÍŠÊx®‹(G|nýd½Ïn†÷~ÄZñürøÑÙ5¾ú4ˆÎÄ|çuó[gqZT¯“ ÏÆòîg£m.ÚL§õþ¹A”.öM†«„¸Þ…+< gŠ¼ŽYÂV“YÆÓ¦WéoXJÈ6žËæоéO¨Õû’Å‹eq {Ú­ó|™m'{|þq{Œa\l’· « `éfUöîvëº|·ÍãM~`~9Òy³´§Î†µ +ÌƠƅÑXhº4-¡ží
+ó5¬îÃ9Ũ|P›"]{ïÙ¨©™³›bj]Õôl
+éõ‘ø6AÄó}÷"@qmZ^u“ZÈi¨É¬³ÍZ›¶×©xäN»åüƒm­"Ê?·Ït¤Eä§,-ö ”÷«&?g ãéÈi˜À1æóx»JuT±ºˆPk“}B.Zõ£'H°ÄEºbûßÍ=”:c{ùb?Nàw¸{œÕvÂ$mиHÚ=–ø*Nz]‰AšNX:Wÿ˜!5[„â9:âL:ŸDœgÛvރ5{ž$,]I1…º"ŽÀðÉä;¯[¨dÞðÌwÿ±–B‰åRGèl‘)NeÝÿW`~]T£Ó^˜œ«Íä\¹¦€esB†«„>G‰$tœÑé +ëV¾N§·šqÿ$œÑÓ6‚Pj (oô +l\Ç Š‘O…@uõýóÆ??^[¢õšqû0džzöÜðûñ¤7 úh,QE8dhuuRäÐÄCïãt5”Rù2CXÒ6˱¤P  +@¡Kl‚Õå÷Y×k6‹?ųÁ»d‘ñ¸X®?\ϖl¾‘[(öà/– |™1ÛBýhp­ ®íQCƒl€Èêú +¹w¹w´É¥žp|ì^oL&|ß/´µUTú
+« ã!|AÂÃ)ˆU×.Wa|ìôà +Ø@¾p¾W†ò±‹ü' å7Fµ§ V©&œÿ\áü8œß‚ŸX;5õ}àԌ ۞Zº>" ‰Áy ç‡lÎ ðìž5Í2Ø I¤±v" ö„ûA›8+:?o@Œ7èD¥êeB?±öUhH¥¦ýìn@RjHJ§¦.¢rß¡3©ž²¯“£„º1¦¶&Þ®¾6š*ÁÚ=҈ê줧æÔPóÃÔÜm¥æퟥÕgýÝÏ⧢õúy:AM{!
+h™šÜå(”›”ç±áó[Z0žFÉà—¨ˆ¬ë‚ofņ³Ü {§”… á, +¸²}í&ژzê©ÌwŒË &×Q©ïUBÓYPýŠáúÝ6zw•ËøÈÚ,_?ù½{èø$_àÉ-Þ±L^’\YQ}Øä%²Ã;Üߥ]IÛ4ãsƏSml2…OÇÙ@?…:[ÞGÄwå>”¢ár¯ˆúhσ†ÿÊÄûŽgƒ2¶f²†5luM3° »a5ÑxI´J&ŽD]êÀWEæ¤sҀ–Yõ÷³q¹®Uf(2KÔ)0™í> S•vN\“hg?‰U÷”jº( dwÉ41ÂTJ LQÚ  —uå2ì Ö÷„‚ú R†LÜŽù¥ÎLEZ¿X¥ŸmDm©ž!ò=¡0n¹ý •Õhá™l?˜j´§ÈíßÑ@ƒgðÙH„ök0¬aO2ߓ¡ÔГ.„Bæ"ÕG´·9˜û/Ël6 :Èi2ôÏúk¤ ü<9HD;ÉGގêÄ8CyB•c ¤®â¤Äd ½88¯+›ÁsЀv’ äàgR`WÕîޝI!€VÖîV¬³IB2åGÝø}`N›xŽï÷‘2»òTÁQ$Ÿ¨‚ƒ¶à 1¤¶
+ރM$Äaÿȑž¡©~6šïkÐüú¡wšØjõª4àBa¹2¶w!OHT °†»gT{Z…öø°u|ÔvË#HIç 4Ü¿»±àZ}ªuºv&’¿ƒ;)ò\…âCuöΧÀÔüv^“׍a߀+rý£´Æ
+ë á;PõÿØ)]<Rú|V¾À,Ç»-ÇëÚeÜÁiî ¼V_¡v5ØùŽµ«Á÷ºPYq
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_QOSMapper.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_Fig_Idea1.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_Fig_Idea1.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_Fig_Idea1.dia (revision 1676)
@@ -0,0 +1,5 @@
+‹íš[s›8Çßó)òêâN[»³Ý×ÎìÃöFµÙ•%ã¤ýì—˜p³c°h³K2a¡œƒ¤ßÿHGâã§ÇVKJ–*Ð õÓêîcœÀ÷âoÃàNHšÝ-Õ-çû÷º~<5ü”BN™†“ƒ–"ýÄꢒ®®î奁r˜••¥s–DŽwh©Fpýï†Ñ‰Õ¢VYoM1eÊÄKõþ[þ£ê¥½fçŒí=Ü#Ö4»ÛÓ4UøÓ¾U¥ÇNv}Q§¬•ŠJd³ºÿþ/^©,¨lu½h¯¾ƒl“¶† .:ÂÔ|ó¹®wÉv€e;`²$i¸§Œ3˜ð¶“ˆRŒ )üpv@Ãý¤kˆ*ç^a½(>!Ý+¢¨¡Ç܆Oˆ•/õ¹R¢ò¤I„QÙΣÑ?hÍKñüÍ!‰!‹•wÊgú¨VqÄP•$^ªuñ5»Aý6å·§ áE/X ·ê‡¾^è3EMËL¼;$Œža œ…#.Íp¾¸ ó†0څkÊH;–Ü¢1¹ùcóm»A'ðG˜Þ¢d³å7·Ñaț¶_F÷ÈÉ~‡¹H·ôvL!—%Û=‹èメc¡w¤BoŸ ÷¦€ÞùŸAÿ;iŽ%ғJ¤{"2˜‚Ho&ò—i%2J¤"€) f$9’öX$Ê$0*(­) ޞ™Ê›Q錦Rn
+ª
+L’Dk¦rB*¿¢Gށ¥;K{áI¤ÒÒÌÀ^¸šé¸®ýÁÖ<Ã]xÅÝ0¯<ë†V[ßJlÔéÎ|“°V¯±Ÿøöì'žÙeêqöÞå*+/«üI,ŠÓÇøi¡iCëzuœ."5ÄEs§¢s·ÂÈÆ9‚8ِêD»ëz¬sPªü½Ñ³’\ýƒzo-DsÀn¾$u„ü
+À—ºŽ<pÄìï; ‘Æû—¥kJHˆHœ¿ú«Ôõ€«K‡1zl:¯8±FZ1"›s cCóǺ¸°ô~µ‡l@Ä` ÓV<~~¢l¿Ùù•À•Óü$J©ž.ÕV
+Ñ2zmö†¾‹Ú£•àÓ¥+[,Ù%›)…ZÜÁb‰Ð÷ð¢Pê­éxn.ìsÏÝó÷Õ¬³ñ:sê:­êø_«[£àÖíYÌcü0¤žØ9·ÊŬ£Ù†%æ·¿ÿZ֜—²C–²u¤æ¥¬ÌlŒ>±7åf³¹þŸ“Y3×ÿ›ÉeÁ¬ÿ!ú7çLv2ù›ã£m©‡Ñ™ü­RþA.û­Èߚå?DþA=řå/o# ŒþÈý`T_ì™FvÄê>b}õ^V½Iӓ1´ÉXŒB˜ò'Œú³lsºÕ¼u’ÙG™}Ê|é”yeþ$”ù(óÿ”yWSVÜçŸç¯îjßï¯î~õæõµ3
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_Fig_Idea1.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/posix_filtro.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/posix_filtro.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/posix_filtro.dia (revision 1676)
@@ -0,0 +1,11 @@
+‹í\]oâ8}çWDôq™;ßÓiG3#íj´#u¤îþ!C\ðnpcJ;ûÛ×I @ |8qT‘š’Ⱥ7×9çøÚ¾äÓç—il<c–’„Þuiu?ßw>E}c†¦†h@Óìì®;á|ö±ß_,füš"ž03&s3ÅýÿP£¾hÔïÞw cÓ@„8Ê®-¯"ÎÎ96(šâ»îþ³dN£nÑjÙn”Ä 3žQ|×½yÊ?ÝþÒLËÎÛ34ìlv:KR"šð×ÙN“
+;Ùq£Í²U*ÑñýÍ禸¥å…µ­}7Zé„Oºë‡aÍ®zá|CÕbÕ˜j$ÌÆ"|×É0IbŒhᇳ9–÷“ŽP, r(p‚õâò¤+éQ\*ñ1÷£W̖7õuÍD㙤dãeœK†ÿà_’ç‘#!Œ¯ÉKw­#V× Ñ]÷ÁÚ&_¹„1Ñßi™~³„P^ô‚m÷¬uGTuC•íá°lš‰›Gtã¥yh†nïƒeZî­ű<Óuå<âO£„Ñ]Ai$¢Üþ‚D|²Õ
+5a +ÓLÆ^m;ë9óÄE˜»wËræÓI²ìGŽóö/œ0‘yz(
+ïˆýâbA$ifºÌ¦«”ZÀtVÌPpJ=³jDt
+µx—Üjü€Ö'=_!6¡•É¾'·ÐËUßUŒMù€N¦«™ýw#úv]^…=`+äUÑ
+d9Õ-ðsÍWÍ+ù€Ná•4öOb¼&Éw€¦¥šá2¡zdZ™ï™n}dúªé­*Ç¥¯aù`éՇ¥£–ö–žrX:–­Âò/üÂ÷àÒ¯‹K‘òõ\Ù.9múf†¾×sLßõ<ç60-èô‚âLÎ+Ϻ¢ä³¼QPjSõHó-€­v¥Ý‚?±`BÜù >QÒù­óðhü Ê=„+Ë·ð”P¾ï²ëË&ߒ9#‚Žý:~vhqlû|Û@; l2nò­¦}Ž6÷ ¬üSϊɘNñþçƒé|z^¯í]þW*AíUG[¹:kK€—ëƒ{)úðˆ§è)aD끌ìâK ‚JAë B/P(b6åù=߄+-pl[L±àehÁOF„ð×Îw:قl„µ.ÈéÂ&Ì´&¨Ô`5’%È“$ˆ™¬’óÓ †o˜d…$Z¤“´.´¤  d8J³è °ßDÁ·½lë2Dáq4ÁÑ<ÎÊ2qç§ðð¢eA2WØD™…FDá¡xŸ(Ô®±-ŕLÂÁ[)SæLŒ¾ø.[P@éÓ(àœ°*ZÉÝ‘5àAÊ_c\¾‡½¨Q9,Ô®j°}Ñ*g‘¶múb`XM#`B10\Ì4òËl“ú%º] ßÿÖƒÌÀPƙ”ê‚ÓÈÈT
+çgãAž1
+m‘=„’1~§³'4¤u¡†.”q¦…A©0Ô®èÅÄ_í&µ0Àl…)Ûxº…®é€ sê_„4üNbέ2z°^Z”N"½~g¦teIиÙÊp³,!ßqT=‡,¯dì Փû” ¤lIˆ±d!?5=fyc:>ü»„ ®‹£¿|š_W‘Ão‚Š˂–é½Ñšvô(©ô>‚H‡®)r)  HÐCü5AÂVø¥G Ùqíì`‡§r3ß´è¹ëÜÊk%µò1#«š— +Z3ãB˜›x¿TÉ 1¬™[a<È (˜53®› W¨Í¨ŠQ#Ϩ h)£*U1nèœêêùÑÄ+2OÊ ‚“ò‚!mLÊwâªàˆž–_?Iì&Hâ´A{ƒ$n;$qN!‰£Irí$©]&BÕ¯ 7Þ¶U@W«¢ÅåÐA·(-”¢˜UЭ
+e WÐ]d¡ M¨‘.ŠÞ—*°u½ŒÔîxqž¿³õ¾³õR×ûÎÿ5ÏÖcÊY
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/posix_filtro.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/images/oview_Fig_Idea2.dia
===================================================================
--- branches/new_sharkdoc/vol4/images/oview_Fig_Idea2.dia (nonexistent)
+++ branches/new_sharkdoc/vol4/images/oview_Fig_Idea2.dia (revision 1676)
@@ -0,0 +1,10 @@
+‹íšKs›0€ïù ¹º€xÓÖî4½v¦‡öÎ[±ÕʒGÈqÒC{Å#&`°^mZœ 3À²+‰oW«Eï?Üo‰r‡xŒ«@3Ô‹«÷+ ßÊÿ5‡[E
+Ð89›«!vouýp8hä!†‚qà½#ý$êRHWWŠòTÁ
+
+˜\˯B!8Žö)nÑ\àòǚ³=]©™T.·d„qå’¹z}›þT=W£—ôœÑ½ƒ;Ä«j·;c)"v'" +z’ã™\*–Bt½¸þh_gMÊ/ºêÚhDl!_czj‡#H²05ß|…—ˆ†6@†6À‡6€ãpǸà‹S#cAšÙ|Úۉ—HTÎu<C{vùˆt£{d—*þ˜Ú#ðñ¼Q7…'*w8ÆAy?Ÿ¸‹¾£¥Èç«€tùJy£Ü°{µˆ#†ªàÕ\ýb”¯: R™ï¸ê~;†©ÈFÁš¹Å84B“ê(ªjæ²í® z„%pfŽ<¼s4ÙùòÐÎ"h.§§±¤Î¤êx%6§:‚ßAõáõFô®S9aÈ«ºŸF÷ÈIþڙˆ7ìÖL!—]¶~Ñ Æ[CºBï
+½}„Þzç?ƒþo$ÒìJ¤7(‘î‘È` "½‰È?N¤Õ•È`P"ý#‘Œd0!ùǑ´»" À L£€ÒÊöý™¨ìJ§3•Ã.¡@±†£,¢€5Q9"•ßн¨ÁÒ튥=ó¤ÒÒÌÀž¹šé¸®ýÎÖ<ÝyÙY;«"†“5l¹”X‘izi‘°$W©'~ƒ +õÄ3U¦c·ŒŠ:SÉõ\äÛs,=NïbçýK­—›(ãt©6&ª•ŠÚj…‘þº‚¯éÕ¿D÷ۗXmpP÷÷:ÏJÃú?(ðÚ"@4E€6L! ÿpƒ~J:>cŠjßC pM€3KI ðü–Ùi„~†i»Ÿß›šûæÌ>wß=»õXÅrBÎÙ¡Úú‚5«³î º>—^šßÝȅþÙ6–ŒRI‹ä9>‰ëw”ôƒä;˜^°t=¦w«_éžµògÆgÝ·Ò ~&ë «šÃÎ՚xÇ©ÚÔlÃz=35˜&ê6µ9ÍÓc¥ê ó7xàëÿN)÷uEkŠ­Ruw
+½‡€†$tޑ†Ý’Š= ¦‘‘ÝÖEä$‡
+]]N՝ó©ºi´í2‘o!ŒÅA͹¶9^Šjöf6Qfö@™?8e^A™?
+eþÊü‚2o¤Å èaç€=è΁$™±òd&Hsûµä2æ”Ë´Ée‚rÕfJež“ÊdçéþãÅUiƒòâê7qfJå–0
\ No newline at end of file
/branches/new_sharkdoc/vol4/images/oview_Fig_Idea2.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/kernsupport.tex
===================================================================
--- branches/new_sharkdoc/vol4/kernsupport.tex (nonexistent)
+++ branches/new_sharkdoc/vol4/kernsupport.tex (revision 1676)
@@ -0,0 +1,875 @@
+%----------------------------------------------------------------------------
+\chapter{Kernel Internals}
+%----------------------------------------------------------------------------
+
+Since the Generic Kernel does not implement any memory protection,
+all the Modules have access to the internal data structures used
+for scheduling. Although the Modules could modify these data
+structures, typically they do not need to do so.
+
+%----------------------------------------------------------------------------
+\section{Kernel types}
+%----------------------------------------------------------------------------
+
+The Generic Kernel defines a set of primitive data types, that are
+briefly described below:
+
+\begin{description}
+\item [PID]This type is used to contain a task index. It is an
+integer pointing to an entry of the task descriptor table. This
+type can have values in the range {[}0...MAXPROC-1{]}, plus an
+invalid value, NIL (that is, -1).
+
+\item [IQUEUE]This type is used to implement the task queues typically used in
+scheduling operations. For more information see Section \ref{KernSupport_Code}.
+
+\item [TASK]This type is simply a
+redefinition of the \texttt{void {*}} type and it can be used for
+readiness ad the returned value in the task function declaration.
+
+\item [LEVEL,~RLEVEL]They are used to index the Module descriptor
+Tables. They are integers and they point to a particular entry.
+The values of these types are
+{[}0...\texttt{MAX\_SCHED\_LEVEL-1}{]} for the \texttt{LEVEL} type
+and {[}0...\texttt{MAX\_RES\_LEVEL}{]} for the \texttt{RLEVEL}
+type.
+
+\item [bandwidth\_t]This type is used to store a real number
+in the range {[}0,1{]}. It is a 32 bit unsigned integer and its
+value is interpreted as $\frac{x}{MAX\_ BANDWIDTH}$.
+
+\item
+[task\_key\_t]This is an integer type and it is used as an index
+for task specific data (similar to POSIX's Thread Specific Data).
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Descriptors}
+%----------------------------------------------------------------------------
+
+In this section we present all the descriptors defined in the
+Generic Kernel. If not specified, these data structures are
+defined in the \texttt{include/kernel/descr.h} file and they are
+used (usually as arrays) in the \texttt{kernel/kern.c} file.
+
+%----------------------------------------------------------------------------
+\subsection{Task Descriptor}
+\label{KernSupport_Task_descriptor}
+%----------------------------------------------------------------------------
+
+The \texttt{proc\_des} structures used to define task control blocks
+\footnote{The name of this structure is derived from the previous versions of
+Hartik. However, it is a \textit{task} descriptor and not a \textit{process}
+descriptor.}. In the following paragraphs the fields of the task descriptor are
+described \footnote{The following fields have been removed from the structure in
+the last releases: request\_time, priority, timespec\_priority, prev, next.}.
+
+\begin{description}
+\item [DWORD~task\_ID]Progressive number assigned to a task at its
+creation.
+
+\item [LEVEL~task\_level]This field points to the Module
+that owns the task. The Generic kernel uses this field to redirect
+the calls to the Module owning the task.
+
+\item
+[CONTEXT~context]This field contains an index in the OS Lib
+context array that handles the context of a task.
+
+\item
+[BYTE~{*}stack]This field is a pointer to the memory used as a
+task stack.
+
+\item [TASK~(*body)()]This field is the pointer to
+the first instruction of a task body, and it is used at
+initialization time.
+
+\item [char~name[MAX\_TASKNAME]]This is a
+symbolic name, whose length is defined by the
+\texttt{MAX\_TASKNAME} constant.
+
+\item [WORD~status]This is the
+task status.
+
+\item [WORD~pclass]This field is the Class code of
+the Task Model used during task creation. It can be used by
+Modules to know the typology of the task (useful if the task
+supports many types of Models; see
+%
+% Tool: such section does not exists.
+%
+%Section
+%\ref{SchedModules_LevelCalls},
+\texttt{level\_accept\_task\_model}
+%function)
+.
+
+\item [WORD~group]This is the task group. The value 0
+is used to index a single task. This field is not used as a GID in
+classical Unix systems but is used to kill or activate a group of
+tasks in an atomic way.
+
+\item [WORD~stacksize]Stack dimension (in
+bytes).
+
+\item [DWORD~control]Task Status flags. A description of
+the bits in this field is reported in
+Section\ref{Modelli_TASK_MODEL}.
+
+\item
+[int~frozen\_activations]Number of frozen activations. Useful only
+if the \texttt{FREEZE\_ACTIVATION} flag of the \texttt{control}
+field is active (see Section \ref{Kernel_Attivazione}).
+
+\item
+[int~sigmask]This is the blocked signal task mask (see
+\texttt{kernel/signal.c} and also \cite{POSIX1003.1}).
+
+\item
+[int~sigpending]This is the pending signal task mask (see
+\texttt{kernel/signal.c} and also \cite{POSIX1003.1}).
+
+\item
+[int~sigwaiting]This is the mask of the signals on which a task is
+waiting, blocked on a \texttt{sigwait} primitive (or similar).
+
+\item [int~avail\_time]This field contains the remaining
+computation time of a task (see Section
+\ref{KernSupport_Capacita}).
+
+\item [PID~shadow]This is the shadow
+pointer (see Section \ref{oview_Shadows}).
+
+\item
+[struct~\_task\_handler\_rec~{*}cleanup\_stack]Pointer to the
+first element of the cleanup stack.
+
+\item [int~errnumber]This is
+an error number local to the running task. The symbol
+\texttt{errno} defined into the C standard is implemented as a
+macro that refers to this field of the running task.
+
+\item
+[TIME~jet\_table{[}JET\_TABLE\_DIM{]}]This table contains the
+computation times consumed by the last JET\_TABLE\_DIM instances
+of the task. The table is handled as a circular buffer.
+
+\item
+[int~jet\_tvalid]This is the number of valid items in the
+\texttt{jet\_table} table.
+
+\item [int~jet\_curr]This is the
+current element in the \texttt{jet\_table} table.
+
+\item
+[TIME~jet\_max]This field contains the maximum time (in
+microseconds) consumed by a task, among all its instances.
+
+\item
+[TIME~jet\_sum]This field accumulates the execution times (in
+microseconds) of all task instances from the start of the task (or
+from the last call to \texttt{jet\_delstat}). This field, together
+with the \texttt{jet\_n} field, is used to compute the mean
+execution time of a task instance.
+
+\item [TIME~jet\_n]This field contains the number of instances involved in the
+computation of \texttt{jet\_sum}.
+
+\item [PID~waiting\_for\_me]This field contains
+the identifier of the task which is currently blocked for a
+\texttt{task\_join} on the current task. The field value is NIL if
+no task is blocked for a join on it.
+
+\item
+[void~{*}return\_value]This is the value returned by a task when
+it dies. This value is memorized if the task is joinable, waiting
+for someone to synchronize on it with a join.
+
+\item
+[void~{*}keys{[}PTHREAD\_KEYS\_MAX{]}]This array contains the task
+specific data.
+
+\item
+[struct~condition\_struct~{*}cond\_waiting]This field is NULL or
+it points to the condition variable on which the task is
+blocked \footnote{This field is present because if a task is killed during
+a block on a condition wait, the POSIX standard requires that the
+task reacquires the mutex linked to that condition before it
+dies.}.
+
+\item [int~delay\_timer]This field is used in the
+implementation of the blocking primitives with timeout. Usually
+this field contains the OS Lib index of the event created for the
+wake-up.
+
+\item [int~wcet]This field can be used by Modules to
+store some temporal information. It is generally used in
+conjunction with the \texttt{avail\_time} field.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Level descriptor}
+\label{KernSupport_Level_Descriptor}
+%----------------------------------------------------------------------------
+
+In this Section we describe the fields contained in the
+\texttt{level\_des} structure, that implements the Scheduling
+Module Descriptor. These Modules will fill the proposed interface,
+defining also all the interface functions. If a Module does not
+implement an interface function, it redefines that function in a
+way that it will raise an exception if called. The fields defined
+for the \texttt{level\_des} structure are the following:
+
+\begin{description}
+\item [Private~Functions,~Public~Functions]The rest of the interface is made of
+a set of function pointers that implements the \emph{virtual} functions of the
+Scheduling Modules. That functions are described in the Chapter
+\ref{CapSchedulingModules}. All that functions have as first parameter a LEVEL
+field that can be used to find the Module Descriptor and then the private
+structures of that Modules \footnote{The behaviour of the LEVEL parameter passed
+to that function is the same of the hidden paramether \emph{this} of many Object
+Oriented languages.}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Resource module descriptor}
+\label{KernSupport_Descrittore_GestioneRisorse}
+%----------------------------------------------------------------------------
+
+In this Section we describe the fields contained in the
+\texttt{resource\_des} structure, which implements the Resource
+Module Descriptor. These Modules will fill the proposed interface,
+defining all the required functions. If a Module does not
+implement an interface function, it redefines that function in a
+way that it will raise an exception if it is called. The fields
+defined for the \texttt{resource\_des} structure are the
+following:
+
+\begin{description}
+\item [char~res\_name{[}MAX\_MODULENAME{]}]This filed contains a
+symbolic Name of the Module, for statistical purposes. The file
+\texttt{include/modules/codes.h} contains the name of the Modules
+distributed with the Kernel. \item [WORD~res\_code]This field
+contains a numeric identifier that identifies a Module in an
+unique way. The codes of the Modules distributed with the kernel
+are written in the file \texttt{include/modules/codes.h}. \item
+[BYTE~res\_version]This is a version number for the Module. The
+version numbers of the Modules distributed with the Kernel are
+reported in the file \texttt{include/modules/codes.h}. \item
+[int~rtype]This field is used to identify the extended interface
+implemented by a Resource Module. This field is necessary to
+implement some primitives that use a particular extended
+interface, that need to know which of the resource modules
+registered in the kernel have a particular extension. \item
+[Resource~Calls]The rest of the interface is made of a set of
+function pointers that implement the \emph{virtual} functions of
+the Resource Modules. These functions are described in Chapter
+\ref{CapModuliRisorsa}. All these functions have as first
+parameter a RLEVEL field that can be used as the similar parameter
+of the Scheduling Module virtual functions.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{System states}
+%----------------------------------------------------------------------------
+
+As mentioned in Section \ref{oview_Status} the concept of task
+state has a local meaning, and it is stored in the \texttt{status}
+field of its task descriptor.
+
+The values that the status field can have are divided in four
+intervals, described in Table \ref{KernSupport_Tab_StatusCodes}.
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|p{4cm}|p{9cm}|}
+\hline
+Interval reserved to & Codes\\ \hline \hline
+
+Generic Kernel & {[}0...\texttt{MODULE\_STATUS\_BASE}-1{]} \\ \hline
+Scheduling Algorithm \foreignlanguage{english}{} & {[}\texttt{MODULE\_STATUS\_BASE}
+...\texttt{APER\_STATUS\_BASE}-1{]}\\ \hline
+
+Aperiodic Servers \foreignlanguage{english}{} & {[}\texttt{APER\_STATUS\_BASE}
+...\texttt{LIB\_STATUS\_BASE}-1{]}\\ \hline
+
+Others (Resource Handling, libraries, etc.) \foreignlanguage{english}{} &
+\texttt{>= LIB\_STATUS\_BASE}\\ \hline
+\end{tabular}
+\end{center}
+\caption{Partitioning of the codes for the status field of the task descriptor.}
+\label{KernSupport_Tab_StatusCodes}
+\end{table}
+
+Each Module Should use the codes in the correct range of values.
+
+This approach allows to handle many Module configurations. The
+fact that two Scheduling Modules use the same status code for
+different meanings is not a problem, because the codes are used
+internally to the Modules.
+
+%----------------------------------------------------------------------------
+\section{Kernel Global Variables}
+\label{KernSupport_Variabili}
+%----------------------------------------------------------------------------
+
+The following global variables are defined in the Generic Kernel
+and can be used by the Modules.
+
+\begin{description}
+
+\item [proc\_des~proc\_table{[}{]}]This variable is the task descriptor array.
+Not all the entries of this array are used. The descriptor really allocated are
+handled by the \texttt{task\_create} primitive.
+
+\item [level\_des~{*}level\_table{[}{]}]This variable is the array that
+memorizes a set of \emph{pointers} to the Scheduling Modules
+Descriptors. When a Module registers itself into the Kernel, an
+entry of this array is allocated, and it points to an
+\emph{extension} of the \texttt{level\_des} descriptor type. In an
+object oriented interpretation it can be thought as a polymorphic
+Module array (see Section \ref{Modelli_MetodologiaOOP}).
+
+\item [resource\_des~{*}resource\_table{[}{]}]This variable memorizes an
+array of pointers to extension of the resource\_des structure. For
+this variable the same comments for the level\_table apply.
+
+\item [PID~exec]This variable contains the task returned by the
+Scheduling Module scheduling operation. Typically this variable is
+used only into the \texttt{scheduler()} function of the Generic
+Kernel. This variable cannot be modified, it can only be read and
+checked with the field \texttt{exec\_shadow}. This variable has
+the value \texttt{NIL} (-1) when a primitive blocks the running
+task, and the scheduler is not yet called. This variable
+\emph{does not} point to the running task. Use
+\texttt{exec\_shadow} instead!
+
+\item [PID~exec\_shadow]This variable points to the running task. It can be
+different from the value contained into \texttt{exec} because of the Shadow
+mechanism (see Section \ref{oview_Shadows}). This variable cannot be modified,
+it can only be read and check with the field \texttt{exec}. This variable has
+the value \texttt{NIL} (-1) when a primitive blocks the running task, and the
+scheduler is not yet called. When a reference to the running task is needed,
+this variable has to be used.
+
+\item [int~cap\_timer]This variable is different from -1 only if the Generic
+Kernel or a Module created a capacity event. This variable can be used by the
+Scheduling Modules that do not utilize the \texttt{CONTROL\_CAP flag} for their
+tasks (see Section \ref{KernSupport_Capacita}).
+
+\item [struct~timespec~schedule\_time]This variable contains the system time in
+which the scheduler was called the last time. The first thing the Kernel
+function \texttt{scheduler()} does is the setting of that variable. This
+variable is also used as finish time for an execution time interval.
+
+\item [struct~timespec~cap\_lasttime]This variable is a copy of the
+\texttt{schedule\_time} variable, done at each call of the \texttt{scheduler()}
+function. The value of that variable is used as the start time of the last
+interval executed by a task. It is used to implement the time accounting.
+
+\item [DWORD~res\_levels]This variable is the number of resource
+module level descriptors allocated. It is modified only by the
+\texttt{resource\_alloc\_descriptor} function
+%
+% Tool: such section does not exists.
+%
+% (see Section \ref{SchedModules_RegFunctions})
+.
+
+\item [int~task\_counter]This variable is a variable that counts the number of
+User tasks actually present into the system (see Section
+\ref{Kernel_Inizializzazione}).
+
+\item [int~system\_counter]This
+variable is a variable that counts the number of System tasks
+actually present into the system (see Section
+\ref{Kernel_Inizializzazione}).
+
+%
+% Tool: no more sys_end nor sys_abort. Check this in the code!
+%
+% \item [int~mustexit]This variable
+% is used by the system primitives \texttt{sys\_end} and
+% \texttt{sys\_abort} to block the context changes into the event
+% handlers.
+
+\item [int~calling\_runlevel\_func]This variable is a
+flag. It is set to 1 when the system executes some system
+functions (registered through the \texttt{sys\_atrunlevel()}
+function). This flag influence the \texttt{task\_activate}
+primitive, because that primitive has to do different stuffs
+depending on the value of that variable (see the code of the
+primitive in the file \texttt{kernel/activate.c}).
+
+\item
+[IQUEUE~freedesc]This variable is the free task descriptor queue.
+It is handled by the Kernel and must be used by a Scheduling
+Module into the call \texttt{task\_end} call to free a task
+descriptor of a task terminated correctly.
+
+\item
+[TIME~sys\_tick]If the OS Lib is initialized with the \textit{one
+shot timer} the variable contains the system tick (in
+microseconds). Otherwise, the one-shot timer is used, and this
+variable has a value of \texttt{0}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Temporal protection}
+\label{KernSupport_Capacita}
+%----------------------------------------------------------------------------
+
+The Generic Kernel supports task temporal protection through a set
+of procedures and data structures that may be used by the
+Scheduling Modules. The generic Kernel does force to use its own
+functions, so a Module can define itself a policy to ensure
+temporal protection. In this Section the proposed functions to
+implement the temporal protection are described.
+
+The Generic Kernel handles the time capacity of the tasks in the
+system using the creation and the deletion of a specific OS Lib
+event that simply reschedules the system. The end of the capacity
+is seen by the Modules as a normal epilogue done in the case of a
+preemption.
+
+The timer event is created when a task is dispatched, and it is
+deleted by all the primitives that may cause preemption. In an
+instant there is at least one capacity event pending, that is the
+event of the running task.
+
+The Generic Kernel defines for each task the bit
+\texttt{CONTROL\_CAP} that is memorized into the field
+\texttt{control} of the task descriptor. That bit is set by the
+Scheduling Modules to require for a task the creation of the
+capacity event at dispatch time.
+
+The Scheduling Modules have also to check the capacity exhaustion
+each time a task is descheduled.
+
+Capacities are handled using the following variables provided by
+the Kernel:
+
+\begin{itemize}
+
+\item The \texttt{wcet} field of the task descriptor usually memorizes a
+characteristic time for a task (i.e., it is used to store a worst-case execution
+time or a mean execution time). It is included in the task descriptor to avoid
+the allocation of such an information for all the modules. It is \emph{not} used
+by the Generic Kernel.
+
+\item The \texttt{avail\_time} field of the task descriptor is used to handle
+the available execution time for a task. The capacity event generated by the
+Generic Kernel at dispatch time has an activation time that is equal to
+\texttt{schedule\_time + avail\_time}. The field is updated by the generic
+kernel each time a task is descheduled, decrementing the slice just executed by
+the task.
+
+\item The \texttt{cap\_timer} field is used by the Generic Kernel to know
+whether a capacity event is or not pending. If the field is equal to -1, there
+are no events, otherwise the value is the index of the capacity event. If the
+field is not equal to -1 the Generic kernel will delete automatically the event
+each time the system is rescheduled. The Generic Kernel does not check who has
+created the event pointed by \texttt{cap\_timer}, so a Scheduling Module that
+not use the flag \texttt{CONTROL\_CAP} can create a capacity event and put his
+index into \texttt{cap\_timer}, avoiding the removal of the event directly in
+the code of the Module.
+
+\item The \texttt{cap\_lasttime} field contains the time of the previous
+reschedule of the system. The accounting of the computation times is done from
+the difference between \texttt{schedule\_time} and \texttt{cap\_lasttime}. The
+time used by the Kernel primitives is accounted in the running task.
+
+\end{itemize}
+
+The functions called by the capacity event have only to reschedule
+the system. The Scheduling Modules that have to generate
+themselves the capacity event can store their events in the
+\texttt{cap\_timer} filed if they want an event to be removed at
+each preemption. The events can call the Generic Kernel Function
+called \texttt{capacity\_timer} (it does not accept any
+parameter).
+
+%----------------------------------------------------------------------------
+\subsection{Negative capacities}
+%----------------------------------------------------------------------------
+
+The contents of the \texttt{avail\_time} field can be negative.
+This fact, theoretically impossible, can happen for two reasons:
+
+\begin{itemize}
+\item first, the OS LIb event handler can not guarantee the
+delivery of a capacity event at exact time (a small delay of some
+microseconds may occur). So, a capacity event may be delivered
+after the capacity is exhausted, so that the task capacity becomes
+negative. We can suppose that negatives values are smaller than
+the usual time for the tasks; \item second, because the shadow
+mechanism can execute a task that has finished his budget; that
+task will not be descheduled until the shadow of the higher
+priority task points to it. This behavior is correct because we
+want that the blocking task will ends its critical section to
+limit the blocking time of the higher priority tasks. This
+approach is supported by some theoretical results (see
+\cite{Gha95}).
+\end{itemize}
+
+Scheduling modules can use two strategies to cope with the problem
+given by negative capacities.
+
+The first solution is to recharges the capacity with an amount
+equal to $Q_{s}$; if the capacity is still negative, the task will
+{}``loose a turn''. This solution is good for algorithms that
+provide a periodic replenishment (like for example Round Robin,
+Polling Server or Deferrable Server) but not for algorithms like
+Sporadic Server or Constant Bandwidth Server, where the
+replenishment is due to the capacity usage (in these algorithms
+the server would not become active).
+
+The second solution is to replenish the budget up to $Q_{s}$; this
+solution is good for all types of algorithms, but we have to
+consider that the server utilization factor becomes
+$\frac{Q_{s}+\Delta}{T_{s}}$.
+
+%----------------------------------------------------------------------------
+\section{Utility functions}
+%----------------------------------------------------------------------------
+
+This section contains a set of utility functions that can be used
+to simplify the writing of the Modules. Often these functions are
+simple redefinitions of the OS Lib functions. Use these functions
+instead of those provided by the OS Lib.
+
+%----------------------------------------------------------------------------
+\subsection{Event Handling}
+\label{KernSupport_GestioneEventi}
+%----------------------------------------------------------------------------
+
+The Generic Kernel uses the Generic kernel event handling provided
+by the OS Lib. The following functions should be used (see
+\texttt{include/kernel/func.h}):
+
+\begin{itemize}
+\item \texttt{kern\_event\_post} can be used to post an event. The
+redefinition adds a check on the index, raising an exception if
+the OS Lib event queue is full. \item \texttt{kern\_event\_delete}
+can be used to remove an OSLIB event. The unique parameter of the
+funcion is the eveni ID returned by the kern\_event\_post
+function. \item \texttt{event\_need\_reschedule}, with no
+parameters. It has to be called into the event handlers that have
+to reschedule the system. The Modules never have to call the
+schedule function into event handlers.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsection{Exception Handling}
+%----------------------------------------------------------------------------
+
+The Generic Kernel exception handling is based on the real-time
+signal interface of the POSIX standard. In particular, the
+exceptions are implemented with the signal number 9, SIGHEXC, that
+typically writes a message to the console and ends the system.
+
+The function to use to raise an exception is: \begin{center}
+\fbox{\tt{ void kern\_raise(int n, PID p); }} \end{center}
+
+As a result of this function call, a real-time signal is enqueued
+into the system and the n parameter is passed into the field
+\texttt{si\_value} of the structure \texttt{siginfo\_t} passed as
+a parameter to the signal handler.
+
+%----------------------------------------------------------------------------
+\subsection{Memory Management}
+\label{KernSupport_GestioneMemoria}
+%----------------------------------------------------------------------------
+
+The Generic kernel provides a memory allocator based on Flux
+OS-Kit LMM\cite{Bry97}. The LMM is in the \texttt{kernel/mem}
+directory; the functions defined in this subsection are in the
+file \texttt{kernel/mem.c}. These functions must be called with
+interrupt disabled.
+
+The allocator divides the memory into three regions that can be
+specified with some \#defines into the flag parameter of some
+functions:
+
+\begin{itemize}
+\item Memory addresses below 1 Mb (flag field set to
+\texttt{MEMORY\_UNDER\_1M}) \item Memory addresses from 1 Mb to 16
+Mb (flag field set to \texttt{MEMORY\_FROM\_1M\_TO\_16M}) \item
+Memory addresses below 16 Mb (flag field set to
+\texttt{MEMORY\_UNDER\_16M}) \item Memory addresses over 16 Mb
+(flag field set to \texttt{0})
+\end{itemize}
+
+Memory management functions are described below (see also Figure
+\ref{KernSupport_mem_functions}):
+
+\begin{figure}
+\begin{center}
+\begin{minipage}{6cm}
+\begin{verbatim}
+void *kern_alloc(DWORD s);
+void *kern_alloc_aligned(size_t size, lmm_flags_t flags,
+ int align_bits, DWORD align_ofs);
+void *kern_alloc_gen(size_t size, lmm_flags_t flags,
+ int align_bits, DWORD align_ofs,
+ DWORD bounds_min, DWORD bounds_max);
+void kern_free(void *block, size_t size);
+void *kern_alloc_page(lmm_flags_t flags);
+void kern_free_page(void *block);
+void *DOS_alloc(DWORD size);
+void DOS_free(void *ptr, DWORD size);
+\end{verbatim}
+\end{minipage}
+\end{center}
+\label{KernSupport_mem_functions}
+\caption{Memory allocation functions.}
+\end{figure}
+
+\begin{description}
+\item [\texttt{kern\_alloc}]This function allocates a memory block
+of s bytes returning a \texttt{void~{*}}. All the addresses given
+are supposed to be good for the block. The function returns
+\texttt{NULL} if there is not a free memory block with the
+required size. \item [\texttt{kern\_alloc\_aligned}]This functions
+allocates an aligned memory block. The first \texttt{align\_bits}
+of the block must be equal to the lowest \texttt{align\_bits} of
+\texttt{align\_ofs}. In other words, \texttt{align\_bits}
+specifies an alignment as a power of 2, whereas
+\texttt{align\_ofs} is a natural offset. The function returns
+\texttt{NULL} if there is not a block with the required
+characteristics. \item [\texttt{kern\_alloc\_gen}]This function
+allocates an aligned memory block in a way similar to
+\texttt{kern\_alloc\_aligned}, with the additional condition that
+the block must be found within the addresses \texttt{bounds\_min}
+and \texttt{bounds\_max}. \item [\texttt{kern\_free}]This function
+will free a block allocated with one of the previous functions.
+Note that this function requires the dimension of the block to
+allocate. \item [\texttt{kern\_alloc\_page}]This function
+allocates an aligned page of memory (4 Kb). \item
+[\texttt{kern\_free\_page}]This function frees a page allocated
+with the \texttt{kern\_alloc\_page} function. \item
+[\texttt{DOS\_alloc,~DOS\_free}]These functions allocate memory
+under the first Mb.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Context switch}
+%----------------------------------------------------------------------------
+
+The creation and the deletion of a context in the Generic Kernel
+is made using the OS Lib functions, properly renamed into
+\texttt{kern\_context\_create} and \texttt{kern\_context\_delete}.
+
+To change context, the Generic Kernel provides two functions,
+\texttt{kern\_context\_save} and \texttt{kern\_context\_load}.
+First function can be used to start a kernel primitive (disabling
+interrupts, whereas the second can be used to enable the
+interrupts, change the context using the OS Lib functions,
+dispatch pending signals and test for asynchronous cancellation.
+Note that currently the kernel primitives run on the same stack of
+the caller thread, and the primitives are simply called disabling
+the interrupts.
+
+These functions must never be called into the standard interface
+of the scheduling modules. When a OS Lib event need to reschedule
+the system because there is a preemption, the function
+\texttt{event\_need\_reschedule} must be called instead.
+
+The functions described in this paragraph are into the
+\texttt{include/kernel/func.h} file.
+
+%----------------------------------------------------------------------------
+\subsection{Queues, arrays and pointers}
+\label{KernSupport_Code}
+%----------------------------------------------------------------------------
+
+To simplify the use of the internal Kernel references, the
+following approach is used:
+
+\begin{itemize}
+\item Whenever possible, the descriptor arrays are statically
+allocated. \item Each descriptor is identified by an integer which
+represents the index in the descriptor array (e.g. PID, LEVEL,
+RLEVEL).
+\end{itemize}
+
+To handle task queues, the Generic Kernel provides some utility
+functions which can speed up the Module writing; however a module
+can use its own functions to enqueue tasks.
+
+The implemented functions do not use any fields of the task
+descriptor; they are implemented with a double linked list. The
+prototypes of the functions for queue management are shown in
+Figure \ref{KernSupport_queue_functions}. They are into the file
+\texttt{kernel/iqueue.c}, and \texttt{include/kernel/iqueue.h},
+described below.
+
+\begin{figure}
+\texttt{\#define IQUEUE\_NO\_PRIORITY 1}
+\texttt{\#define IQUEUE\_NO\_TIMESPEC 2}
+\texttt{struct IQUEUE\_shared \{ }
+\texttt{~~PID prev{[}MAX\_PROC{]}; }
+\texttt{~~PID next{[}MAX\_PROC{]}; }
+\texttt{~~struct timespec {*}timespec\_priority; }
+\texttt{~~DWORD {*}priority; }
+\texttt{\};}
+\texttt{typedef struct \{ }
+\texttt{~~PID first; }
+\texttt{~~PID last; }
+\texttt{~~struct IQUEUE\_shared {*}s; }
+\texttt{\} IQUEUE; }
+\texttt{~}
+\texttt{void iq\_init (IQUEUE {*}q, IQUEUE {*}share, int flags);}
+\texttt{void iq\_priority\_insert (PID p, IQUEUE {*}q); }
+\texttt{void iq\_timespec\_insert (PID p, IQUEUE {*}q); }
+\texttt{void iq\_insertfirst (PID p, IQUEUE {*}q); }
+\texttt{void iq\_insertlast (PID p, IQUEUE {*}q);}
+\texttt{void iq\_extract (PID p, IQUEUE {*}q); }
+\texttt{PID iq\_getfirst ( IQUEUE {*}q); }
+\texttt{PID iq\_getlast ( IQUEUE {*}q); }
+\texttt{PID iq\_query\_first(IQUEUE {*}q);}
+\texttt{PID iq\_query\_last(IQUEUE {*}q);}
+\texttt{struct timespec {*}iq\_query\_timespec(PID p, IQUEUE
+{*}q);}
+\texttt{DWORD {*}iq\_query\_priority (PID p, IQUEUE {*}q);}
+\texttt{PID iq\_query\_next (PID p, IQUEUE {*}q);}
+\texttt{PID iq\_query\_prev (PID p, IQUEUE {*}q);}
+\texttt{int iq\_isempty (IQUEUE {*}q);}
+\caption{Prototypes of the task queue handling functions.}
+\label{KernSupport_queue_functions}
+\end{figure}
+
+
+Basically, an IQUEUE has an \char`\"{}I\char`\"{}nternal prev/next
+structure, that may be shared between one or more queue. Of
+course, the user MUST guarantee that the same task will not be
+inserted in two IQUEUEs that share the same prev/next buffer.
+
+Internal queue initialization:
+
+\begin{description}
+\item [share~=~\&x]the internal data structure of the IQUEUE x is
+used to enqueue the tasks. \item [\texttt{share~=~NULL}]an
+internal data structure to handle prev/next pairs is dynamically
+allocated (The amount of memory that is allocated can be reduced
+using the flags). \item [flags]can be used to reduce the memory
+usage of an IQUEUE when \texttt{share=NULL}:
+
+\begin{description}
+\item [\texttt{IQUEUE\_NO\_PRIORITY}]the iqueue do not provide
+internally a priority field \item
+[\texttt{IQUEUE\_NO\_TIMESPEC}]the iqueue do not provide
+internally a timespec field
+\end{description}
+
+note that, if these flags are used, the corresponding insert
+functions will not work!. The default value for the flags is, of
+course, 0.
+
+\end{description}
+The queue insertion is made by the following functions:
+
+\begin{description}
+\item [iq\_insert]insertion based on the \texttt{priority} field.
+\item [iq\_timespec\_insert]same as above but use the
+\texttt{timespec\_priority} field \item [iq\_insertfirst]insert in
+the first position of the queue \item [iq\_insertlast]insert in
+the last position of the queue
+\end{description}
+
+The queue extraction functions: basically extracts a task p from
+the queue q. There are three versions of the function:
+
+\begin{description}
+\item [iq\_extract]extracts given a task p (that must be inserted
+in the queue); \item [iq\_getfirst]extracts the first task in the
+queue, NIL if the queue is empty; \item [iq\_getlast]extracts the
+last task in the queue, NIL if the queue is empty;
+\end{description}
+
+Seven queue query functions are also provided. The first two
+functions (query first/last) return the first and the last task in
+the queue, NIL if the queue is empty. The second two functions
+(query priority/timespec) can be used to get/set the priority or
+the timespec field used when queuing. The third two functions
+(query next/prev) can be used to scan the queue elements. The last
+function can be used to test if a queue is empty.
+
+%----------------------------------------------------------------------------
+\subsection{Initialization functions}
+%----------------------------------------------------------------------------
+
+The Generic Kernel supports the specification of the functions to
+be called at system initialization and termination (see Section
+\ref{Kernel_Inizializzazione}). These functions can be registered
+through the following system primitive:
+
+\begin{center}
+\fbox{\tt{
+\texttt{int sys\_atrunlevel(void ({*}f)(void {*}),void {*}p, BYTE when);
+}}}
+\end{center}
+
+The parameters for that function are:
+
+\begin{description}
+
+\item [\texttt{f}]the function to be registered;
+
+\item [\texttt{p}]the parameter to be passed to function \texttt{f} when the
+function will be called;
+
+\item [\texttt{when}]is the situation in witch that function will be called. The
+correct values are the following:
+
+\begin{description}
+
+\item [\texttt{RUNLEVEL\_INIT}]The function will be called after Module
+registration, when the system is just entered in multitasking mode but no thread
+executed yet;
+
+\item [\texttt{RUNLEVEL\_SHUTDOWN}]The function will be called after a call to
+\texttt{sys\_abort} or \texttt{sys\_end}; The system is still in multitasking
+mode;
+
+\item [\texttt{RUNLEVEL\_BEFORE\_EXIT}]The function will be called when the
+Kernel exits from multitasking mode;
+
+\item [\texttt{RUNLEVEL\_AFTER\_EXIT}]The function is called before the system
+hangs (or returns to the host OS, if the proprietary extender is used).
+
+\end{description}
+
+It is also possible to specify with an OR operator a flag
+\texttt{NO\_AT\_ABORT} that disables the call to the functions if
+the system is exiting with a \texttt{sys\_abort} function.
+\end{description}
+
+You can post at most \texttt{MAX\_RUNLEVEL\_FUNC} functions.
+
+%----------------------------------------------------------------------------
+\subsection{Interrupt disabling, printf and system termination}
+%----------------------------------------------------------------------------
+
+The Generic Kernel redefines the following OS Lib functions (see
+the \texttt{include/kernel/func.h} file):
+
+\begin{description}
+\item [\texttt{cli}]renamed in \texttt{kern\_cli} \item
+[\texttt{sti}]renamed in \texttt{kern\_sti} \item
+[\texttt{ll\_fsave}]renamed in \texttt{kern\_fsave} \item
+[\texttt{ll\_frestore}]renamed in \texttt{kern\_frestore}.
+\end{description}
+
+To display some messages to the console, the Generic Kernel
+provides two functions called \texttt{printk} and
+\texttt{kern\_printf}. These functions are similar to the standard
+C \texttt{printf} function, except that they write directly to the
+console. The \texttt{printk} function allows to specify a kind of
+``importance'' for the message that the function displays. For
+more information look at the file \texttt{include/kernel/func.h}
+and \texttt{include/kernel/log.h}.
+
+Finally, a clean system termination can be obtained through the \texttt{exit}
+primitive. For more information look at the file \texttt{include/kernel/func.h}
+and read Section \ref{Kernel_Inizializzazione}.
/branches/new_sharkdoc/vol4/kernsupport.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/scheduling_modules.tex
===================================================================
--- branches/new_sharkdoc/vol4/scheduling_modules.tex (nonexistent)
+++ branches/new_sharkdoc/vol4/scheduling_modules.tex (revision 1676)
@@ -0,0 +1,894 @@
+%----------------------------------------------------------------------------
+\chapter{The Scheduling Modules\label{CapSchedulingModules}}
+%----------------------------------------------------------------------------
+
+This chapter describes the interface of a generic Scheduling
+Module, the semantic of the functions that compose the interface,
+and a set of conventions used to write the Modules.
+%
+% Tool: such section does not exists.
+%
+% For more
+% information on the Scheduling Module Architecture see Section
+% \ref{ArchDetail_Scheduling_Modules}.
+
+%----------------------------------------------------------------------------
+\section{Task Lifecycle\label{SchedModules_Lifecycle}}
+%----------------------------------------------------------------------------
+
+To understand the interface of a Scheduling Module, we present a
+simple view of the events that refer the life of a task, from its
+creation to its end. The Module Interface reflects these events.
+
+Figure \ref{SchedModules_Lifecycle_Base} illustrates a simple
+case, in which a task is created, activated, and then preempted by
+another task that dies after a while. The following events are
+generated:
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=8cm]{images/schedmodules_lifecycle1.eps}
+\end{center}
+\label{SchedModules_Lifecycle_Base}
+\caption{A simple scenario: tasks i and j are created and activated. Task i is
+executed, and, after a while, it is preempted by task j. The numbers in
+parenthesis denote the event sequence.}
+\end{figure}
+
+\begin{description}
+\item [create]This event is generated at task creation. The
+Scheduling Module initializes the data structures for the task
+activation.
+
+\item [activate]This event is generated when a task is
+explicitly activated by a call to a user primitive. That event
+authorizes the Scheduling Module to insert the task in the set of
+the schedulable tasks.
+
+\item [dispatch]This event is generated when a task, after it has been scheduled
+\footnote{The scheduling event is not showed in the figure.}, is actually
+executed. The Scheduling Module updates the data structures to register the
+execution of the task.
+
+\item [epilogue]This event is generated all the times a task is preempted by
+another task \footnote{This event is also raised if the task finishes its time
+capacity allocated on its server (for soft tasks).}. The Scheduling Module
+usually reinserts the task in the set of the schedulable tasks.
+
+\item [end]this event is generated when a
+task ends its execution. The Scheduling Module is authorized to
+free the task descriptor and any data allocated for the task.
+\end{description}
+
+Note that the POSIX standard does not differentiate between task
+creation and task activation; in fact, the
+\texttt{pthread\_create} primitive creates and activates directly
+a task.
+
+Figure \ref{SchedModules_Lifecycle_endcycle} shows a sample sequence of events
+produced by a periodic task.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=1.0\columnwidth]{images/schedmodules_lifecycle2.eps}
+\end{center}
+\label{SchedModules_Lifecycle_endcycle}
+\caption{Activation handling: a periodic task is activated once, and it executes
+for three activations .}
+\end{figure}
+
+A task is activated, it executes for three instances and then it
+falls asleep waiting for another explicit activation. The new
+events introduced in this scenario are:
+
+\begin{description}
+\item [endcycle]The endcycle event is the termination of the
+current task instance. It is generated by a primitive inserted
+into the task code. If the task is a periodic task, it will be
+reactivated by the Scheduling Module at the beginning of the next
+period. If the task is an aperiodic task, this event implies that
+the task will wait for an explicit activation (through an activate
+event).
+
+\item [(reactivation)]This event is not created directly
+by the user with a primitive, but it is handled internally by the
+Scheduling Module that handles the task. This event reactivates
+the task, and it is usually delivered at the end of a period.
+\end{description}
+
+Although the event \textit{endcycle} terminates an aperiodic or a
+periodic job, and it can differ in the way they handle pending
+activations. A \emph{pending activation} is an \emph{activate}
+event which is delivered when the task has not ended the previous
+instance. The handling of pending activations is left to the
+Scheduling Modules.
+
+Figure \ref{SchedModules_Lifecycle_extract} shows the
+\textit{block} ed \textit{unblock} events. These events are
+generated to handle the behavior of a synchronization primitives,
+which generally blocks a task (\emph{block} event) and then
+activate again the task after a while (\emph{unblock} event). The
+events behave as
+follows:
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=8cm]{images/schedmodules_lifecycle3.eps}
+\end{center}
+\label{SchedModules_Lifecycle_extract}
+\caption{Task synchronization. A task calls a synchronization primitive, which
+blocks the task using an extract event. When the task will be able to continue,
+an insert event will be called.}
+\end{figure}
+
+
+\begin{description}
+\item [block]It disables the task scheduling because the task is
+arrived at a synchronization point.
+
+\item [unblock]This event is
+used to notify to the task that the synchronization is occurred,
+so the task scheduling must be enabled.
+\end{description}
+
+The Generic Kernel guarantees that an \textit{unblock} event will
+never be called before a corresponding \textit{block} event. That
+is, these two events are coupled.
+
+
+%----------------------------------------------------------------------------
+\section{Assumptions on Task Queues}
+%----------------------------------------------------------------------------
+
+The modules distributed with the Kernel use the following
+assumptions when managing task queues:
+
+\begin{itemize}
+\item The variables of type \texttt{IQUEUE} are allocated into the extensions of
+the level descriptor and \emph{not} outside;
+
+\item The running task is extracted
+from the ready queue (if there is one in the Module) at dispatch time
+\footnote{A policy that leaves the running task at the head of the ready queue
+is also suitable.};
+
+\item A Module can handle queue and other data structures
+than those provided by the Generic Kernel. In this case all the data structures
+shall be inserted in the level descriptor extension and the functions that use
+them shall be visible only in that Module (for example look at the file
+\texttt{kernel/modules/srp.c}).
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\section{Scheduling Module Interface\label{SchedModules_Interface}}
+%----------------------------------------------------------------------------
+
+This section describes the interface of the functions that have to be
+implemented to develop a Scheduling Module. The functions described in this
+Section are those represented by the dashed rectangles named \emph{Public
+Functions and Private Functions} introduced early in this chapter. They are
+\emph{not} user primitives, but they are called to implement the scheduling
+behavior of a primitive. The function names reported in this section are the
+name of the function pointers contained into the \texttt{level\_des} structure
+(defined into \texttt{include/kernel/descr.h}). When a designer implements a new
+Scheduling Module, he writes the correspondent functions and then he sets the
+correct values into the correct \texttt{level\_des} structure (as an example, a
+template application is provided on the website). The user primitives are
+listed into the S.Ha.R.K. User Manual (it can be found, together with the
+template application, on the proper section of S.Ha.R.K. website).
+%
+% Tool: such section does not exists.
+%
+% For more information see also at Sections \ref{ArchDetail_Module_Interface} and
+% \ref{KernSupport_Level_Descriptor}.
+
+All the interface functions have as first parameter a variable of
+\texttt{LEVEL} type, used to obtain a pointer to the level
+descriptor of the current Scheduling Module; some functions may
+also have additional parameters.
+
+We recommend that the functions listed in Table
+\ref{SchedModules_Tab_schedule_time} should use the global
+variable \texttt{schedule\_time} to get the system time, and
+should not use the \texttt{kern\_gettime} function provided with
+the OS
+Lib.
+\begin{table}
+\begin{center}\begin{tabular}{|c|c|}
+\hline Type& Function\\ \hline \hline Public
+Functions& \texttt{public\_scheduler}\\ &
+\texttt{public\_dispatch}\\ &
+\texttt{public\_epilogue}\\ &
+\texttt{public\_message}\\ &
+\texttt{public\_block}\\ \hline Private Functions&
+\texttt{private\_dispatch}\\ &
+\texttt{private\_epilogue}\\ \hline
+\end{tabular}\end{center}
+
+\caption{\label{SchedModules_Tab_schedule_time}These functions
+should use the variable \texttt{schedule\_time} to read the
+current time.}
+\end{table}
+
+\textbf{WARNING}: All the Scheduling Modules functions are called
+with \emph{interrupts disabled}. They should never consume more
+than a few microseconds!!!
+
+%----------------------------------------------------------------------------
+\subsection{Public Functions\label{SchedModules_PublicFunctions}}
+%----------------------------------------------------------------------------
+
+These functions are directly called by the Generic Kernel to
+implement the behavior of a scheduling algorithm.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{PID (*public\_scheduler)(LEVEL l);}}
+%----------------------------------------------------------------------------
+
+This function is the scheduler of the current Scheduling Module.
+
+It must return the scheduled task among those handled by the
+Module \footnote{That is, the tasks owned by the Module plus the tasks
+that other Modules inserted in it using the private
+functions.}.
+
+The scheduled task must be selected only using the private data structures of
+the Module, \emph{prescinding from the other Modules registered in the system}.
+The fact that a task is returned by this function to be scheduled does not imply
+that that task will be executed (dispatched) immediately
+%
+% Tool: such section does not exists.
+%
+% \footnote{Look at section \ref{ArchDetail_Shadows}}
+.
+
+So, the level scheduler shall not:
+
+\begin{itemize}
+\item Modify the pointer to the running task (in other words, the
+variables \texttt{exec} and \texttt{exec\_shadow});
+
+\item Handle
+timers for deadline, capacity exhaustion, and things like that;
+
+\item Set the data structures preparing the execution of the task (for example,
+if the Module uses a ready queue, the task must not be extracted from the queue
+\footnote{This will be done at dispatch time!}).
+\end{itemize}
+
+If the level does not implement a scheduler (because, for example, it is an
+Aperiodic server that inserts all its tasks in another Module \footnote{look at
+\texttt{kernel/modules/cbs.c}}), or if the Module currently does not have any
+ready task, the returned value must be \texttt{NIL}.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int (*public\_guarantee)(LEVEL l, bandwidth\_t *freebandwidth);}}
+%----------------------------------------------------------------------------
+
+This function implements the on-line acceptance test. This
+function should only consider the tasks directly inserted in the
+module, and it does not consider the tasks inserted in the module
+through private functions (their guarantee is made by the Module
+that owns them).
+
+The function is called with an additional parameter that is the
+free bandwidth left by the Modules with level number less than
+\texttt{l}. The acceptance tests that can be implemented are those
+based on the Utilization Factor.
+
+The function returns 1 if the current task set can be guaranteed
+using the free bandwidth available, 0 otherwise. The
+\texttt{freebandwidth} parameter must be decreased by the function
+by the amount of bandwidth used by the task being guaranteed.
+
+If the pointer to this function is registered in the
+\texttt{level\_des} descriptor of the Module with a NULL value,
+the acceptance test procedure will stop and the whole task set is
+considered guaranteed (see Section \ref{Kernel_Garanzia}).
+
+This function is called by the Generic Kernel each time a task is
+created in the system. The call is issued after the task is
+created using the task call \texttt{public\_create} and after the
+Resource Models of the new task have been registered. The
+public\_guarantee functions are called starting from level 0 until
+a NULL pointer is reached or the task set cannot be guaranteed.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int (*public\_create)(LEVEL l, PID p, TASK\_MODEL *m);}}
+%----------------------------------------------------------------------------
+
+This function is called by the Generic Kernel into the
+\texttt{task\_create} primitive to create a task into a Module.
+The function has two additional parameters: the first is the task
+descriptor allocated by the Generic Kernel for the new Task, and
+the second is the Task Model passed at creation time.
+
+The function returns 0 if the Module can handle the TASK\_MODEL
+passed as parameter (that is, if the Module can handle the pclass
+of the TASK\_MODEL, and if the level field is 0 or l), -1
+otherwise.
+
+The functions must set the Module internal data structures with
+the QoS parameters passed with the Task Model. The function does
+not enable the task to be scheduled in the system (i.e., if a
+ready queue is implemented, the new task should not be inserted in
+it).
+
+The \texttt{task\_create} primitive sets the task state to the
+default \texttt{SLEEP} value, and sets the flags of the
+\texttt{control} field of the task descriptor to the values given
+into the \texttt{control} field of the \texttt{TASK\_MODEL}
+structure. These settings can be modified by the public\_create
+function.
+
+The acceptance test on a new task is called after this function.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void (*public\_detach)(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function is called into the Generic Kernel
+\texttt{task\_create} primitive when an error is occurred during
+the creation of a new task.
+
+The function receives as an additional parameter the task
+identifier passed to the \texttt{public\_create} function. This
+function is called only after public\_create, and it must reset
+the data structures allocated internally by the current Module
+during public\_create.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void (*public\_end)(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function implements task termination. When this function is
+called the task has been killed by someone (e.g., task\_kill() or
+pthread\_cancel()), or it is ended. All the references to task p
+have to be removed from the internal data structures of the
+Module.
+
+The \texttt{public\_end} function is called after the POSIX's
+cleanup functions, after the POSIX's thread-specific data
+destructors, and before the destructors of the Resource Modules.
+
+When the function is called the task is in the EXE state. The
+typical actions done by this function are the following:
+
+\begin{itemize}
+\item The task is extracted from some internal queue. \item All
+the pending events for the task (e.g., deadline and capacity
+timers) are removed. \item The task is inserted into the
+\texttt{freedesc} queue. When the task is inserted in this queue
+the task descriptor of the task may be reused by the Generic
+Kernel.
+
+
+If the Module implements some form of guarantee on the task set,
+the insertion of the descriptor p into the \texttt{freedesc} queue
+may be postponed until the bandwidth used by the task will be
+totally released. This may occur after task's termination (for
+example, in the EDF Module a guarantee is implemented, and the
+bandwidth is decreased at the end of the current period. Hence,
+the task descriptor will be inserted into the \texttt{freedesc}
+queue at the end of the period.
+
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int (*public\_eligible)(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function is called by the Generic Kernel into the global
+scheduling function (see Section \ref{Kernel_Scheduler}) and is
+used to ensure the Kernel of the correctness of the value returned
+by the public\_scheduler.
+
+The function receives as an additional parameter that is the task
+returned by the \texttt{public\_scheduler} call. It must return 0
+if the task can be scheduled, -1 otherwise. If a -1 is returned,
+the system will call the level scheduler function again to choose
+another (may be the same) task.
+
+This function is used when implementing aperiodic servers and the
+Module needs to know when its tasks will be scheduled by a
+level\_scheduler of the Master Module, to update some old out-of
+date parameters.
+
+This function is useful in pathological or unplanned situations.
+For example (see Figure \ref{SchedModules_Fig_eligible}), we have
+implemented a CBS module in a way that it uses another Scheduling
+Module. The CBS Module inserts its tasks in that module using the
+guest calls; after that, it waits for its tasks to be scheduled.
+In general, it may happen that, because of some overload
+condition, the CBS task will be scheduled after its deadline.
+Through the \texttt{public\_eligible} function the CBS Module can
+postpone the task deadline, so causing the scheduler to be called
+again to manage the new situation.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=7cm]{images/schedmodules_eligible.eps}
+\end{center}
+\label{SchedModules_Fig_eligible}
+\caption{Use of the \texttt{public\_eligible} function. Consider a CBS Module
+that inserts its task j into an EDF-NP (EDF non-preemptive) Module. EDF-NP will
+schedule task i first. When task i ends, task j (CBS) is scheduled. However,
+this task has an obsolete deadline. The \texttt{public\_eligible} function
+called on the CBS Module when the EDF-NP Module tries to schedule task j allows
+the CBS Module to postpone the deadline.}
+\end{figure}
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void (*public\_dispatch)(LEVEL l, PID p, int nostop);}}
+%----------------------------------------------------------------------------
+
+This function is called by the Generic Kernel to notify a Module
+(registered at level l) that his task p is going to be the running
+task.
+
+When this function is called it is not possible to change the task
+selected for execution. It is not possible to avoid the execution
+of a task that is on the tail of a shadow chain
+%
+% Tool: such section does not exists.
+%
+% (see Section\ref{ArchDetail_Shadows})
+. The \texttt{public\_eligible}
+function should be used instead whenever a task cannot be
+scheduled but it is chosen by a level scheduler.
+
+The function receives two additional parameters: the task
+\texttt{l} that will be executed and a \texttt{nostop} parameter.
+The value of the latter parameter is the result of the logic
+expression \texttt{exec == exec\_shadow}, where the value of
+\texttt{exec\_shadow} is computed by the \texttt{scheduler()}
+function (see Section \ref{Kernel_Scheduler}) after following the
+shadow chain. If the value nostop is 0, no capacity event should
+be generated by the Module.
+
+In practice, the \texttt{public\_dispatch} can be thought as a
+prologue in which the Scheduling Modules set the internal data
+structures to allow a task to be executed. The state of the task
+is set to EXE before the function call. The function shall not
+modify the task state, as well as the \texttt{exec} and
+\texttt{exec\_shadow} variables.
+
+A few typical actions for this function are described below:
+
+\begin{itemize}
+\item the task is removed from the ready queue, if there is one;
+
+\item if the Module does not use the \texttt{CONTROL\_CAP} flag (see
+\ref{KernSupport_Capacita}, and kernel/modules/ps.c) but it needs capacity
+control it is necessary to create a capacity event with the
+\texttt{kern\_event\_post} function. Remember that a capacity event should not
+be created if the \texttt{nostop} is not equal \texttt{0} \footnote{In this case
+the task is going to be the running task because it locks a resource needed by a
+high priority task, so usually the task must execute until the release of the
+blocking resource.};
+
+\item If the Scheduling Module is {}``coupled'' with a Resource
+Handling Module, this function must update the ceiling (for
+example as done with the SRP protocol).
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void (*public\_epilogue)(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function is called by the Generic Kernel when:
+
+\begin{itemize}
+\item the running task p is preempted by another task in the
+system;
+
+\item a function that may generate a preemption is called
+(these functions usually call the generic scheduler that, as a
+first operation, simply call this function);
+
+\item the capacity of
+the running task p is exhausted (the capacity exhaustion is
+handled as a preemption request!).
+\end{itemize}
+
+In general, this function receives as an additional parameter the
+running task index. The effect of the call may also disable the
+schedulability of the task. When this function is called the task
+p has a state equal to EXE.
+
+The typical actions done by this function are:
+
+\begin{itemize}
+\item if the schedulability of the task is still active, the task
+is reinserted into the ready queue, if there exists one into the
+Module; \item the state of the task is modified and it is set to
+an internal Module state (for example, a READY state); \item the
+capacity of the task is checked: if it is exhausted some
+operations will be done, for example an exception is raised, a
+deadline is postponed, and so on; \item If the Module created a
+capacity event without using the \texttt{CONTROL\_CAP} field and
+without using the \texttt{cap\_timer} variable, that capacity
+event must be removed.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void (*public\_activate)(LEVEL l, PID p, struct timespec *t);}}
+%----------------------------------------------------------------------------
+
+This function is called by the Generic Kernel when an explicit
+activation for the task is called using the
+\texttt{task\_activate} primitive or the \texttt{group\_activate}
+primitive.
+
+The PID parameter is the task that has to be activated. Also, the
+activation time is given as an parameter (this will be the
+time-base of the task). The effect of the function is to activate
+the schedulability of the task.
+
+The typical actions done by this function are listed below:
+
+\begin{itemize}
+\item First, a check is done to verify if the task is in a state
+compatible with the activation (for example, a sporadic task
+cannot be activated too frequently);
+
+\item The state of the task,
+usually equal to SLEEP, is modified (for example it becomes
+READY);
+
+\item If the Module has a ready queue, the task is
+inserted in it;
+
+\item If the Module counts the task's pending
+activations, and the task does not have finished his current
+activation yet, the activation should be saved for the task;
+
+\item
+If the Module handles periodic tasks or tasks with temporal
+deadlines, some events should be created to check these
+conditions.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void (*public\_block)(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+The function implements the blocking of the task p (p is the
+running task) in a generic synchronization primitive that does not
+use the shadow mechanism.
+
+The function must disable the schedulability for the task until it
+is ``freed'' by a call to the \texttt{public\_unblock} function.
+
+The typical actions done by this function are:
+
+\begin{itemize}
+\item The task should be extracted from the ready queue if the
+\texttt{task\_dispatch} didn't do this;
+
+\item The events posted
+with the dispatch should be removed (for example, the capacity
+events should be removed, but not the deadline ones);
+
+\item The
+function shall not modify the state of the task; the state of the
+task is modified by the primitive that calls the function;
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void (*public\_unblock)(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+The function accepts a parameter p that is the task that has
+terminated the synchronization started with a call to the
+\texttt{public\_block} function. After this call, the awaken task
+can be scheduled in the system.
+
+Usually the function inserts the task into some internal queues,
+and the state of the task is modified (for example it is set to
+READY). Usually the function does not post any event.
+
+The function is called into the code of the Generic Kernel
+primitives that implement synchronization without using the shadow
+mechanism. The Generic Kernel guarantees that this function is not
+called before the corresponding call to \texttt{public\_block}.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int (*public\_message)(LEVEL l, PID p, void *m);}}
+%----------------------------------------------------------------------------
+
+This function is called when the task\_message() primitive is
+called by a task to send a message to the scheduler. Typical
+messages are, for example, the end of an instance, or some kind of
+signaling the task must do to a scheduling module, like a
+checkpint mechanism.
+
+The parameter p is the running task (that is, exec\_shadow). A
+parameter m is passed, and it can be used to pass arbitrary
+parameters to the scheduler. The value NULL is typically used by
+the Kernel to signal the task\_endcycle primitive. An integer is
+also returned to return a kind of status value to the calling
+task.
+
+%----------------------------------------------------------------------------
+\subsubsection{The task\_endcycle primitive}
+%----------------------------------------------------------------------------
+
+A typical message that a task sends to a scheduling module is the
+end of an instance, signaled using a task\_endcycle() primitive.
+The implementation of that primitive is simply a
+``task\_message(NULL,1)''. The task\_message should implement a
+behavior similar to the one descried in the following paragraphs.
+
+If the task does not have pending activations (or if the Module does not manage
+them) the effect of the function is to disable the schedulability of the task
+until an explicit activation is done by the user \footnote{using a
+\texttt{task\_activate} call.} or an automatic reactivation done by the Module
+(if the task is periodic).
+
+If the task has some pending activations the function will
+reactivate the task in a way similar to \texttt{public\_epilogue}.
+
+The typical actions done by this function are listed below:
+
+\begin{itemize}
+\item If the task must be suspended, the task state is modified to
+a ``parking'' state (\texttt{IDLE} or \texttt{SLEEP});
+
+\item The
+task may be removed from the ready queue (if it was not removed by
+the \texttt{public\_dispatch});
+
+\item Some resource reclaiming
+algorithm may be implemented, because a task instance is finished;
+
+\item Timer events related to the budget exhaustion and deadlines
+are handled (for example events can be deleted, or postponed).
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsection{Private Functions}
+%----------------------------------------------------------------------------
+
+This section describes the private functions provided by a
+scheduling module. Private functions are called only by other
+scheduling modules, and never by the generic kernel, and they
+represent the interface extorted by a scheduling module towards
+other modules. Typical example of use of the private functions
+are:
+
+\begin{itemize}
+
+\item an EDF module have to implement task activation and
+unblocking simply inserting a task into the ready queue. For that
+purpose, the functions public\_activate and public\_unblock
+internally calls the private function private\_insert. Moreover,
+the two functions can have some peculiarities. For example, the
+implementer would like that public\_activate adds a deadline check
+posting an OSLib event at the deadline time, whereas this is not
+the case of public\_unblock, because the deadline used before have
+to be used again. Deadline posting can be done into
+public\_activate. private\_insert will simply insert the task into
+its \char`\"{}private\char`\"{} queue.
+
+\item an aperiodic server
+wants to insert a task into the EDF queue. Again, the
+public\_activate and the public\_unblock of the aperiodic server
+will call the private\_insert of the EDF queue, that will insert
+the task into its queue.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void (*private\_insert )(LEVEL l, PID p, TASK\_MODEL *m);}}
+%----------------------------------------------------------------------------
+
+This function is used to insert a task into the Module. The
+inserted task must have been already created through a call to the
+\texttt{task\_create} primitive. When inserted, the behavior of
+the function is as the task has been activated into the module
+(e.g., the task goes into the ready queue). All the useful
+informations passed to the task Model must be registered
+internally to the Module.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void (*private\_extract )(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function terminates a chunk of a task previously inserted in the Module
+using private\_insert. The typical effect of this function is to extract the
+task from the internal queues and to delete the events generated for the task
+(deadline, capacity, and so on). The function shall not insert the task
+descriptor in the \texttt{freedesc} queue \footnote{public\_end() is responsible
+for that\ldots{} }.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void (*private\_dispatch)(LEVEL l, PID p, int nostop);}}
+%----------------------------------------------------------------------------
+
+This function is usually called by \texttt{public\_dispatch} to
+inform the Master Module that a task inserted in it as a guest is
+being dispatched. The semantic of the function is similar to that
+of \texttt{public\_dispatch}.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void (*private\_epilogue)(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function is called by a Module to inform the Master Module
+that a task inserted in it using private\_insert() is being
+preempted or its budget has been exhausted.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int (*private\_eligible)(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function is usually called by public\_eligible to inform the
+Master Module that a task inserted in it as a guest has been
+chosen for scheduling. The semantic of the function is similar to
+that of \texttt{public\_eligible}.
+
+%----------------------------------------------------------------------------
+\section{Registration Function}
+%----------------------------------------------------------------------------
+
+The code contained in a Module is composed by the function calls
+(Level, Task and Guest Calls), and by a Registration Function that
+must be called when the system starts to properly initialize the
+kernel data structures. This registration function can be thought
+as a C++ constructor for the Module.
+
+A Module initialization typically consists of four parts:
+
+\begin{itemize}
+\item The first part allocates a level descriptor that will be
+used to initialize the Module; To alloc a level descriptor, the
+functions
+
+\texttt{LEVEL~level\_alloc\_descriptor(void)} and
+
+\texttt{RLEVEL~resource\_alloc\_descriptor(void)}
+
+must be used. These functions take no arguments and return a free
+descriptor to be used; \item The second part initializes the
+function pointer of the level descriptor of a scheduling module;
+\item The third part initializes the private data structures of
+the Module, and possibly posts a function that has to be called
+just after the system has gone in multitasking mode; \item The
+fourth part executes the function posted in the third part.
+\end{itemize}
+The first three parts are written in the Registration Function,
+which is called by the \texttt{\_\_kernel\_init\_\_} function
+before the Kernel goes in multitasking mode.
+
+In the \texttt{\_\_kernel\_init\_\_} function no Generic Kernel
+primitives can be called. If there is a need to do that, a
+registered function has to be called instead. For example, the
+dummy task is created by the Dummy Module
+(\texttt{kernel/modules/dummy.c}) through a registration function.
+The main task is created in the same way by the Round Robin Module
+(\texttt{kernel/modules/rr.c}).
+
+%----------------------------------------------------------------------------
+\subsection{Default values}
+%----------------------------------------------------------------------------
+
+In general, the scheduling modules needs only to register the
+functions they want to redefine. For that reason, the public and
+private functions have a default value, set by
+\texttt{level\_alloc\_descriptor()}. Here is a list of these
+default values:
+
+\begin{description}
+\item [private\_insert]Kernel Exception.
+
+\item
+[private\_extract]Kernel Exception.
+
+\item
+[private\_eligible]Returns 0 (that is, the task can be accepted
+for scheduling).
+
+\item [private\_dispatch]Kernel Exception.
+
+\item
+[private\_epilogue]Kernel Exception.
+
+\item
+[public\_scheduler]Returns -1 (that is, no task are ready to be
+scheduled).
+
+\item [public\_guarantee]Returns 1 (that is, the
+system can be scheduled).
+
+\item [public\_create]Returns -1 (that
+is, the model can not be handled by the module).
+
+\item
+[public\_detach]Does nothing.
+
+\item [public\_end]Kernel Exception.
+
+\item [public\_eligible]Returns 0 (that is, the task can be
+accepted for scheduling).
+
+\item [public\_dispatch]Kernel
+Exception.
+
+\item [public\_epilogue]Kernel Exception.
+
+\item
+[public\_activate]Kernel Exception.
+
+\item [public\_unblock]Kernel
+Exception.
+
+\item [public\_block]Kernel Exception.
+
+\item
+[public\_message]Kernel Exception.
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{Writing Conventions\label{SchedModules_Convenzioni}}
+%----------------------------------------------------------------------------
+
+This Section explains some conventions followed in writing the
+Modules. They are useful to understand how to write new Modules
+using the same style adopted in the Modules distributed with the
+Kernel. They can be summarized as follows.
+
+\begin{itemize}
+\item Each Module is composed of two files, one file \texttt{.h}
+and one file \texttt{.c}. The \texttt{.h} files are stored in the
+\texttt{include/modules} directory; the \texttt{.c} files are
+stored in the \texttt{kernel/modules} directory. \item Each
+Registration Function registers only ONE level descriptor. In this
+way the level at which a Module is registered can be found
+inspecting the initialization file. The level descriptor number is
+usually returned by the register function. \item The Task Models
+used by the Modules are listed in the
+\texttt{include/kernel/model.h} file. \item The names of the
+internal functions are defined as \texttt{static} and are in the
+form \texttt{MODULENAME\_FUNCTIONNAME}, where \texttt{MODULENAME}
+is the name of the \texttt{.c} file where the Module code is
+written. \item A Module can export some functions to implement a
+specific behavior; these functions have a first parameter of type
+\texttt{LEVEL}, in order to retrieve the Module data structures.
+An application that relies on a specific Module configuration can
+use the functions under the assumption that the Application knows
+the level at which the Module is registered. \item The prototypes
+of the functions exported by a Module (registration function plus
+other functions if present) have to be included in the \texttt{.h}
+file. \item The Modules should not use global data, because
+different instances of a Module can be registered at the same time
+in the system.
+\end{itemize}
+In general writing a new Scheduling Module requires the creation
+of new files. To simplify the distribution and the integration of
+new modules in the Generic Kernel no modifications have to be made
+to the standard distribution of the Kernel. Beside that, a few
+rules of common sense have to be followed:
+
+\begin{itemize}
+\item A new Scheduling Module should consist of only one
+\texttt{.h} file and only one \texttt{.c} file. Modules composed
+of many files should contain an explanation in their
+documentation. \item Together with the Scheduling Module a system
+designer should provide:
+
+\begin{itemize}
+\item an initialization file (similar to those present in the
+\texttt{kernel/init} directory) that shows how the new Module must
+be initialized; \item at least one test program showing the
+functionality of the Module;
+\end{itemize}
+\item New data definitions (for example new Task Models, new
+\texttt{pclass}, version and exception values) used by the new
+Modules should be inserted into the \texttt{.h} file of the
+Module. New constants should be different from the others
+contained into the default distribution.
+\end{itemize}
+A template example of a Scheduling Module can be found on the
+S.Ha.R.K. web site. Examples of third-party scheduling modules can
+be dound into the demos directory (e.g., demos/static,
+demos/edfact, demos/cash).
/branches/new_sharkdoc/vol4/scheduling_modules.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/makefile
===================================================================
--- branches/new_sharkdoc/vol4/makefile (nonexistent)
+++ branches/new_sharkdoc/vol4/makefile (revision 1676)
@@ -0,0 +1,4 @@
+MAIN = vol4
+MAIN_NAME = vol4
+
+include ../common/manual.mk
/branches/new_sharkdoc/vol4/makefile
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/examples.tex
===================================================================
--- branches/new_sharkdoc/vol4/examples.tex (nonexistent)
+++ branches/new_sharkdoc/vol4/examples.tex (revision 1676)
@@ -0,0 +1,1065 @@
+%----------------------------------------------------------------------------
+\chapter{Examples}
+%----------------------------------------------------------------------------
+
+The application of the proposed approach is presented in this
+chapter, on three meaningful examples, by showing the code of the
+scheduling and of the resource modules. The examples are really
+implemented in the Kernel, so these remarks can also be used as
+documentation.
+
+%----------------------------------------------------------------------------
+\section{SIMPLEEDF (Earliest Deadline First) Scheduling Module}
+%----------------------------------------------------------------------------
+
+This section describes an implementation of EDF with the following
+characteristics:
+
+\begin{itemize}
+\item Support for periodic and sporadic tasks;
+\item Support for release offsets and relative deadlines less than the period;
+\item On-line guarantee using the utilization factor paradigm;
+\item Temporal isolation implemented using the \texttt{CONTROL\_CAP} flag;
+\item A number of different deadline/WCET/activation violation options.
+\end{itemize}
+
+Typically this module is registered at Level 0; in effect the
+guarantee algorithm works only if the Module can use all the
+bandwidth of the system. In order to schedule background periodic
+tasks, a soft task model should be used with a Scheduling Module
+like the CBS Scheduling Module. The Module described in this
+section is contained in \texttt{modules/edf.c}.
+
+%----------------------------------------------------------------------------
+\subsection{State transition diagram}
+%----------------------------------------------------------------------------
+
+The state transition diagram for an EDF task is shown in Figure
+\ref{Examples_EDF_Stati}.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=1.0\columnwidth]{images/example_EDF_status.eps}
+\end{center}
+\label{Examples_EDF_Stati}
+\caption{State transition diagram for an EDF task. (For simplicity, some
+transitions have been excluded.)}
+\end{figure}
+
+The states whose name start with \texttt{EDF\_} are internal
+Module statuses. The event names are reported near the arcs; in
+particular the names of the timer events are written within
+parentheses. The different states have the following meanings:
+
+\begin{description}
+\item [\texttt{FREE}]Before creation, and after destruction, the
+task is in this state.
+
+\item [\texttt{SLEEP}]The task waits in this state for an explicit activation.
+
+\item [\texttt{EDF\_READY}]This is the classic ready state where the task has to
+wait until it has the highest priority (i.e., the earliest deadline).
+
+\item [\texttt{EXE}]This is the state when the task is executing.
+
+\item [\texttt{EDF\_WAIT}]This is the state of a sporadic task after finishing
+an instance, waiting for the endperiod event to arrive.
+
+\item [\texttt{EDF\_IDLE}]This is the
+state of a periodic task after finishing an instance, waiting for
+the endperiod event to arrive. An activated task with a release
+offset is also put in this state, waiting for the first period to
+arrive.
+
+\item [\texttt{EDF\_ZOMBIE}]This is the state where a task
+is put when it terminates correctly. The allocated bandwidth is
+freed when the endperiod event is fired.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Level
+descriptor}
+%----------------------------------------------------------------------------
+
+The EDF Module extends the \texttt{level\_des} structure that
+contains the interface exported by a generic Scheduling Module.
+The extended data structure, \texttt{EDF\_level\_des,} contains
+the following fields:
+
+\begin{description}
+\item [\texttt{flags}]This variable stores the flags passed to the
+module at registration time. The following flags are defined:
+
+\begin{description}
+\item [\texttt{EDF\_ENABLE\_DL\_CHECK}]If set, the module will
+keep track of task deadlines by internal deadline timers. The
+behavior in case of a deadline overrun depends on the
+\texttt{EDF\_ENABLE\_DL\_EXCEPTION} flag, see below.
+
+\item
+[\texttt{EDF\_ENABLE\_WCET\_CHECK}]If set, the module will keep
+track of task execution times by enabling the CONTROL\_CAP flag
+for the tasks in the generic kernel.
+
+\item
+[\texttt{EDF\_ENABLE\_DL\_EXCEPTION}]If set, the module will raise
+an exception if a deadline overrun occurs. If not set, the
+\texttt{dl\_miss} counter for the task is increased every time a
+deadline overrun occurs.
+
+\item
+[\texttt{EDF\_ENABLE\_WCET\_EXCEPTION}]If set, the module will
+raise an exception if an execution-time overrun occurs. If not
+set, the \texttt{wcet\_miss} counter for the task is increased
+every time an execution-time overrun occurs.
+
+\item
+[\texttt{EDF\_ENABLE\_ACT\_EXCEPTION}]If set, the module will
+raise an exception if a task is activated more often than its
+declared minimum interarrival time. If not set, the \texttt{nskip}
+counter for the task is increased instead.
+\end{description}
+
+\item [\texttt{ready}]This is an \texttt{IQUEUE} variable used to
+handle the ready queue. \item [\texttt{U}]This variable is used to
+store the sum of the reserved bandwidth for the tasks owned by the
+Module. \item [\texttt{tvec}]A vector of EDF task descriptors,
+\texttt{EDF\_task\_des}, that defines a number of additional
+variables for each task, see below.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Task
+descriptor}
+%----------------------------------------------------------------------------
+
+The EDF module introduces a number of additional task variables.
+They are collected in a \texttt{EDF\_task\_des} structure for each
+task:
+
+\begin{description}
+\item [\texttt{flags}]Flags that store some additional type/status
+information about the task. The following flags are defined:
+
+\begin{description}
+\item [\texttt{EDF\_FLAG\_SPORADIC}]The task is sporadic. This
+influences some state transitions, see Figure
+\ref{Examples_EDF_Stati}.
+
+\item
+[\texttt{EDF\_FLAG\_SPOR\_LATE}]The task is sporadic and has
+experienced a period overrun. (This is only possible if the
+EDF\_ENABLE\_DL\_EXCEPTION level flag is not set.) When finished,
+the task should go directly to the SLEEP state.
+\end{description}
+
+\item [\texttt{period}]The period or minimum interarrival time of
+the task.
+
+\item [\texttt{rdeadline}]The relative deadline of the
+task. Currently, only $D\leq T$ is allowed.
+
+\item
+[\texttt{offset}]The release offset, relative to the activation
+time of the task. \item [\texttt{release}]This variable stores the
+release time of the current instance.
+
+\item
+[\texttt{adeadline}]This variable stores the absolute deadline
+associated with the most recent task activation.
+
+\item
+[\texttt{dltimer}]A handle to the task deadline timer.
+
+\item
+[\texttt{eop\_timer}]A handle to the task end-of-period timer.
+
+\item [\texttt{dl\_miss}]Counter for the number of missed
+deadlines.
+
+\item [\texttt{wcet\_miss}]Counter for the number of
+execution-time overruns.
+
+\item [\texttt{act\_miss}]Counter for the
+number of skipped activations.
+
+\item [\texttt{nact}]The current
+number of queued activations (periodic tasks only).
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Module
+internal event handlers}
+%----------------------------------------------------------------------------
+
+The module uses internal kernel events (one-shot timers) to handle
+the release of tasks, deadline overruns, etc. When an event is
+posted by the module, an event handler is specified, and the PID
+of the relevant task is passed as parameter. For instance, the
+\texttt{endperiod} event is handled by the following function:
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{static
+void EDF\_timer\_endperiod(void *par) }}
+%----------------------------------------------------------------------------
+
+The first thing to do when handling an event is to recover the
+information about the Module that posted the event. This can be
+done with the following statements:
+
+\bigskip{}
+\texttt{PID p = (PID) par;}
+
+\texttt{EDF\_level\_des *lev =}
+
+\begin{center}\texttt{(EDF\_level\_des
+*)level\_table{[}proc\_table{[}p{]}.task\_level{]};}\end{center}
+\bigskip{}
+
+The generic kernel task fields can be referenced as
+\texttt{proc\_table{[}p{]}.name}; the internal data of the Module
+can be referenced as \texttt{lev-}\texttt{\emph{>}}\texttt{field}.
+The EDF task descriptor can be referenced as
+
+\bigskip{}
+\texttt{EDF\_task\_des *td = \&lev->tvec{[}p{]}; }
+\bigskip{}
+
+and the EDF task fields can then be referenced as
+\texttt{td-}\texttt{\emph{>}}\texttt{field}.
+
+By studying the state transition diagram, we see that different
+actions should be taken depending on the state of the task:
+
+\begin{itemize}
+\item If the task state is \texttt{EDF\_ZOMBIE,} the task is
+inserted into the \texttt{freedesc} queue and the allocated
+bandwidth is freed;
+
+\item If the state is \texttt{EDF\_WAIT,} the
+task state is set to \texttt{SLEEP}, so the sporadic task can be
+reactivated;
+
+\item If the state is \texttt{EDF\_IDLE} and the task
+is periodic, it is reactivated by a call to the
+\texttt{EDF\_intern\_release} function. This involves posting a
+deadline event (if \texttt{EDF\_ENABLE\_DL\_CHECK} is set);
+inserting the task in the ready queue; increasing the absolute
+deadline; and telling the kernel that it may need to reschedule by
+calling \texttt{event\_need\_reschedule.}
+
+\item If the state is
+\texttt{EDF\_IDLE} and the task is sporadic, it is marked as late.
+\end{itemize}
+The module also contains the following event handlers:
+
+static void EDF\_timer\_deadline(void *par)
+
+static void EDF\_timer\_offset(void *par)
+
+static void EDF\_timer\_guest\_deadline(void *par)
+
+%----------------------------------------------------------------------------
+\subsection{Public Functions}
+%----------------------------------------------------------------------------
+
+The Module redefines the Level Calls interface. In the following
+paragraphs the implementation of these functions is described.
+
+All the functions of the interface receive a parameter of type
+\texttt{LEVEL} that can be used in a way similar to the parameter
+passed to the event functions to find all the data structures
+needed.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{PID
+EDF\_public\_scheduler(LEVEL l);}}
+%----------------------------------------------------------------------------
+
+This is the Module scheduler that, as all good schedulers, simply
+returns the first task in the ready queue without extracting it.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int
+EDF\_public\_guarantee(LEVEL l, bandwidth\_t *freebandwidth);}}
+%----------------------------------------------------------------------------
+
+The on-line guarantee function simply verifies if there is enough
+free bandwidth for scheduling its tasks. If so, the free bandwidth
+is decremented by the amount used by the Module, and it returns
+that the task set can be guaranteed.
+
+If the guarantee is called after a task creation in the Module, it
+can be the case that the new task, with all the other tasks
+already guaranteed by the Module, uses a bandwidth greater than 1
+(note that the U field can store only numbers in the
+{[}0\ldots{}1{]} interval). In this case, in the function
+\texttt{EDF\_public\_create} a flag is set forcing the guarantee
+algorithm to fail.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int EDF\_public\_create(LEVEL l, PID p, TASK\_MODEL *m);}}
+%----------------------------------------------------------------------------
+
+The function checks if the Model passed as second parameter can be
+handled. In this case, the Module handles all the
+HARD\_TASK\_MODELs that have a correct \texttt{pclass} value and a
+wcet and a period != 0. This function sets the \texttt{period},
+\texttt{flag}, and \texttt{wcet} internal fields of the newly
+created task. The function sets also the \texttt{CONTROL\_CAP}
+flag to inform the Generic Kernel that the execution time have to
+be controlled. Finally, the function allocates the system
+bandwidth in such a way that it can be checked by the guarantee
+algorithm. If the bandwidth allocated for the already guaranteed
+tasks plus the new one is greater than 1, a flag is set to signal
+that the guarantee algorithm must fail.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void EDF\_public\_detach(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function simply reclaims the bandwidth used by the task
+allocated by \texttt{EDF\_public\_create}, disabling the flag set
+by \texttt{EDF\_public\_create} when the guarantee is impossible
+(U>1).
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int EDF\_public\_eligible(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function simply returns 0 because the EDF tasks are always
+eligibles. In fact, the EDF Module does not use the guest
+functions of another Module to handle its tasks.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void EDF\_public\_dispatch(LEVEL l, PID p, int nostop);}}
+%----------------------------------------------------------------------------
+
+To dispatch an EDF task, the task itself must be removed from the
+ready queue. The capacity handling (like the capacity event post)
+is automatically done by the Generic Kernel.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void EDF\_public\_epilogue(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+The function must suspend the running task because it has been preempted or
+because if has finished his capacity. Therefore, the first thing to be done is
+the check of the available capacity. If it is exhausted an exception is raised
+and the task is put into the \texttt{EDF\_WCET\_VIOLATED} \footnote{The task
+shall not be extracted by any queue because the task was extracted by the
+\texttt{EDF\_public\_dispatch} function.} state.
+
+When the task has not consumed all of its capacity it is inserted
+back into the ready queue.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void EDF\_public\_activate(LEVEL l, PID p, struct timespec *t);}}
+%----------------------------------------------------------------------------
+
+This function simply activates the task, inserting it into the
+ready queue. A task can be activated only if it is in the
+\texttt{SLEEP} or in the \texttt{EDF\_WCET\_VIOLATED} state. If
+the task is in the \texttt{EDF\_WAIT} state it means that the task
+is a sporadic task activated too early, so an exception is raised.
+
+The function executes the following steps:
+
+\begin{itemize}
+\item A suitable deadline is computed for the task;
+
+\item The task
+is inserted into the ready queue;
+
+\item A deadline event is posted
+for the task.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void EDF\_public\_unblock(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+The function simply inserts the task into into the ready queue.
+The task was blocked on a synchronization by a call to the
+function \texttt{EDF\_public\_block}.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void EDF\_public\_block(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+The function implements a synchronization block. The function
+simply does nothing, because:
+
+\begin{itemize}
+\item The task was already extracted from the ready queue;
+
+\item
+The capacity event is handled by the Generic Kernel;
+
+\item The
+task state is set by the calling primitive;
+
+\item The deadline
+does not need modifications.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int EDF\_public\_message(LEVEL l, PID p, void *m);}}
+%----------------------------------------------------------------------------
+
+This function implement only the task\_endcycle behavior, doing
+two things:
+
+\begin{itemize}
+\item The \texttt{wcet} of the task is refilled, since the task
+has finished its instance;
+
+\item The task state is set to
+\texttt{EDF\_IDLE} or \texttt{EDF\_WAIT}, waiting the deadline
+arrival.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void EDF\_public\_end(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+The function should erase all the information about the task in
+the data structure of the Module. It simply sets the task state to
+\texttt{EDF\_ZOMBIE}. The deallocation of the bandwidth used by
+the task and the freeing of the task descriptor is performed while
+handling the deadline event.
+
+%----------------------------------------------------------------------------
+\subsection{Private Functions}
+%----------------------------------------------------------------------------
+
+The EDF Module can accept a JOB\_TASK\_MODEL as the Model for the
+Guest Tasks. This Model does not provide information about the
+time that the task will execute. This means that the EDF Module
+does not check the execution time of the task. It must be checked
+by the Module that inserts the tasks as guest tasks. In the
+following paragraphs the guest calls are described.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int EDF\_private\_insert(LEVEL l, PID p, TASK\_MODEL *m);}}
+%----------------------------------------------------------------------------
+
+This function is called by a generic Aperiodic Server Module to
+insert a task into the EDF Module.
+
+The function simply fills the private data structures of the EDF
+Module with the task parameters passed through the Task Model. No
+guarantee is done on the guest tasks (the guarantee of a guest
+task is a responsibility of the Module that calls this function).
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void EDF\_private\_dispatch(LEVEL l, PID p, int nostop);}}
+%----------------------------------------------------------------------------
+
+This function is typically called by the \texttt{task\_dispatch}
+Task Call of the Module that inserts the task as guest task. The
+effect of the call is to extract a task from the ready queue, so
+it is identical to the \texttt{task\_dispatch} Task Call.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void EDF\_private\_epilogue(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function is called when a task is preempted (no capacity are
+handled by the Module). The function simply inserts the task into
+the ready queue.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void EDF\_guest\_activate(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function is called when the Module that inserts the task in
+the system through the EDF\_private\_insert wants to activate it.
+The effect of this function is to insert the task into the ready
+queue and to post a deadline event if the deadline miss should be
+detected for the task (a flag that specifies if the Module should
+generate a deadline is given in the JOB\_TASK\_MODEL.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void EDF\_private\_extract(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function is called by a Module when it wants to terminate a
+task inserted as guest. This function is not called only at task
+termination, but also when the Module has to change some
+parameters for the task (for example, when a deadline should be
+postponed).
+
+The function has to erase all references to the task in the
+private data structures of the EDF Module. Note that this function
+can be called also when the task is not in the EXE state, so all
+task states should be checked for a correct behavior.
+
+%----------------------------------------------------------------------------
+\subsection{Additional Functions exported by the Module}
+%----------------------------------------------------------------------------
+
+Finally, the EDF Module exports two functions that can be used by
+the user.
+
+The first function is the registration function, used to register
+the Module into the system and to init the internal data
+structures.
+
+The second function, \texttt{EDF\_usedbandwidth}, can be used to
+get the bandwidth actually used by the Module. That function needs
+as a parameter the level at which an EDF Module is registered, so
+all the private data structures can be read. Note that giving the
+level of a Module in an application should not be considered a
+violation of the independence of an Application to the Registered
+Modules. If an application wants to know a specific data in a
+Module, it has to know in what level the Module is Registered...
+
+%----------------------------------------------------------------------------
+\section{PS (Polling Server) Scheduling Module}
+%----------------------------------------------------------------------------
+
+In this Section will be described an implementation of a PS Module
+that have the following characteristics:
+
+\begin{itemize}
+\item Soft Aperiodic Task support;
+
+\item On-line guarantee using
+the utilization factor paradigm;
+
+\item Temporal isolation
+implemented without the \texttt{CONTROL\_CAP} flag.
+
+\item Feature
+that allows to use the idle time left by the Modules registered at
+lower level numbers;
+
+\item Support for pending task activations;
+
+\item Compatibility with static (RM) and dynamic (EDF) algorithms.
+\end{itemize}
+
+This Module implements an aperiodic server that inserts its tasks
+into another Scheduling Module, without having any information on
+how the Master Module is implemented. The module described in this
+section is contained in \texttt{modules/ps}.
+
+%----------------------------------------------------------------------------
+\subsection{Transition state diagram}
+%----------------------------------------------------------------------------
+
+In Figure \ref{Examples_PS_Status} the state diagram of a task is
+showed.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=1.0\columnwidth]{images/example_PS_status.eps}
+\end{center}
+\label{Examples_PS_Status}
+\caption{State Diagram of a Task scheduled with the PS Module.}
+\end{figure}
+
+
+The Module introduce only one state, \texttt{PS\_WAIT}. This is
+the state in which a task waits to be inserted in the ``ready
+queue''. The server queue is handled in a FIFO way. The other
+states in which a Module will go are internal states of the Master
+Module.
+
+%----------------------------------------------------------------------------
+\subsection{Private Data structures}
+%----------------------------------------------------------------------------
+
+The PS Module redefines the \texttt{level\_des} structures adding
+some private data structures, listed below:
+
+\begin{description}
+\item [\texttt{nact}]This array is used to track the pending
+activations of a task handled by the Module. Each task element has
+a value of\texttt{-1} (if the task skips the pending activations)
+or a value \texttt{>=0} (that is, the value of pending activations
+for the task);
+
+\item [\texttt{lastdline}]This field is used to
+store the deadline used by the Polling Server;
+
+\item
+[\texttt{period}]This field stores the reactivation period of the
+server;
+
+\item [\texttt{Cs}]This field stores the Maximum capacity
+of the server;
+
+\item [\texttt{availCs}]This field stores the
+computation time available for the server at a given time. The
+capacity is updated when the task handled by the Module is
+scheduled by the Master Module, or when a task handled by the
+Module is dispatched following the shadow chain and the server is
+not scheduling in background;
+
+\item [\texttt{wait}]This field is
+the wait queue, where the tasks wait their turn to be served by
+the Polling Server;
+
+item [\texttt{activated}]This field is the
+PID of the task currently inserted into the Scheduling Module. The
+server inserts in the Master Module maximum one Module at a time;
+
+\item [\texttt{flags}]The flag field is used to store some
+informations passed when the Module was registered, like for
+example the implemented guarantee algorithm (RM or EDF). This
+field is used also to know if the server is executing a task in
+background;
+
+\item [\texttt{U}]This field is used to store an
+information of the used bandwidth by the task handled by the
+Module.
+
+\item [\texttt{scheduling\_level}]This field stores the
+level of the Host Module.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Internal Module Functions}
+%----------------------------------------------------------------------------
+
+The PS Module needs to define some internal functions. These
+functions are called to handle the internal events posted by the
+Module. Many of these functions are declared \texttt{static}, so
+they are not visible externally to the Module.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void PS\_activation(PS\_level\_des *lev);}}
+%----------------------------------------------------------------------------
+
+This function is an inline function and it handles the activation
+of a task into a Master Module. In particular:
+
+\begin{itemize}
+\item It inits a Job Task Model that will be passed to the Master
+Module with the period and the deadline of the Polling Server;
+
+\item It creates and activates through the guest calls the task
+indexed by the private field \texttt{lev->activated}.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void PS\_deadline\_timer(void *a);}}
+%----------------------------------------------------------------------------
+
+This function implements the periodic reactivation of the Polling
+Server. In particular:
+
+\begin{itemize}
+\item a new deadline is computed and a new deadline event is
+posted;
+
+\item the Server capacity is reloaded to the maximum value
+if the available capacity was positive, to a value less than the
+maximum (a ``recharge'' (sum) is done) if negative;
+
+\item If the
+recharge turn the available capacity positive, a waiting task is
+activated, or the capacity available is depleted.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsection{Public Functions}
+%----------------------------------------------------------------------------
+
+All the functions of the interface receives a LEVEL parameter that
+can be used in a way similar to the parameter passed to the event
+functions to get all the private data of the Module.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{PID PS\_level\_scheduler(LEVEL l);}}
+%----------------------------------------------------------------------------
+
+This scheduler is used by the Module if the Module is registered
+specifying that it can not use the idle time left by other
+Modules. It always return \texttt{NIL} (meaning that the module
+has nothing to schedule).
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{PID PS\_level\_schedulerbackground(LEVEL l);}}
+%----------------------------------------------------------------------------
+
+This scheduler is used by the Module if the Module is registered
+specifying that it can use the idle time left by other Modules. It
+sets a flag in the \texttt{flags} field to remember that the
+Module is scheduling a task in background, after that it returns
+the first task in the wait queue. The scheduler is disactived in
+case the task scheduled by the server is blocked on a
+synchronization (look at the function \texttt{PS\_public\_block}).
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int PS\_level\_guaranteeRM(LEVEL l, bandwidth\_t *freebandwidth);}}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int PS\_level\_guaranteeEDF(LEVEL l, bandwidth\_t *freebandwidth);}}
+%----------------------------------------------------------------------------
+
+These two functions implements the internal guarantee of the
+Module, simply decrementing when possible the available bandwidth.
+the difference between the two functions is that the first
+function allow to schedule until a used bandwidth of 0.69, and the
+second one allow a scheduling limit of 1. The structure of this
+function is similar to that of \texttt{EDF\_public\_guarantee},
+except that the guarantee is done on the server and not on each
+task handled by the server..
+
+%----------------------------------------------------------------------------
+\subsection{Task Calls}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int PS\_public\_create(LEVEL l, PID p, TASK\_MODEL *m);}}
+%----------------------------------------------------------------------------
+
+This functions checks if the Task Model passed can be handled by
+the Module. The Module simply handles all the Soft Task Models
+that specify a periodicity equal to APERIODIC, ignoring each
+additional parameters. This function sets the \texttt{nact} field
+on the new task according to the requirements of the task model.
+The function does not set the flag \texttt{CONTROL\_CAP}.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void PS\_public\_detach(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function does nothing, because in the
+\texttt{PS\_public\_create} function no dynamic data structures
+were allocated, and because the tasks served by do not require
+individual guarantee (the guarantee is done for the whole Server).
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int PS\_public\_eligible(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+The function always returns 0 because the PS tasks are always
+eligible.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void PS\_public\_dispatch(LEVEL l, PID p, int nostop);}}
+%----------------------------------------------------------------------------
+
+A task can be dispatched if it is in the wait queue or if it is
+inserted into the Master Module.
+
+In the first case the task is extracted from the \texttt{wait}
+queue, in the latter case the private function
+\texttt{private\_dispatch} is called to signal to the Master
+Module to dispatch the task.
+
+Then, a capacity event is generated (only if the parameter
+\texttt{nostop} is \texttt{0} (the parameter is 0 if there is no
+substitution due to the shadow chain mechanism). The capacity
+event is created using the \texttt{cap\_timer} field. In this way
+the event will be removed by the Generic Kernel.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void PS\_public\_epilogue(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function implements the suspension of the running task due to
+a preemption or a capacity exhaustion.
+
+First, the function updates the server capacity using the
+\texttt{cap\_lasttime} and \texttt{schedule\_time} variables. If
+the server capacity is exhausted, the task that is inserted into
+the Master Module (if the task is not scheduled in background)
+terminates with a \texttt{private\_extract}, and then it is
+inserted in the wait queue.
+
+If the server capacity is not exhausted, there are two cases: if
+the Module is scheduling a task in background, the task will be
+inserted on the head of the wait queue, otherwise the
+\texttt{private\_epilogue} function will be called to signal the
+Master Module a task preemption.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void PS\_public\_activate(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function activates a task. If the task passed as parameter is
+the task currently inserted in the Master Module, or if the task
+is already inserted into the \texttt{wait} queue, the activation
+is stored and the nact field is incremented (only if the task has
+specified in the task model passed at its creation to save the
+activations).
+
+Otherwise the normal activation actions are done:
+
+\begin{itemize}
+\item the field \texttt{request\_time} of the task descriptor is
+updated; \item The task is activated using the internal
+\texttt{PS\_activation} function if there aren't tasks in the
+Module and the server capacity is positive, otherwise the task is
+queued into the wait queue.
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void PS\_public\_block(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+The function should implement the synchronization blocking. The
+function should block the whole server, calling eventually the
+\texttt{private\_extract} guest call on the Master Module and
+setting the \texttt{PS\_BACKGROUND\_BLOCK} flag to block every
+background schedule.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void PS\_public\_unblock(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+The function should reactivate a blocked task. The task
+reactivation consists of its insertion into the \texttt{wait}
+queue and of the reset of the flags set in the
+\texttt{public\_block} function.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int PS\_public\_endcycle(LEVEL l, PID p, void *m);}}
+%----------------------------------------------------------------------------
+
+The function implement the task\_endcycle behavior and does the
+following steps:
+
+\begin{itemize}
+
+\item The server capacity is updated, or the background scheduling
+feature is disabled if it was active;
+
+\item The task was extracted
+from the Master Module through a call to the private function
+\texttt{private\_extract}, otherwise it is extracted from the
+\texttt{wait} queue;
+
+\item If the task has some pending
+activations, it is inserted at the end of the \texttt{wait} queue,
+otherwise the task state is set to \texttt{SLEEP}.
+
+\item If
+possible a new task is extracted from the top of the \texttt{wait}
+queue, through a call to the function \texttt{PS\_activation};
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void PS\_public\_end(LEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+The function directly insert the task into the \texttt{freedesc}
+queue.
+
+%----------------------------------------------------------------------------
+\subsection{Private functions}
+%----------------------------------------------------------------------------
+
+The private functions are not defined (the defaults are used).
+
+%----------------------------------------------------------------------------
+\subsection{Functions exported by the Module}
+%----------------------------------------------------------------------------
+
+Finally, the PS Module exports two functions that can be used by
+the user.
+
+The first function is the registration function, used to register
+the Module in the system and to init the internal data structures.
+This function registers also a initialization function that posts
+the first server deadline event. This event cannot be created in
+the registration function because the registration function is
+called when the OS Lib is not initialized yet.
+
+The second function, \texttt{PS\_usedbandwidth}, can be used to
+obtain the allocated bandwidth of the Module, and it is similar to
+the function \texttt{EDF\_usedbandwidth}.
+
+
+%----------------------------------------------------------------------------
+\section{PI (Priority Inheritance) Resource Module}
+%----------------------------------------------------------------------------
+
+In this Section an implementation of the shared resource access
+protocol Priority Inheritance (PI) \cite{Sha90} is described; it
+has the following characteristics:
+
+\begin{itemize}
+\item support for the Generic Kernel mutex interface;
+
+\item use of
+the shadow mechanism provided by the Generic Kernel;
+
+\item
+independence from the data structures used internally by the
+Scheduling Modules;
+
+\item possibility of a static initialization
+of the used mutexes.
+\end{itemize}
+
+The Module is contained in \texttt{modules/pi}.
+
+%----------------------------------------------------------------------------
+\subsection{Used approach}
+%----------------------------------------------------------------------------
+
+The key idea of the implementation are:
+
+\begin{itemize}
+\item when a task enters into a critical section locking a mutex,
+the Module registers which is the task that owns the mutex,
+because it is used if other tasks try to lock the mutex, and
+because only that task can unlock it;
+
+\item the Module registers
+the number of mutexes that owns the tasks, to check that the task
+does not die with some mutexes locked.
+
+\item when a task tries to
+block a busy mutex, its shadow pointer will be set to the blocking
+task;
+
+\item when a mutex is unlocked, all the task blocked by it
+are freed, so all the blocked tasks can try to acquire the mutex
+(the mutex will be locked by the first task blocked scheduled,
+usually the higher priority task that was blocked);
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\subsection{Private data structures}
+%----------------------------------------------------------------------------
+
+The PI Module defines the structure \texttt{mutex\_resource\_des}
+that handle the interface exported by the Resource Modules. The
+private data structures added by the Module to the interface are
+the following:
+
+\begin{description}
+\item [\texttt{nlocked}]this array stores the number of mutexes
+that each task currently locks;
+
+\item [\texttt{blocked}]this array
+is used to track the blocked tasks on a mutex. Each PI mutex has a
+pointer to the first blocked task; the other tasks are queued in
+this structure (look at Figure\ref{Examples_PI_blocked}). The data
+structure can be allocated locally to the Module because a task
+can be blocked on only one
+mutex.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=1.0\columnwidth]{images/example_PI_blocked.eps}
+\end{center}
+\label{Examples_PI_blocked}
+\caption{Use of the \texttt{blocked} array. The example describes a structure
+\texttt{mutex\_t} initialized with the Priority Inheritance protocol. The field
+\texttt{firstblocked} is the first element of the blocked task queue on a
+specific mutex.}
+\end{figure}
+
+\end{description}
+
+Each mutex handled by the Priority Inheritance protocol uses a
+dynamically allocated internal data structure called
+\texttt{PI\_mutex\_t}, that has the following fields:
+
+\begin{description}
+\item [\texttt{owner}]When the mutex is free this field is
+\texttt{NIL}, else it is the PID of the task that locks the mutex;
+
+\item [\texttt{nblocked}]This is the number of tasks actually
+blocked on a mutex;
+
+\item [\texttt{firstblocked}]When the field
+\texttt{nblocked} is different from 0 this field is the first task
+blocked on a mutex (the following tasks can be found following the
+blocked list ).
+\end{description}
+
+Finally, to init a PI mutex, a correct parameter must be passed to
+\texttt{mutex\_init}. That parameter must be of type
+\texttt{PI\_mutexattr\_t} and it does not add any other parameter
+to the default attribute.
+
+%----------------------------------------------------------------------------
+\subsection{Internal and Interface Functions}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int PI\_res\_register(RLEVEL l, PID p, RES\_MODEL *r);}}
+%----------------------------------------------------------------------------
+
+This function always return -1 because it will never be called by
+the Generic Kernel (because the Module does not accept any
+Resource Model).
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void PI\_res\_detach(RLEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+This function simply controls that the task that is still ending
+does not lock any mutexes. If not, an exception is raised. Such a
+situation is very dangerous because, when a task is died, the
+shadow data structures are not consistent, and this will probably
+cause a system crash.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int PI\_init(RLEVEL l, mutex\_t *m, const mutexattr\_t *a);}}
+%----------------------------------------------------------------------------
+
+This function inits a mutex to be used with the PI Protocol. A
+structure of type \texttt{PI\_mutex\_t} is allocated and all the
+fields are initialized..
+
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int PI\_destroy(RLEVEL l, mutex\_t *m);}}
+%----------------------------------------------------------------------------
+
+This function should destroy a mutex. The mutex has to be
+correctly initialized and it must be free (not locked by a task).
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int PI\_lock(RLEVEL l, mutex\_t *m);}}
+%----------------------------------------------------------------------------
+
+This function should implement a mutex lock. First, a check is
+done to see if the mutex was initializated statically. In that
+case, the initialization of the data structures is completed.
+
+At this point, a check is done to see if the task already owns the
+mutex. If not, a cycle is done. In the body the shadow field is
+set, and the system is rescheduled. The cycle is needed because
+when the mutex will be unlocked, all the blocked tasks will be
+woken up to fight for the locking of the mutex.
+
+Finally, When the mutex will be found free, it is locked.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int PI\_trylock(RLEVEL l, mutex\_t *m);}}
+%----------------------------------------------------------------------------
+
+This function is similar to the previous one, except that the task
+is never blocked if the mutex is busy.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int PI\_unlock(RLEVEL l, mutex\_t *m);}}
+%----------------------------------------------------------------------------
+
+This function should free the mutex. First, a check is done to see
+if the task that unlocks really owns the mutex. Then, the mutex is
+unlocked and all the blocked tasks are woken up (the shadow field
+is reset to point to the blocked tasks themselves). Then, the
+system is rescheduled to see if a preemption should be done (the
+Module does not know if a preemption will occurs or not, because
+it does not know which are the modules registered!).
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void PI\_register\_module(void);}}
+%----------------------------------------------------------------------------
+
+This function will register the Module in the system. This
+function is very similar to the Scheduling Modules Registration
+function.
/branches/new_sharkdoc/vol4/examples.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol4/resource_modules.tex
===================================================================
--- branches/new_sharkdoc/vol4/resource_modules.tex (nonexistent)
+++ branches/new_sharkdoc/vol4/resource_modules.tex (revision 1676)
@@ -0,0 +1,218 @@
+%----------------------------------------------------------------------------
+\chapter{Resource Modules}
+\label{CapModuliRisorsa}
+%----------------------------------------------------------------------------
+
+In this chapter the interface of a Resource Module is described. The semanthic
+of the various functions, and the approach used to handle the Shared Resource
+Access Protocols are described.
+%
+% Tool: such section does not exists.
+%
+% For architectural informations look at
+% Sections\ref{ArchDetail_Moduli_GestioneRisorse} and
+% \ref{ArchDetail_prot_ris_condiv}.
+%----------------------------------------------------------------------------
+\section{Resource Modules Interface}
+%----------------------------------------------------------------------------
+
+The approach used to define the interface of a Resource Module is
+similar to that used for the Scheduling Modules (look at Section
+\ref{CapSchedulingModules}, \ref{SchedModules_Interface} and
+\ref{SchedModules_Convenzioni}).
+
+The interface of a Scheduling Module is less complex than that of the Scheduling
+Modules: only the \textit{create} and \textit{end} events are handled in the
+task life. This choice is made because the Resource Modules usually does not
+influence the scheduling of the system \footnote{Note that a Resource Handling
+Algorithm that modifies the scheduling of the system is more like a Scheduling
+Module than a Resource Module. Some hybrid approaches can be implemented
+requiring that the implementation is made using two Modules that can modify the
+private data of each other.}.
+
+All the functions of a Resource Module are called with Interrupt
+disabled.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int (*res\_register)(RLEVEL l, PID p, RES\_MODEL *r);}}
+%----------------------------------------------------------------------------
+
+This function is called by the Generic Kernel by the
+\texttt{task\_create} primitive to register a Resorce Model into a
+Resource Module.
+
+The function will accept as parameter the index p of the
+descriptor allocated by the Generic Kernel for the task and one of
+the Resource Models passed through the primitive.
+
+The Generic Kernel guarantees that the Resource Model passed in
+this function can be handled by the Module. The function returns 0
+if the Module can handle the request, -1 if the task can not be
+created because the Module can not guarantee the quality of
+service required.
+
+The function will set up the local Module data with the parameters
+of Quality of Service passed with the Resource Model.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{void (*res\_detach)(RLEVEL l, PID p);}}
+%----------------------------------------------------------------------------
+
+The call of this function signals to the Module that the task p is
+terminated, so all internal data structures must be updated.
+
+This function is called independently from the fact that the task
+has or not registered some Resource Model in the Module in two
+cases:
+
+\begin{itemize}
+\item The primitive \texttt{task\_create} fails for some trouble
+inependent from the Module; in this case the function is called
+before the \texttt{public\_detach} function of the Scheduling
+Module that owns the task;
+
+\item The task terminates in the
+correct way; in this case the function is called before the
+function \texttt{public\_end} of the Scheduling Module that owns
+the task.
+\end{itemize}
+
+In other words, this function implemets the behaviour of the
+Scheduling Module's \texttt{public\_detach} and
+\texttt{public\_end} functions. This is correct because the
+Resource Module only react to the creation and termination events.
+It doesn't matter if the task is terminated correctly or if it has
+not been created\ldots{}
+
+%----------------------------------------------------------------------------
+\section{Implementation of the Shared Resource Access Protocols}
+%----------------------------------------------------------------------------
+
+The interface exported by the Resource Modules is used also by the
+Modules that implements the Shared Resource access Protocols.
+
+The problem solved developing these Modules is the project of some
+OS primitives that can be independent from the used protocol, and,
+moreover, independent from a specific Module registered at
+run-time.
+
+%----------------------------------------------------------------------------
+\subsection{Used Approach}
+%----------------------------------------------------------------------------
+
+The approach used is to extend the Resource Module interface; in this way also
+the protocols that requires some per-task parameters can be implemented
+\footnote{For example, these parameters can be the ceiling of a task on a
+Priority Ceiling or SRP protocol}.
+
+Using an Object Oriented approach the hierarchy of the Modules can be described
+(look at Figure\ref{ResMudules_Gerarchia}).
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=9cm]{images/resmodel_Gerarchia.eps}
+\end{center}
+\label{ResMudules_Gerarchia}
+\caption{UML Diagram that shows the class hierarchy that implements the Shared
+Resource AccesProtocols.}
+\end{figure}
+
+These Modules are viewed by the Generic Kernel as Resource Modules. When a mutex
+is initialized some checks \footnote{Similar to those used in the primitive
+\texttt{public\_create} for the Task Models.} are done to find the Module that
+extends the interface in the correct way \footnote{To know that a Module has
+extended the Resource Modules Interface the \texttt{rtype} field is provided
+(look at Section \ref{KernSupport_Descrittore_GestioneRisorse}). }and therefore
+implement the required protocol.
+
+%----------------------------------------------------------------------------
+\subsection{The mutexes}
+%----------------------------------------------------------------------------
+
+The mutexes are stored in the \texttt{mutex\_t} structure showed
+in Figure \ref{ResModules_Fig_mutex_t}. That declaration is
+contained in the file
+\texttt{include/kernel/descr.h.}%
+\begin{figure}
+\begin{center} \fbox{\tt{ \begin{minipage}{6cm} \begin{tabbing}
+123\=123\=123\=\kill
+typedef struct \{ \\
+\>RLEVEL mutexlevel; \\
+\>int use;\\
+\>void *opt;\\
+\} mutex\_t;
+\end{tabbing} \end{minipage} }} \end{center}
+\label{ResModules_Fig_mutex_t}
+\caption{The \texttt{mutex\_t} structure.}
+\end{figure}
+
+The structure contains the following fields:
+
+\begin{description}
+\item [mutexlevel]It is the level which the Module is registered
+in.
+
+\item [use]It tells if the mutex is currently used into a
+synchronization done through condition variables.
+
+\item [opt]This field is a pointer to a structure that the Module can
+dinamically alloc to handle protocol-dependent parameters \footnote{These
+parameters cannot be allocated internally to the Module because the mutexes are
+not statically allocated as task or semaphore descriptors.}.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Interface extension}
+%----------------------------------------------------------------------------
+
+In this section the extension to the Resource Modules is
+described. The proposed functions handles all the events that
+belongs to amutex.
+
+Only the function \texttt{init} is called with interrupts
+disabled. The other functions have to disable the interrupts,
+because there is not a generic behaviour for all these functions
+(for example, the lock of a mutex may be non-blocking on some
+protocols).
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int init(RLEVEL l, mutex\_t *m, mutexattr\_t *a);}}
+%----------------------------------------------------------------------------
+
+This function is called to init a mutex with a protocol. The
+function accepts as parameters the mutex to be initialized and the
+mutex attribute that store the parameters to be used in the
+initialization.
+
+The function returns a value of \texttt{0} if the mutex
+initialization was successful, or an error code otherwise. The
+error codes returned by the functions must be compatibles with the
+functions \texttt{pthread\_mutex\_init} of the POSIX standard.
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int destroy(RLEVEL l, mutex\_t *m);}}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int lock(RLEVEL l, mutex\_t *m);}}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int trylock(RLEVEL l, mutex\_t *m);}}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsubsection{\texttt{int unlock(RLEVEL l, mutex\_t *m);}}
+%----------------------------------------------------------------------------
+
+These functions implements the core functionality of the mutexes
+and they have a semantic similar to the corresponding POSIX
+functions. In particular they receive as parameter a pointer to a
+mutex, and they returns 0 if the operation was successful or an
+error code if not.
+
+These functions have to manage internally the context change in
+the system, because it is not possible to give a fixed rule for
+these functions (for example, the lock operation, that usually can
+block the task, is never a blocking primitive under the SRP
+assumptions).
/branches/new_sharkdoc/vol4/resource_modules.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol5/vol5.tex
===================================================================
--- branches/new_sharkdoc/vol5/vol5.tex (nonexistent)
+++ branches/new_sharkdoc/vol5/vol5.tex (revision 1676)
@@ -0,0 +1,595 @@
+\documentclass[english]{report}
+\usepackage[T1]{fontenc}
+\usepackage[latin1]{inputenc}
+\usepackage{geometry}
+\geometry{verbose,a4paper}
+\usepackage{float}
+\usepackage{makeidx}
+\makeindex
+\usepackage{graphicx}
+
+\makeatletter
+
+\newenvironment{intest}{\noindent\large\bf\hspace*{1pt}}
+{\vspace*{-5pt}\\\line(1,0){433}}
+
+\usepackage{babel}
+\makeatother
+\begin{document}
+\thispagestyle{empty}
+
+\begin{center}{\LARGE S.Ha.R.K. User Manual}\end{center}{\LARGE \par}
+\vfill{}
+
+\begin{center}Volume V\end{center}
+\begin{center}The S.Ha.R.K. New Tracer\end{center} \vfill{}
+\begin{center}Written by\end{center}
+\begin{center}Tullio Facchinetti (tullio.facchinetti at unipv.it)\end{center} \vfill{}
+\begin{center}\includegraphics[width=2cm]{../common/sssup.ps}\end{center}
+\begin{center}Scuola Superiore di Studi e Perfezionamento S. Anna\end{center}
+\begin{center}RETIS Lab\end{center}
+\begin{center}Via Carducci, 40 - 56100 Pisa\end{center}
+
+\pagebreak
+
+\tableofcontents{}
+
+
+\chapter{The S.Ha.R.K. tracer}
+
+The new Tracer is a powerful tool to understand what happens while a
+S.Ha.R.K. \cite{Gai01} application is executed. The Tracer logs
+a set of events corresponding with the most important activities
+within the kernel, such as preemptions, interrupt activations,
+mutexes blocks and releases, and much more.
+
+During the execution, the kernel logs the sequence of events in
+memory; such events are then written to disk or sent through the
+network, typically at the end of the application execution. Each
+event is made by: a high resolution timestamp (TSC, Time Stamp
+Counter) corresponding to the instant at which the event has been
+logged; the event type; 2 optional parameters to add additional
+information to the event.
+
+The Tracer can also be used to log custom events, since it
+reserves a number of free event types for user events.
+
+To use the features made available by the Tracer, the Tracer
+functions must be enabled into the kernel by specifying
+
+~
+
+TRACER = NEW
+
+~
+
+into the \textit{shark.cfg} configuration file. The S.Ha.R.K.
+kernel must be built with this option set.
+
+%----------------------------------------------------------------------------
+\chapter{Primitives}
+%----------------------------------------------------------------------------
+
+\vspace{7mm}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_enable \index{FTrace\_enable}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FTrace\_enable();}]
+\item [\textbf{Description:}] Enable the Tracer. When this function is called, the Tracer starts
+the event logging.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_disable \index{FTrace\_disable}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FTrace\_disable();}]
+\item [\textbf{Description:}] Disable the Tracer. When this function is called, the Tracer stops
+the event logging.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_chunk\_create \index{FTrace\_chunk\_create}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FTrace\_chunk\_create(int normal\_size, int emergency\_size, FTrace\_flags flags);}]
+\item [\textbf{Description:}] Create a new chunk.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_chunk\_delete \index{FTrace\_chunk\_delete}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FTrace\_chunk\_delete(int number);}]
+\item [\textbf{Description:}] Delete a Chunk.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_set\_chunk\_flags \index{FTrace\_set\_chunk\_flags}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FTrace\_set\_chunk\_flags(int number, FTrace\_flags flags);}]
+\item [\textbf{Description:}] Set the chunk flags.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_get\_chunk\_flags \index{FTrace\_get\_chunk\_flags}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FTrace\_get\_chunk\_flags(int number, FTrace\_flags *flags);}]
+\item [\textbf{Description:}] Returns chunk flags.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_actual\_chunk\_select \index{FTrace\_actual\_chunk\_select}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FTrace\_actual\_chunk\_select(int number);}]
+\item [\textbf{Description:}] Select the actual chunk.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_chunk\_link \index{FTrace\_chunk\_link}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FTrace\_chunk\_link(int chunk\_A, int chunk\_B);}]
+\item [\textbf{Description:}] Link two chunks.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_get\_first\_chunk \index{FTrace\_get\_first\_chunk}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FTrace\_get\_first\_chunk(FTrace\_flags flags);}]
+\item [\textbf{Description:}] Find the first chunk with specific flags.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_get\_chunk\_table \index{FTrace\_get\_chunk\_table}
+\end{intest}
+
+\begin{description}
+\item [\textbf{FTrace\_Chunk\_Ptr *FTrace\_get\_chunk\_table();}]
+\item [\textbf{Description:}] Get chunks status.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_compress\_chunk \index{FTrace\_compress\_chunk}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FTrace\_compress\_chunk(int number, FTrace\_flags new\_flags);}]
+\item [\textbf{Description:}] Create a new memory region where the compressed data are stored.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_send\_chunk \index{FTrace\_send\_chunk}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FTrace\_send\_chunk(int number, int osd\_flags,
+FTrace\_flags new\_flags);}]
+\item [\textbf{Description:}] Send the chunk out from the memory.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_init\_disk\_writer \index{FTrace\_init\_disk\_writer}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FTrace\_init\_disk\_writer(char *fname, int flag,
+char *l\_ip, char *t\_ip);}]
+\item [\textbf{Description:}] Initialize the disk Tracer chunk dumper. It sets
+the internal chunk sender to the function that writes chunks on disk. It
+initializes the filename that will be used to open the file for saving chunks.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_disk\_writer \index{FTrace\_disk\_writer}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void FTrace\_disk\_writer(FTrace\_Chunk\_Ptr c);}]
+\item [\textbf{Description:}] This function is called by the application when it
+asks to write chunk c on disk. It saves the chunk data into the chunk\_to\_disk
+array. At the runlevel after the exit, all the saved chunks will be written to
+disk.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_OSD\_init\_udp \index{FTrace\_OSD\_init\_udp}
+\end{intest}
+
+\begin{description}
+\item [\textbf{int FTrace\_OSD\_init\_udp(int flag, char *l\_ip, char *t\_ip);}]
+\item [\textbf{Description:}] Initialize the Tracer chunk network sender using
+the UDP protocol supported by S.Ha.R.K. If flag = 1 initializes the network
+driver, otherwise it considers that the network layer has already been
+initialized. It also sets the internal chunk sender to the function that
+initializes the task for sending the chunk.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+FTrace\_set\_filter \index{FTrace\_set\_filter}
+\end{intest}
+
+\begin{description}
+\item [\textbf{void FTrace\_set\_filter(BYTE family, int status);}]
+\item [\textbf{Description:}] Set the filter for a specific family of events
+(see Table \ref{tab:filter-events} for a list of all the event families). When
+the filter is enabled for a given family of events, all the events belonging to
+that family are not logged.\\
+While \texttt{status} set to 1 enables the filter, \texttt{status}
+set to 0 disables the filter.
+\end{description}
+
+%------------------------------------------------------------
+\begin{intest}
+TRACER\_LOGEVENT \index{TRACER\_LOGEVENT}
+\end{intest}
+
+\begin{description}
+\item [\textbf{TRACER\_LOGEVENT(WORD type, WORD par1, DWORD par2);}]
+\item [\textbf{Description:}] Stores a new event of \texttt{type} type into the
+current chunk, together with the 2 parameters \texttt{par1} (2 bytes) and
+\texttt{par2} (4 bytes).
+\end{description}
+
+%----------------------------------------------------------------------------
+\chapter{Event types description}
+\label{ch:Event-types-description}
+%----------------------------------------------------------------------------
+
+This Chapter reports all the available event type codes currently
+supported by S.Ha.R.K.
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|l|c|c|c|}
+\hline Name & Code & Parameter 1 & Parameter 2 \\ \hline
+\hline FTrace\_EVT\_empty & 0x00 & . & . \\
+\hline FTrace\_EVT\_cycles\_per\_msec & 0x10 & .& [clk/msec] \\
+\hline FTrace\_EVT\_trace\_start& 0x20 & . & . \\
+\hline FTrace\_EVT\_trace\_stop & 0x30& . & . \\
+\hline FTrace\_EVT\_blackout\_start & 0x40 & .& . \\
+\hline FTrace\_EVT\_blackout\_end & 0x50 & .& . \\
+\hline FTrace\_EVT\_id & 0x60 & context& pid \\
+\hline FTrace\_EVT\_numevents & 0x70 & .& . \\
+\hline
+\end{tabular}
+\end{center}
+\caption{General trace events.}
+\end{table}
+
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|l|c|c|c|}
+\hline Name & Code & Parameter 1 & Parameter 2 \\ \hline
+\hline FTrace\_EVT\_ipoint & 0x01 & number & . \\ \hline
+\end{tabular}
+\end{center}
+\caption{Lightweight tracing events.}
+\end{table}
+
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|l|c|c|c|}
+\hline Name & Code & Parameter 1 & Parameter 2 \\ \hline
+\hline FTrace\_EVT\_task\_create & 0x02 & context& pid \\
+\hline FTrace\_EVT\_task\_activate & 0x12 & context & . \\
+\hline FTrace\_EVT\_task\_dispatch & 0x22 & . & . \\
+\hline FTrace\_EVT\_task\_epilogue & 0x32 & . & . \\
+\hline FTrace\_EVT\_task\_end & 0x42 & context & pid \\
+\hline FTrace\_EVT\_task\_begin\_cycle & 0x52 & . & . \\
+\hline FTrace\_EVT\_task\_end\_cycle & 0x62 & context & level \\
+\hline FTrace\_EVT\_task\_sleep & 0x72 & . & . \\
+\hline FTrace\_EVT\_task\_schedule & 0x82 & exec\_shadow.context & exec.context \\
+\hline FTrace\_EVT\_task\_timer & 0x92 & context & level \\
+\hline FTrace\_EVT\_task\_disable& 0xA2 & . & . \\
+\hline FTrace\_EVT\_task\_deadline\_miss & 0xB2 & context & . \\
+\hline FTrace\_EVT\_task\_wcet\_violation & 0xC2 & context& . \\
+\hline
+\end{tabular}
+\end{center}
+\caption{Task related events.}
+\end{table}
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|l|c|c|c|}
+\hline Name & Code & Parameter 1 & Parameter 2 \\ \hline
+\hline FTrace\_EVT\_interrupt\_start & 0x03 & int & . \\
+\hline FTrace\_EVT\_interrupt\_end & 0x13 & int & . \\
+\hline FTrace\_EVT\_interrupt\_hit & 0x23 &
+\multicolumn{2}{c|}{Instant where interrupt was hit (no end)} \\
+\hline FTrace\_EVT\_interrupt\_count & 0x33 &
+\multicolumn{2}{c|}{Number of interrupts raised since last interrupt\_count} \\
+\hline
+\end{tabular}
+\end{center}
+\caption{Interrupt events, even more lightweight than ipoints.}
+\end{table}
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|l|c|c|c|}
+\hline Name & Code & Parameter 1 & Parameter 2 \\ \hline
+\hline FTrace\_EVT\_to\_real\_mode & 0x04 & . & . \\
+\hline FTrace\_EVT\_to\_protected\_mode & 0x14 & . & . \\
+\hline FTrace\_EVT\_CLI & 0x24 & . & . \\ \hline
+FTrace\_EVT\_STI & 0x34 & . & . \\ \hline
+\end{tabular}
+\end{center}
+\caption{Other CPU specific events.}
+\end{table}
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|l|c|c|c|}
+\hline Name & Code & Parameter 1 & Parameter 2 \\ \hline
+\hline FTrace\_EVT\_set\_priority & 0x05 & . & . \\
+\hline FTrace\_EVT\_context\_switch & 0x15 & context& . \\
+\hline FTrace\_EVT\_inheritance & 0x25 & exec\_shadow.context & exec.context \\
+\hline
+\end{tabular}
+\end{center}
+\caption{Changes on task attributes and state.}
+\end{table}
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|l|c|c|c|}
+\hline Name & Code & Parameter 1 & Parameter 2 \\ \hline
+\hline FTrace\_EVT\_set\_mutex\_create & 0x06 & . & . \\
+\hline FTrace\_EVT\_set\_mutex\_lock & 0x16 & context& mutex \\
+\hline FTrace\_EVT\_set\_mutex\_inherit & 0x26 & . & . \\
+\hline FTrace\_EVT\_set\_mutex\_unlock & 0x43 & context & mutex \\
+\hline FTrace\_EVT\_set\_mutex\_wait & 0x46 & context & mutex \\
+\hline FTrace\_EVT\_set\_mutex\_post & 0x56 & context& mutex \\
+\hline
+\end{tabular}
+\end{center}
+\caption{Mutex events.}
+\end{table}
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|l|c|c|c|}
+\hline Name & Code & Parameter 1 & Parameter 2 \\ \hline
+\hline FTrace\_EVT\_signal & 0x07 & . & . \\
+\hline
+\end{tabular}
+\end{center}
+\caption{Signal events.}
+\end{table}
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|l|c|c|c|}
+\hline Name & Code & Parameter 1 & Parameter 2 \\ \hline
+\hline FTrace\_EVT\_server\_create & 0x08 & . & server \\
+\hline FTrace\_EVT\_server\_replenish & 0x18 & .& server \\
+\hline FTrace\_EVT\_server\_exhaust & 0x28 & . & server \\
+\hline FTrace\_EVT\_server\_reclaiming & 0x38 & . & server \\
+\hline FTrace\_EVT\_server\_remove & 0x48 & . & server \\
+\hline FTrace\_EVT\_server\_active & 0x58 & . & server \\
+\hline FTrace\_EVT\_server\_using\_rec & 0x68 & reclaiming & server \\
+\hline
+\end{tabular}
+\end{center}
+\caption{Specific server events.}
+\end{table}
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|l|c|c|c|}
+\hline Name & Code & Parameter 1 & Parameter 2 \\ \hline
+\hline FTrace\_EVT\_user\_event\_0 & 0x09 & free & free \\
+\hline FTrace\_EVT\_user\_event\_1 & 0x19 & free & free \\
+\hline FTrace\_EVT\_user\_event\_2 & 0x29 & free & free \\
+\hline FTrace\_EVT\_user\_event\_3 & 0x39 & free & free \\
+\hline FTrace\_EVT\_user\_event\_4 & 0x49 & free & free \\
+\hline FTrace\_EVT\_user\_event\_5 & 0x59 & free & free \\
+\hline FTrace\_EVT\_user\_event\_6 & 0x69 & free & free \\
+\hline FTrace\_EVT\_user\_event\_7 & 0x79 & free & free \\
+\hline FTrace\_EVT\_user\_event\_8 & 0x89 & free & free \\
+\hline FTrace\_EVT\_user\_event\_9 & 0x99 & free & free \\
+\hline FTrace\_EVT\_user\_event\_10 & 0xA9 & free & free \\
+\hline FTrace\_EVT\_user\_event\_11 & 0xB9 & free & free \\
+\hline FTrace\_EVT\_user\_event\_12 & 0xC9 & free & free \\
+\hline FTrace\_EVT\_user\_event\_13 & 0xD9 & free & free \\
+\hline FTrace\_EVT\_user\_event\_14 & 0xE9 & free & free \\
+\hline
+\end{tabular}
+\end{center}
+\caption{User defined events.}
+\end{table}
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|l|c|c|c|}
+\hline Name & Code & Parameter 1 & Parameter 2 \\ \hline
+\hline FTrace\_EVT\_timer\_post & 0x0B & . & . \\
+\hline FTrace\_EVT\_timer\_delete & 0x1B & . & . \\
+\hline FTrace\_EVT\_timer\_wakeup\_start & 0x2B & . & . \\
+\hline FTrace\_EVT\_timer\_wakeup\_end & 0x3B & context & . \\
+\hline
+\end{tabular}
+\end{center}
+\caption{Timer events.}
+\end{table}
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|l|c|c|c|}
+\hline Name & Code & Parameter 1 & Parameter 2 \\ \hline
+\cline{1-1} \cline{2-2} FTrace\_EVT\_data\_pointer & 0x1A &
+\multicolumn{2}{c|}{holds a pointer of data from} \\
+\cline{1-1} \cline{2-2} FTrace\_EVT\_next\_chunk & 0xFF &
+\multicolumn{2}{c|}{previous event} \\
+\hline
+\end{tabular}
+\end{center}
+\caption{Generic data events.}
+\end{table}
+
+\begin{table}
+\begin{center}
+\begin{tabular}{|l|c|}
+\hline Name & Code \\ \hline
+\hline FTrace\_filter\_trace\_Events & 0xF0 \\
+\hline FTrace\_filter\_ipoint & 0xF1 \\
+\hline FTrace\_filter\_task & 0xF2 \\
+\hline FTrace\_filter\_interrupt & 0xF3 \\
+\hline FTrace\_filter\_CPU & 0xF4 \\
+\hline FTrace\_filter\_priority & 0xF5 \\
+\hline FTrace\_filter\_mutex & 0xF6 \\
+\hline FTrace\_filter\_signal & 0xF7 \\
+\hline FTrace\_filter\_server & 0xF8 \\
+\hline FTrace\_filter\_user & 0xF9 \\
+\hline FTrace\_filter\_data & 0xFA \\
+\hline FTrace\_filter\_timer & 0xFB \\
+\hline FTrace\_family\_mask & 0x0F \\
+\hline
+\end{tabular}
+\end{center}
+\caption{Filter management.}
+\label{tab:filter-events}
+\end{table}
+
+%----------------------------------------------------------------------------
+\chapter{Example of Tracer usage}
+%----------------------------------------------------------------------------
+
+\begin{verbatim}
+/* Declarations */
+int a,b,c;
+SYS_FLAGS f;
+
+/* Create 3 chunks for storing the tracer events. */
+a = FTrace_chunk_create(1000000, 1000000, FTRACE_CHUNK_FLAG_FREE | FTRACE_CHUNK_FLAG_CYC);
+b = FTrace_chunk_create(1000000, 1000000, FTRACE_CHUNK_FLAG_FREE | FTRACE_CHUNK_FLAG_JTN);
+c = FTrace_chunk_create(1000000, 1000000, FTRACE_CHUNK_FLAG_FREE | FTRACE_CHUNK_FLAG_CYC);
+
+FTrace_chunk_link(a,b);
+FTrace_chunk_link(b,c);
+
+/* Select the first chunk for saving the events. */
+FTrace_actual_chunk_select(a);
+
+/* Start the tracer. */
+FTrace_enable();
+
+/* Enable filtering for timer related events. */
+FTrace_set_filter(FTrace_filter_timer, 1);
+TRACER_LOGEVENT(FTrace_EVT_trace_start, proc_table[exec_shadow].context, clk_per_msec);
+
+for (i = 0; i < 10; i++)
+ if (proc_table[i].context != 0)
+ TRACER_LOGEVENT(FTrace_EVT_id, (unsigned short int)proc_table[i].context, i);
+
+/* do something */
+
+/** Enable filtering for timer related events. */
+FTrace_set_filter(FTrace_filter_timer, 0);
+
+/** Change the chunk where the events are stored. */
+TRACER_LOGEVENT(FTrace_EVT_next_chunk, 0, 0);
+TRACER_LOGEVENT(FTrace_EVT_ipoint, 6000, 0);
+
+/* do something */
+
+/* Store a TFrace stop event. */
+TRACER_LOGEVENT(FTrace_EVT_trace_stop, 0, 0);
+
+/* Stop the tracer. */
+FTrace_disable();
+
+/* Initialize the network for remotely saving the trace. */
+FTrace_OSD_init_udp(1, "192.168.1.10", "192.168.1.1");
+
+/*
+ * If want to save the events to disk, simply change
+ * the network initialization instruction with the following line:
+ * FTrace_init_disk_writer("trace.dat", 0, NULL, NULL);
+ *
+ */
+
+/* Save the chunk. */
+FTrace_send_chunk(a, 0, FTRACE_CHUNK_FLAG_FREE | FTRACE_CHUNK_FLAG_CYC);
+FTrace_send_chunk(b, 0, FTRACE_CHUNK_FLAG_FREE | FTRACE_CHUNK_FLAG_JTN);
+\end{verbatim}
+
+%----------------------------------------------------------------------------
+\chapter{Tracer output}
+%----------------------------------------------------------------------------
+
+When the trace is saved, locally or remotely, into a file, the
+resulting binary file appears as a sequence of bytes where each
+event stored within the trace output file is 16 bytes long. The
+format of each single event is depicted in Table \ref{tab:format}.
+
+The fields have the following meaning:
+
+\begin{itemize}
+\item Code represents the event type (see Chapter
+\ref{ch:Event-types-description} for the full list);
+\item Parameter 1 and 2 are the parameters used when \texttt{TRACER\_LOGEVENT}
+is invoked;
+\item TSC is the Time Stamp Counter associated with the event;
+\end{itemize}
+
+If \texttt{ptr} points to the first byte of an event, the correct TSC value
+can be obtained with the following instructions:
+
+\begin{verbatim}
+unsigned long long tsc_value;
+tsc_value = (unsigned long long)(*(unsigned int *)(ptr + 4)) << 32;
+tsc_value += (unsigned long long)(*(unsigned int *)(ptr + 8));
+\end{verbatim}
+
+\begin{table}
+\begin{center}\begin{tabular}{|c|c|c|c|c|}
+\hline Code & Parameter 1 & TSC (high part) & TSC (low part) & Parameter 2 \\
+\hline 2 bytes & 2 bytes & 4 bytes & 4 bytes & 4 bytes \\
+\hline
+\end{tabular}\end{center}
+\caption{Event output file format.}
+\label{tab:format}
+\end{table}
+
+\printindex{}
+
+\bibliographystyle{alpha}
+\bibliography{../common/biblio}
+
+\end{document}
/branches/new_sharkdoc/vol5/vol5.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol5/makefile
===================================================================
--- branches/new_sharkdoc/vol5/makefile (nonexistent)
+++ branches/new_sharkdoc/vol5/makefile (revision 1676)
@@ -0,0 +1,4 @@
+MAIN = vol5
+MAIN_NAME = vol5
+
+include ../common/manual.mk
/branches/new_sharkdoc/vol5/makefile
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/changes.txt
===================================================================
--- branches/new_sharkdoc/changes.txt (nonexistent)
+++ branches/new_sharkdoc/changes.txt (revision 1676)
@@ -0,0 +1,27 @@
+manuals directory
+- restyled in order to automatically build manuals
+
+all volumes
+- manuals are now in Latex, exported from Lyx
+- corrected the Latex exported from Lyx;
+- all code moved into verbatim environments;
+
+vol1
+- hartport doc moved to vol-oldcontent;
+- shark.cfg fully documented;
+
+vol2
+- updated linuxc26 doc;
+- changed code using sys_end;
+- updated IntDrive documentation;
+- updated IntDrive example code;
+- added references to scientific papers;
+
+vol5
+- new S.Ha.R.K. tracer almost fully documented from scratch;
+
+vol-oldcontent
+- included hartport documentation;
+
+TODO
+- add references to vol6;
/branches/new_sharkdoc/changes.txt
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/vol6.tex
===================================================================
--- branches/new_sharkdoc/vol6/vol6.tex (nonexistent)
+++ branches/new_sharkdoc/vol6/vol6.tex (revision 1676)
@@ -0,0 +1,2703 @@
+\documentclass[english]{report}
+\usepackage[T1]{fontenc}
+\usepackage[latin1]{inputenc}
+\usepackage{a4wide}
+\setcounter{secnumdepth}{3} \setcounter{tocdepth}{3}
+\usepackage{graphicx}
+
+\makeatletter
+
+\usepackage{babel}
+\makeatother
+
+\begin{document}
+
+\thispagestyle{empty}
+
+\begin{center}{\LARGE S.Ha.R.K. User Manual}\end{center}{\LARGE \par} \vfill{}
+
+\begin{center}{\large Volume VI}\end{center}
+
+\begin{center}S.Ha.R.K. File System\end{center} \vfill{}
+
+\begin{center}Written by\end{center}
+\begin{center}Paolo Gai (pj at sssup.it)\end{center}
+\begin{center}Tullio Facchinetti (tullio.facchinetti at unipv.it)\end{center}
+\begin{center}Original italian version by\end{center}
+\begin{center}Massimiliano Giorgi (massy at gandalf.sssup.it)\end{center}
+\vfill{}
+
+\begin{center}\includegraphics[width=2cm]{../common/sssup.ps}\end{center}
+
+\begin{center}Scuola Superiore di Studi e Perfezionamento S. Anna\end{center}
+\begin{center}RETIS Lab\end{center}
+\begin{center}Via Carducci, 40 - 56100 Pisa\end{center}
+\begin{center}\pagebreak\end{center}
+
+\tableofcontents{}
+
+\listoffigures
+
+\listoftables
+
+\begin{abstract}
+This is the documentation about S.Ha.R.K. File system. The document gives an
+insight on many data structures used internally by the file system. This is the
+first step toward a \emph{true} file system user manual. If you carefully read
+it, you will understand how it works, how can be initialized and used.
+
+In any case, please send any comments to pj@sssup.it.
+
+Enjoy,
+
+Paolo
+\end{abstract}
+
+%----------------------------------------------------------------------------
+\chapter{File system architecture}
+\label{sec:arch}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\section{Features}
+%----------------------------------------------------------------------------
+
+\label{sec:arch:gen}The library is composed by two main layers:
+
+\begin{description}
+\item [File-system] The file system contains all the data structures used to
+handle files.
+\item [Blocks~devices]This part handles directly the hardware. They provide a
+common interface that unifies the usage of all the block devices (i.e., the hard
+disks).
+\end{description}
+
+The architecture of the library is modular, and it is described in
+Figure \ref{fig:Filesystem-architecture}.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=6cm]{images/arch2.eps}
+\end{center}
+\caption{File system architecture}
+\label{fig:Filesystem-architecture}
+\end{figure}
+
+The library is connected to the Kernel via a \emph{glue} layer, to
+the application via a \emph{wrapper} layer; the block devices and
+the file system operations are separated by a cache, that may be
+excluded.
+
+\label{sec:arch:req}
+
+The library needs a set of primitives that must be supported by
+the underlying kernel, as memory handling, string handling, and
+functions with a variable number of parameters. Moreover, the
+kernel should support functions that implement:
+
+\begin{itemize}
+\item Mutual exclusion.
+\item Allocation of low level resources (as I/O spaces and interrupts).
+\item Memory protection (not needed in S.Ha.R.K.).
+\end{itemize}
+
+%----------------------------------------------------------------------------
+\section{Low Level: Device Drivers}
+%----------------------------------------------------------------------------
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=6cm]{images/archlow.eps}
+\end{center}
+\caption{Device Drivers}
+\label{fig:archlow}
+\end{figure}
+
+The device drivers are divided in two main parts:
+
+\begin{itemize}
+\item A general part that exports the basic low level services. It
+also gives a set of internal routines to the internal modules.
+\item A set of internal modules that handle one or more
+peripherals. The application can choose which module must be
+linked, initialized and used at compile time.
+\end{itemize}
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=6cm]{images/archlow2.eps}
+\end{center}
+\caption{Device Drivers - details}
+\label{fig:archlow2}
+\end{figure}
+
+The general part is composed by four modules:
+
+\begin{description}
+\item [Block~device]The main part; it exports the interface to the upper layers,
+inits the device driver subsystem and register all the drivers present in the
+system.
+\item [Logical~disk]This module provides functions that allow to inspect the
+logical structure of an hard disk, like start, end, size and type of each
+partition on the Hard Disk.
+\item [Physical~disk]This module provide a small data base that contains
+informations about all the hard disks in the system; these informations can be
+useful for the module that must handle the low level pending request queues.
+\item [Queue~policy]This module handles the low level policies for the pending
+requests (SCAN, LOOK, EDF, ...).
+\end{description}
+
+%----------------------------------------------------------------------------
+\section{High Level: File systems}
+%----------------------------------------------------------------------------
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=10cm]{images/archhigh.eps}
+\end{center}
+\caption{High Level - File system details}
+\label{fig:archhigh}
+\end{figure}
+
+The high level is divided in three parts:
+
+\begin{itemize}
+\item The first part handle the file systems, its initialization and its
+interface to the internal modules.
+\item A second part composed by a set of modules that implement a particular
+file system (i.e., FAT16).
+\item A cache module (whose policy can be easily changed).
+\end{itemize}
+
+The first part is composed by sub-modules (internal implementation
+of a sub-module can be changed without affecting the rest of the
+library):
+
+\begin{description}
+\item [Filesystems]It is responsible for the initialization and termination of
+all the high level layer. It registers all the file systems, and it contains the
+routines for mounting/unmounting the partitions.
+\item [File]It handles the descriptor tables and the files; it defines the
+\texttt{file} structure.
+\item [Super]It handles the super blocks (that contains the global informations
+about partitions on a disk).
+\item [Inodes]It handles the inodes (informations about a file in the file
+system).
+\item [Dentry]It handles file names in a tree structure.
+\item [Open,~read,~umask,~...]They implement the correspondent system
+primitives.
+\end{description}
+
+%----------------------------------------------------------------------------
+\chapter{Device drivers}
+\label{sec:dd}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\section{Interface}
+\label{sec:dd:interfaccia}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsection{Initialization}
+\label{sec:dd:interfaccia:init}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+typedef struct bdev_parms {
+ __uint32_t showinfo;
+ char *config;
+ void *bmutexattr;
+ __uint16_t dummy;
+#ifdef IDE_BLOCK_DEVICE
+ IDE_PARMS ideparms;
+#endif
+} BDEV_PARMS;
+
+void bdev_def_showinfo (BDEV_PARMS s, int v);
+void bdev_def_configstring(BDEV_PARMS s, char *v);
+void bdev_def_mutexattrptr(BDEV_PARMS s,void *v);
+\end{verbatim}
+\caption{The BDEV\_PARMS structure}
+\label{tab:BDEV_PARMS}
+\end{table}
+
+The bdev\_init() function (see Table \ref{tab:BDEV_PARMS}) must be
+called to initialize a device driver, passing a pointer to a
+BDEV\_PARMS structure. Use the provided macros to init that
+structure.
+
+The structure is composed by two parts: a generic part and a
+specific part. The generic part is composed by the following
+fields:
+
+\begin{description}
+\item [showinfo]If this flag is set, the initialization of the device will be
+``verbose''. To set this flag, use the macro bdev\_def\_showinfo.
+\item [config]It is a string that can have a particular meaning for the device
+driver. The string is parsed by the device driver, that usually searches for
+some initialization parameter (something like ``foo:[number]''). To set this
+string, use the macro bdev\_def\_configstring.
+\item [bmutexattr]This parameter can be used to tell the system which is the
+kind of mutex to use to implement the mutual exclusion. To set this parameter,
+use the macro \texttt{bdev\_def\_mutexattrptr}.
+\item [dummy]Used to align the data structure (see the macro BASE\_DEV).
+\end{description}
+
+The specific part is directly specified by the device driver; the
+bdev\_init function can be called can be called passing a pointer
+to a BDEV\_PARMS structure initialized with a BASE\_BDEV value. If
+NULL is specified, the default values are used.
+
+%----------------------------------------------------------------------------
+\subsubsection{How to create a new device driver}
+%----------------------------------------------------------------------------
+
+\begin{enumerate}
+\item Add a new \emph{major} number in t the file include/fs/major.h (see
+\ref{sec:dd:interfaccia:nomi});
+\item Add a ``\#define'' into the file include/fs/bdevconf.h (to enable
+selective compilation);
+\item If needed, add fields to bdev\_parms, and modify the BASE\_BDEV macro with
+the new default parameters;
+\item Modify the function bdev\_init to call the init function of the new device
+driver (into drivers/block/bdev.c).
+\end{enumerate}
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=7cm]{images/ddinit.eps}
+\end{center}
+\caption{Device Drivers Initialization.}
+\label{fig:ddinit}
+\end{figure}
+
+The device driver initialization function, after the
+initialization of its internal part, does the following actions
+(see Figure \ref{fig:ddinit}):
+
+\begin{enumerate}
+\item It registers itself calling bdev\_register(); That function must be called
+for each device handled by the driver.
+\item It registers every block device that it find into its interfaces to the
+Physical Disk Module.
+\item It registers every logical device found calling bdev\_register\_minor().
+\end{enumerate}
+
+Data structures and registration functions used in this phased are
+described in Section \ref{sec:dd:interfaccia:det}.
+
+%----------------------------------------------------------------------------
+\subsection{Device serial number}
+\label{sec:dd:interfaccia:nomi}
+%----------------------------------------------------------------------------
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=7cm]{images/devtype.eps}
+\end{center}
+\caption{Device Serial Number}
+\label{tab:devtype}
+\end{figure}
+
+Every logical device (i.e., a logical partition of a hard disk)
+has a device serial number of type \_\_dev\_t, that must have a
+unique value (see the POSIX standard).
+
+The number has an internal structure (see Figure
+\ref{tab:devtype}) composed by a \emph{major} \emph{number}, and
+another number (whose number depends on the device implementation)
+called \emph{minor} \emph{number}.
+
+Three macro exists (see include/fs/sysmacro.h) to handle the
+device numbers:
+
+\begin{description}
+\item [makedev]This macro creates a \_\_dev\_t number from the major and the
+minor number.
+\item [major]Returns the major number of a device.
+\item [minor]Returns the minor number of a device.
+\end{description}
+
+The major number is used to decide which device driver will handle
+a request (see Section \ref{sec:dd:interfaccia:det}). A device
+driver can register more than on major number. Minor numbers are
+device driver dependent, and the validity of a minor number is
+checked only by the driver.
+
+To simplify the search of a device, every device has a symbolic
+name (see Section \ref{sec:dd:intercaccia:ext}). Symbolic names
+are composed by two parts: a unique name for each major, and a
+specific name assigned to each minor. For example, the major
+MAJOR\_B\_IDE has a symbolic name ``ide''; a minor name for that
+major can be ``hda2'', so the full name is ``ide/hda2'', that
+identifies the second partition on the master hard disk on the
+first IDE controller interface (see Section \ref{sec:dd:ide}).
+
+%----------------------------------------------------------------------------
+\subsection{Implementation details}
+\label{sec:dd:interfaccia:det}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+int bdev_register(__dev_t major, char *name, struct block_device *);
+int bdev_register_minor(__dev_t device, char *name, __uint8_t fsind);
+struct phdskinfo *phdsk_register( struct phdskinfo *disk);
+\end{verbatim}
+\caption{Block device registration functions}
+\label{tab:Block_register}
+\end{table}
+
+These are the registration functions for the device drivers (see
+Table \ref{tab:Block_register}):
+
+\begin{description}
+\item [bdev\_register]This function registers a device type (see Section
+\ref{sec:dd:interfaccia:nomi}); the function receives as parameter the major
+number, its symbolic name, and a pointer to a structure block\_device. The
+function returns 0 in case of success, != 0 otherwise.
+\item [bdev\_register\_minor]It registers a minor number, its symbolic name and
+the file system type (see include/fs/fsind.h). This information is used by
+bdev\_finddevice\_byname (see Section \ref{sec:dd:intercaccia:ext}). The
+function returns 0 in case of success, != 0 otherwise.
+\item [phdsk\_register]This function is used to register every physical device
+found with parameters that can be used by the Disk Scheduling Algorithms (see
+Section \ref{sec:dd:sched}). This function receives a pointer to a structure
+phdiskinfo that contains the device parameters, and returns NULL in case of
+error, or a pointer to the registered structure (that can be != from the
+parameter) in case of success.
+\end{description}
+
+\begin{table}
+\begin{verbatim}
+struct dskgeometry {
+ __uint16_t cyls;
+ __uint16_t heads;
+ __uint16_t sectors;
+};
+
+struct phdskinfo \{
+ char pd_name[MAXPHDSKNAME];
+ __dev_t pd_device;
+ __blkcnt_t pd_size;
+ int pd_sectsize;
+ struct dskgeometry pd_phgeom;
+ struct dskgeometry pd_logeom;
+};
+\end{verbatim}
+\caption{The phdsk structure.}
+\label{tab:structphdsk}
+\end{table}
+
+The phdskinfo structure contains the physical parameters of a
+device. all the field must be filled before calling
+phdsk\_register. The fields are:
+
+\begin{description}
+\item [pd\_name]device name, used only for debug purposes;
+\item [pd\_device]device identificator;
+\item [pd\_size]number of logical sectors of the device;
+\item [pd\_sectsize]Dimension (bytes) of a logical sector;
+\item [pd\_phgeom~e~pd\_logeom]geometry of the device (logical and phisical);
+geometries are described using the struct dskgeometry (see Table
+\ref{tab:structphdsk}):
+
+\begin{description}
+\item [cyls]number of cylinders (traces) of the device;
+\item [heads]number of heads;
+\item [sectors]number of sectors for each cylinder.
+\end{description}
+\end{description}
+
+\begin{table}
+\begin{verbatim}
+struct block_device {
+ char *bd_name;
+ int bd_sectorsize;
+ __uint32_t bd_flag_used:1;
+ struct block_device_operations *bd_op;
+};
+\end{verbatim}
+\caption{block\_device Structure}
+\label{tab:structbdev}
+\end{table}
+
+The struct block\_device described in Table \ref{tab:structbdev}
+is used to register the block devices:
+
+\begin{description}
+\item [bd\_name]Physical device name; for example, for the IDE device driver,
+``ide''.
+\item [bd\_sectorsize]logical sector dimension (bytes; redundant info but
+useful).
+\item [bd\_flag\_used]It should not modified by the device drivers. If set, the
+corresponding device driver is present (a table of all the possible devices is
+used to access the system in a fast way).
+\item [bd\_op]Virtual device operations.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsubsection{block\_device\_operation structure.}
+\label{sec:dd:interfaccia:det:bdevop}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+struct block_device_operations {
+ int (*_trylock) (__dev_t device);
+ int (*_tryunlock)(__dev_t device);
+ int (*read) (__dev_t device, __blkcnt_t blocknum, __uint8_t *buffer);
+ int (*seek) (__dev_t device, __blkcnt_t blocknum);
+ int (*write) (__dev_t device, __blkcnt_t blocknum, __uint8_t *buffer);
+};
+\end{verbatim}
+\caption{block\_device\_operations structure.}
+\label{tab:structbdevop}
+\end{table}
+This structure contains the virtual operation that have to be
+supplied by every device driver:
+
+\begin{description}
+\item [read]This function should read a logical pblock passed as parameter,
+writing the result on the buffer. It returns 0 in case of success, != 0
+otherwise.
+\item [write]Similar to read, but it writes.
+\item [seek]moves the head on the required block.
+\item [\_trylock~e~\_tryunlock]Used to block/unblock a device. They return 0 in
+case of success, != 0 otherwise; after initialization, and usually, every device
+is in the unblocked state.
+\end{description}
+
+Why blocking/unblocking a device? The problem, described in
+Section \ref{sec:dcache}, is that the data cache have to refer to
+a logical block in an unique way. Since there are logical devices
+that shares blocks (think at /dev/hda and /dev/hda2 in Linux), the
+mount operation must be done in mutual exclusion, blocking the
+device.
+
+%----------------------------------------------------------------------------
+\subsubsection{The ``lodsk'' module}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+struct lodskinfo {
+ __uint8_t fs_ind;
+ __blkcnt_t start;
+ __blkcnt_t size;
+};
+typedef int (*lodsk_callback_func)(int, struct lodskinfo*, void *);
+int lodsk_scan(__dev_t device, lodsk_callback_func func, void *data, int
+showinfo, char *lname);
+\end{verbatim}
+\caption{The lodsk module}
+\label{tab:lodsk}
+\end{table}
+
+This module (see Table \ref{tab:lodsk}) offer a service to the
+device drivers: It recognizes the logical structure (partitions)
+of an HD as described into \cite{manual:DOS330} (part of the code
+is derived from Linux).
+
+before calling lodsk\_scan, the device driver must be already
+registered; the function has five parameters:
+
+\begin{enumerate}
+\item The device ID where the search have to be done.
+\item A callback function called for each partition found.
+\item A generic pointer passed to the callback function.
+\item A verbose flag.
+\item The name of the logical device (i.e., ``hdb'', used if the verbose option
+has been set.
+\end{enumerate}
+
+Each callback function is called passing as arguments:
+
+\begin{enumerate}
+\item The logical number of the partition (the Linux numbering scheme is used).
+\item A structure with informations on the partition found. The structure has
+the following fields:
+
+\begin{description}
+\item [fs\_ind]The file system number (see include/fs/fsind.h).
+\item [start]The partition starting block.
+\item [size]The partition size (number of blocks).
+\end{description}
+\item A the generic pointer passed to lodsk\_scan.
+\end{enumerate}
+
+The low\_level routines always check these values to avoid
+read/write operations outside the partition.
+
+%----------------------------------------------------------------------------
+\subsubsection{Semaphores}
+%----------------------------------------------------------------------------
+
+The files include/fs/mutex.h and include/fs/semaph.h contain the
+mutex/semaphore interface used by the file system.
+
+\begin{table}
+\begin{verbatim}
+typedef internal_sem_t __sem_t;
+
+#define __sem_init (ptr,val)
+#define __sem_wait (ptr)
+#define __sem_trywait (ptr)
+#define __sem_signal (ptr)
+\end{verbatim}
+\caption{The semaphore interface}
+\label{tab:semaph}
+\end{table}
+
+In particular, the semaphore interface (see Table
+\ref{tab:semaph}) is simply a wrapper to the S.Ha.R.K. Internal
+Semaphores.
+
+\begin{table}
+\begin{verbatim}
+typedef internal_sem_t __mutex_t;
+
+#define __mutex_init (ptr,attr)
+#define __mutex_lock (ptr)
+#define __mutex_trylock (ptr)
+#define __mutex_unlock (ptr)
+
+typedef SYS_FLAGS __fastmutex_t;
+
+#define __fastmutex_init (ptr)
+#define __fastmutex_lock (ptr)
+#define __fastmutex_unlock (ptr)
+\end{verbatim}
+\caption{The mutex interface}
+\label{tab:mutex}
+\end{table}
+
+The mutex interface requires two types of mutexes:
+
+\begin{enumerate}
+\item Fast mutexes: when only a few lines have to be protected (remapped to
+kern\_fsave/kern\_frestore).
+\item Normal mutexes: without any restriction (remapped again to the internal
+semaphores).
+\end{enumerate}
+
+Please note that these functions are not directly used in the
+code; instead, functions like \_\_b\_mutex\_lock and
+\_\_fs\_mutex\_lock are used. This is done to make possible the
+disabling of the mutual exclusion requirement when not needed
+(i.e., if the file system runs as a process with its own address
+space).
+
+%----------------------------------------------------------------------------
+\subsection{Exported interface}
+\label{sec:dd:intercaccia:ext}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+int bdev_read (__dev_t dev, __blkcnt_t blocknum, __uint8_t *buffer);
+int bdev_write (__dev_t dev, __blkcnt_t blocknum, __uint8_t *buffer);
+int bdev_seek (__dev_t dev, __blkcnt_t blocknum);
+int bdev_trylock(__dev_t device); int bdev_tryunlock(__dev_t device);
+__uint8_t bdev_getdeffs(__dev_t device);
+__dev_t bdev_find_byname(char *name);
+__dev_t bdev_find_byfs(__uint8_t fsind);
+int bdev_findname(__dev_t device, char **majorname, char **minorname);
+int bdev_scan_devices(int(*callback) (__dev_t,__uint8_t));
+\end{verbatim}
+\caption{Low level functions}
+\label{tab:bdev}
+\end{table}
+
+The low level exports two kinds of functions: one to use the
+devices, one to search/get the logical devices present on a
+system.
+
+The three main functions are:
+
+\begin{description}
+\item [bdev\_find\_byname]This function accepts a symbolic device name, as
+described in Section \ref{sec:dd:interfaccia:nomi}, and returns 0 if the device
+is not registered, or its number otherwise.
+\item [bdev\_find\_byfs]This function accepts a file system ID (see
+include/fs/fsind.h), and returns the first device that contains that file
+system, or 0 if no one provides it.
+\item [bdev\_scan\_device]This function can be used to get a list of all the
+devices in the system; the user have to pass a callback that is called for each
+device in the system. The function returns 0 in case of success, -1 if an error
+occurred, or a value != 0 if the callback returns a value != 0. The callback is
+called with a device serial number and a file system type that should be present
+in the device.
+\end{description}
+
+These function are useful when at system startup the root file
+system have to be mounted (see Section \ref{sec:fs:mount}).
+
+The functions bdev\_getdeffs and bdev\textbackslash{}\_findname
+are used for these purposes:
+
+\begin{description}
+\item [bdev\_getdeffs]to know a probable file system present on a logical
+device.
+\item [bdev\_findname]to know the logical name of a device. The function returns
+!= 0 in case of error, and 0 in case of success. In the latter case, the two
+buffers passed as parameter are filled with the major and minor names.
+\end{description}
+
+These functions simply check the parameter values and then they
+calls the device drivers functions (see Section
+\ref{sec:dd:interfaccia:det:bdevop}):
+
+\begin{description}
+\item [bdev\_read]Reads a block on the device.
+\item [bdev\_write]Write a block on the device.
+\item [bdev\_seek]Move the head in the position passed as parameter.
+\item [bdev\_trylock~e~bdev\_tryunlock]Tries to block/unblock a device.
+\end{description}
+
+These functions can block the calling thread for an unspecified
+amount of time. All the device drivers were thought to be used in
+a multithreaded systems.
+
+If a device driver is not multithread, proper mutual exclusion
+must be ensured, because the file system high level functions will
+call a low level service before the previous request has been
+served. Note that if such a mutual exclusion is used, the access
+to the device driver will be forced by the mutex policy, and so
+all the disk scheduling algorithms will not work properly.
+
+%----------------------------------------------------------------------------
+\section{I/O requests scheduling}
+\label{sec:dd:sched}
+%----------------------------------------------------------------------------
+
+Massy's thesis here inserts a dissertation on
+the various disk scheduling algorithms that has been removed.
+
+%----------------------------------------------------------------------------
+\section{Disk scheduling algorithms implemented in S.Ha.R.K.}
+\label{sec:dd:schedpres}
+%----------------------------------------------------------------------------
+
+The system currently support 5 different scheduling algorithms
+that can be changed/increased simply modifying system
+configuration.
+
+\begin{table}
+\begin{verbatim}
+int bqueue_init (bqueue_t *);
+int bqueue_numelements (bqueue_t *);
+int bqueue_removerequest (bqueue_t *);
+int bqueue_insertrequest (bqueue_t *, struct request_prologue *);
+struct request_prologue *bqueue_getrequest(bqueue_t *);
+\end{verbatim}
+\caption{Queue handling functions}
+\label{tab:bqueuefunc}
+\end{table}
+
+Only one algorithm can be active at a time. All the device drivers
+should use the queuing interface listed in the bqueue.h file (see
+Table \ref{tab:bqueuefunc}). The structure bqueue\_t is specific
+for each scheduling algorithm. The semantic of each function in
+the interface is the following:
+
+\begin{description}
+\item [bqueue\_init]Initialize the pending request queue; it returns 0 in case
+of success, != 0 otherwise.
+\item [bqueue\_numelements]Returns the number of elements in the queue.
+\item [bqueue\_insertrequest]This function inserts a request in the queue,
+following the specific algorithm behavior. The function returns 0 in case of
+success, != 0 otherwise. Please note that requests are passed through a pointer
+to the structrequest\_prologue\_t (see tab:structreqprolog). That is, every
+algorithm should use a structure with a struct request\_prologue as first field,
+passing a casted pointer to that structure.
+\item [bqueue\_getrequest]Returns the first request in queue (without removing
+it), and returns a pointer to that request, or NULL if there are not any pending
+requests.
+\item [bqueue\_removerequest]Removes the first request in queue, that is the
+request that would have been returned by bqueue\_getrequest; it returns 0 in
+case of success, != 0 in case of error.
+\end{description}
+
+\begin{table}
+\begin{verbatim}
+#define REQ_DUMMY 0
+#define REQ_SEEK 1
+#define REQ_READ 2
+#define REQ_WRITE 3
+
+struct request_prologue {
+ unsigned sector;
+ unsigned head;
+ unsigned cylinder;
+ unsigned nsectors;
+ unsigned operation;
+ struct request_specific x;
+};
+
+#define request_prologue_t struct request_prologue
+\end{verbatim}
+\caption{struct request\_prologue\_t}
+\label{tab:structreqprolog}
+\end{table}
+
+before calling bdev\_insertrequest, all the fields of the struct
+request\_prologue\_t must be filled (see Table
+\ref{tab:structreqprolog}):
+
+\begin{description}
+\item [sector,~head,~cylinder]This is the starting position in the hard disk.
+\item [nsectors]This is the number of sectors to transfer.
+\item [operation]The operation that must be performed:
+
+\begin{description}
+\item [REQ\_DUMMY]request not specified.
+\item [REQ\_SEEK]head seek to the specified position.
+\item [REQ\_READ]read request.
+\item [REQ\_WRITE]write request.
+\end{description}
+\end{description}
+
+To add algorithm specific fields, you can use the method used for
+the deadlines into Section \ref{sec:dd:sched:edf}.
+
+struct request\_specific (see Table \ref{tab:structreqprolog})
+must be defined by each algorithm, and contains algorithm-specific
+fields.
+
+struct bqueue\_t contains a scheduling queue. Its first field must
+be a pointer to a struct phdiskinfo (see Section
+\ref{sec:dd:interfaccia:det}, and Table \ref{tab:structphdsk}).
+
+Here is a description about the implementation of various disk
+scheduling algorithms.
+
+%----------------------------------------------------------------------------
+\subsection{FCFS}
+\label{sec:dd:sched:fcfs}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+typedef struct TAGfcfs_queue_t {
+ struct phdskinfo *disk;
+ __b_fastmutex_t mutex;
+ struct request_prologue *head;
+ struct request_prologue *tail;
+ int counter;
+} fcfs_queue_t;
+
+struct request_specific {
+ void *next;
+};
+\end{verbatim}
+\caption{struct fcfs\_queue\_t}
+\label{tab:structfcfs}
+\end{table}
+
+The FCFS policy is implemented using the structure in table
+\ref{tab:structfcfs}:
+
+\begin{description}
+\item [mutex]A mutual exclusion semaphore.
+\item [head~e~tail]a pointer to head and tail of a request queue.
+\item [counter]number of pending requests.
+\end{description}
+
+Then, the struct request\_specific contains a pointer that is used
+to link the list.
+
+%----------------------------------------------------------------------------
+\subsection{SSTF}
+\label{sec:dd:sched:sstf}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+typedef struct TAGsstf_queue_t {
+ struct phdskinfo *disk;
+ __b_fastmutex_t mutex;
+ struct request_prologue *actual;
+ struct request_prologue *lqueue;
+ struct request_prologue *hqueue;
+ int counter;
+} sstf_queue_t;
+
+struct request_specific {
+ void *next;
+};
+\end{verbatim}
+\caption{struct sstf\_queue\_t}
+\label{tab:structsstf}
+\end{table}
+
+This scheduling policy is implemented using the data structures in
+Figure \ref{tab:structsstf}:
+
+\begin{description}
+\item [mutex]for mutual exclusion.
+\item [actual]the current request (that is returned by bqueue\_getrequest()).
+\item [lqueue~e~hqueue]two lists ordered in decreasing and increasing order:
+when a new request arrives, the request is inserted on one of the two queues
+depending on the value of the current request cylinder. The current request will
+become the nearest to the current cylinder. Note: This algorithm can cause
+starvation.
+\item [counter]The request counter.
+\end{description}
+
+Then, the struct request\_specific contains a pointer that is used
+to link the list.
+
+%----------------------------------------------------------------------------
+\subsection{LOOK}
+\label{sec:dd:sched:look}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+typedef struct TAGlook_queue_t {
+ struct phdskinfo *disk;
+ __b_fastmutex_t mutex;
+ int dir;
+ struct request_prologue *queue[2];
+ int counter;
+} look_queue_t;
+
+struct request_specific {
+ void *next;
+};
+\end{verbatim}
+\caption{struct look\_queue\_t}
+\label{tab:structlook}
+\end{table}
+
+This scheduling policy is implemented using the data structures in
+Figure \ref{tab:structlook}:
+
+\begin{description}
+\item [mutex]for mutual exclusion.
+\item [dir]Is the looking direction: 0 ascending, 1 descending.
+\item [queue]two ordered lists (one ascending, one descending). queue[dir] is
+the queue used. When the list becomes empty, dir=!dir. a new request is inserted
+in the current queue if its position is after/before the actual position
+(otherwise, it is inserted in the other list).
+\item [counter]the request counter.
+\end{description}
+
+This algorithm can be implemented in two variants:
+
+\begin{enumerate}
+\item Requests with position = current position are inserted in the current
+queue (starvation can happen).
+\item Requests with position = current position are inserted in the queue not
+currently used. This is the default choice; to modify it, you have to modify the
+look.c file.
+\end{enumerate}
+
+%----------------------------------------------------------------------------
+\subsection{CLOOK}
+\label{sec:dd:sched:clook}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+typedef struct TAGclook_queue_t {
+ struct phdskinfo *disk;
+ __b_fastmutex_t mutex;
+ int act;
+ struct request_prologue *queue[2];
+ int counter;
+} clook_queue_t;
+
+struct request_specific {
+ void *next;
+};
+\end{verbatim}
+\caption{struct clook\_queue\_t}
+\label{tab:structclook}
+\end{table}
+
+This scheduling policy is implemented using the data structures in
+Figure \ref{tab:structclook}:
+
+\begin{description}
+\item [mutex]for mutual exclusion.
+\item [dir]This is the current queue.
+\item [queue]Two ascending lists. queue[dir] is used until it is emptied. Then,
+dir is changed. A new request is inserted in the current queue if the current
+position is greater than the current one.
+\item [counter]the request counter.
+\end{description}
+
+This implementation can introduce starvation because insertions at
+the current position are done on the same queue.
+
+%----------------------------------------------------------------------------
+\subsection{EDF}
+\label{sec:dd:sched:edf}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+typedef struct TAGbd_edf_queue_t {
+ struct phdskinfo *disk;
+ __b_fastmutex_t mutex;
+ struct request_prologue *queue;
+ int inservice;
+ int counter;
+} bd_edf_queue_t;
+
+struct request_specific {
+ void *next;
+ long dl;
+};
+\end{verbatim}
+\caption{struct look\_queue\_t}
+\label{tab:structedf}
+\end{table}
+
+This is the only real-time disk scheduling algorithm implemented
+in S.Ha.R.K. This scheduling policy is implemented using the data
+structures in Figure \ref{tab:structedf}:
+
+\begin{description}
+\item [mutex]For mutual exclusion.
+\item [queue]An ordered list, increasing with the deadline.
+\item [inservice]This flag is set when a request is in service.
+\item [counter]The request counter.
+\end{description}
+
+\begin{table}
+\begin{verbatim}
+typedef struct {
+ RES_MODEL r;
+ TIME dl;
+} BDEDF_RES_MODEL;
+
+#define BDEDF_res_default_model(res)
+#define BDEDF_res_def_level(res,l)
+#define BDEDF_res_def_dl(res,dl)
+\end{verbatim}
+\caption{Resource Module for deadlines}
+\label{tab:edfresmodel}
+\end{table}
+
+The request's deadline is got during task creation using the
+S.Ha.R.K. resource module shown in Figure \ref{tab:edfresmodel}.
+
+If the resource module is not used, the deadline is set to
+infinity. That is, in that case the scheduling algorithm become a
+FCFS.
+
+%----------------------------------------------------------------------------
+\section{Device driver: the IDE interface}
+\label{sec:dd:ide}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsection{Description}
+\label{sec:dd:ide:desc}
+%----------------------------------------------------------------------------
+
+A description of the IDE standard can be found in\cite{manual:ideintel} and
+\cite{manual:idevia}. This interface allows the connection of up to 2 IDE
+peripherals using the ATA or ATAPI protocol (as described into
+\cite{manual:ata4}). This driver implements the ATA-4 protocol \footnote{The
+original Massy's thesis have a small description of the standard, that I have
+removed.}.
+
+%----------------------------------------------------------------------------
+\subsection{Implementation}
+\label{sec:dd:ide:code}
+%----------------------------------------------------------------------------
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=7cm]{images/ide.eps}
+\end{center}
+\caption{The IDE subsystem}
+\label{fig:ide}
+\end{figure}
+
+
+The architecture of the IDE subsystem is shown in Figure
+\ref{fig:ide}: there is a part of the interface responsible for
+the system initialization (for example, for finding the IDE
+interfaces in the system, for finding the devices and their
+logical structure, for transforming the low level requests in
+ATA-4 commands), for command handling and another part for
+interfacing with the disk scheduling queue handling. Finally,
+there is a small part OS-dependent that should be rewritten to
+port it to other OSes.
+
+If possible, the driver uses the DMA; in any case, polling can be
+forced. DMA is only supported in bus-master mode
+\cite{manual:ideintel}.
+
+The system actually use only some commands of the classes ``PIO
+data in'', ``PIO data out'', ``Non-data'' e ``DMA''; it uses
+the ``read'', ``write'', ``seek'', ``dma read'', ``dma
+write'', ``identify'', ``pidentify'' and ``set feature''
+commands; packet commands are not currently supported, so ATAPI
+devices (like cd-roms) are currently not supported.
+
+%----------------------------------------------------------------------------
+\subsubsection{Initialization}
+%----------------------------------------------------------------------------
+
+The system is initialized calling the ide\_init() function into
+bdev\_init(). This is automatically done if the IDE support is
+compiled. The user should only initialize the struct bdev\_parms,
+as specified in Section \ref{sec:dd:interfaccia}.
+
+\begin{table}
+\begin{verbatim}
+typedef struct ide_parms {
+ void *parm_initserver;
+} IDE_PARMS;
+
+struct ide_server_model {
+ TIME dl;
+ TIME wcet;
+ TIME mit;
+};
+\end{verbatim}
+\caption{Data structures used to initialize the IDE driver.}
+\label{tab:ideinit}
+\end{table}
+
+The IDE\_PARMS structure has only one parameter, and is included
+into the ideparms field in the global init data structure:
+
+\begin{description}
+\item [parm\_initserver]This parameter is OS-specific and is
+related to the glue code.
+\end{description}
+
+\begin{table}
+\begin{verbatim}
+void ide_glue_send_request (int ideif);
+int ide_glue_activate_interface (int ideif);
+void ide_glue_unactivate_interface (int ideif);
+\end{verbatim}
+\caption{The glue code for the IDE driver.}
+\label{tab:ideglue}
+\end{table}
+
+The system dependent part of the IDE driver is contained into the
+file ideglue.c (see Figure \ref{tab:ideglue}):
+
+\begin{description}
+\item [ide\_glue\_activate\_interface]It enables the interface passed as
+parameter: It creates an aperiodic task, and assigns to it the interface
+interrupt. The task is activated when the interrupt arrives.
+\item [ide\_glue\_activate\_interface]It disables the interface. The aperiodic
+task is killed.
+\item [ide\_glue\_send\_request]It executes the first available request: it
+explicitly activates the task interface; when the task is activated because of
+an interrupt, the pending request is terminated, and another request (if
+present) is activated.
+\end{description}
+
+the parm\_initserver field contains a pointer to the struct
+ide\_server\_model, used to create the aperiodic tasks (see Figure
+\ref{tab:ideinit}):
+
+\begin{description}
+\item [dl]task deadline in $\mu$sec.
+\item [wcet]task worst case execution time in $\mu$sec.
+\item [mit]the mean inter arrival time.
+\end{description}
+
+If these parameters are not specified, standard parameters are
+used.
+
+These defines are used to conditionally compile the driver (see
+the source code):
+
+\begin{description}
+\item [FORCE\_SCANNING]this define force the search of the IDE peripherals also
+if the bus reset fails. This is useful if some peripherals does not follow the
+standard timings.
+\item [IDE\_OLDATAPIDELAY]this define forces a little delay that can be useful
+when using old ATAPI interfaces.
+\item [IDE\_FORCERESET]if defined a soft reset operation cannot be aborted
+because of a timeout. It must be specified if the peripheral does not follows
+the soft reset timings or if it cannot go in stand-by mode.
+\item [IDE\_SKIPSTATUSTEST]with this symbol we do not check if the command is
+being executed correctly (that is done reading on a status register); all the
+TX-based motherboard we found needs this symbol.
+\item [IDE\_SKIPALLTEST]when set, all the command are written into the registers
+without looking on the status register. This symbol implies the previous. This
+mode was needed on a TX motherboard where the polled mode for commands was
+unreliable.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsubsection{Policy queues Interface}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+typedef struct TAGidereq_t {
+ request_prologue_t info;
+ int next;
+ __uint8_t resetonerror;
+ __uint8_t cmd;
+ __b_sem_t wait;
+ int result;
+ __uint8_t features;
+ __uint8_t cyllow;
+ __uint8_t cylhig;
+ __uint8_t seccou;
+ __uint8_t secnum;
+ __uint8_t devhead;
+ __uint8_t *buffer;
+} idereq_t;
+\end{verbatim}
+\caption{struct idereq\_t}
+\label{tab:idereq}
+\end{table}
+
+Table \ref{tab:idereq} shows struct idereq\_t that is used by the
+driver to store the pending requests. It can be noted that the
+info field is of type request\_prologue\_t, as required by the
+modules that handle the scheduling policies (see
+\ref{sec:dd:schedpres}).
+
+Note that (since the IDE interface allows only a command at a
+time) there are two queues for each IDE interface (one for the
+master device, one for the slave). These request queues are
+prioritized. That is, the master queue always have priority on the
+slave queue.
+
+Here a small description of the fields showed in Table
+\ref{tab:idereq}:
+
+\begin{description}
+\item [info]To handle the requests using a module for disk scheduling.
+\item [next]used internally to handle a request pool.
+\item [resetonerror]If set, an error during a command implies a soft reset.
+\item [cmd]The command for the peripheral (see \cite{manual:ata4}).
+\item [wait]Synchronization semaphore: when a task sends a command, it waits the
+end of the execution of the command.
+\item [result]This is the result: 0 in case of success, != 0 in case of error
+(see idelow.c for the error codes).
+\item [features,~cyllow,~cylhigh,~seccou,~secnum~e~devhead]Values to be inserted
+into the I/O registers of the IDE interface. The behavior is different depending
+on the peripheral mode (LBA or C/H/S) (see Section \ref{sec:dd:ide:desc}).
+\item [buffer]read/write buffer (if needed).
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsubsection{Minor numbers}
+%----------------------------------------------------------------------------
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=10cm]{images/ideminor.eps}
+\end{center}
+\caption{IDE minor numbers}
+\label{fig:ideminor}
+\end{figure}
+
+This section describes how minor numbers are handled.
+
+As described in Section \ref{sec:dd:intercaccia:ext}, the generic
+low level part uses the major number to pass a request to a
+device. The specific device is then selected using the minor
+number.
+
+Figure \ref{fig:ideminor} shows the minor number structure of this
+device:
+
+\begin{itemize}
+\item The first 3 bits identifies the interface (8 interfaces maximum).
+\item A bit for the peripheral (master/slave). This is used to enqueue request
+in the right queue.
+\item The last 4 bits says which partition should be used. This info is used to
+convert relative sector numbers into absolute sector numbers.
+\end{itemize}
+
+Minor numbers are accessed only via macros. To modify the minor
+number mapping you should only modify these macros.
+
+%----------------------------------------------------------------------------
+\chapter{File system}
+\label{sec:fs}
+%----------------------------------------------------------------------------
+
+With the word ``file system'' we mean the internal organization
+of a block device; the purpose of such an organization is to store
+a set of files, usually divided in directories.
+
+A block device is seen by the file system as an ordered sequence
+of fixed sized blocks. The basic operations of a file system are
+read/write operations on the n-th block.
+
+%----------------------------------------------------------------------------
+\section{Interface}
+\label{sec:fs:int}
+%----------------------------------------------------------------------------
+
+This section describes the interface between the system and the
+user tasks. It also describes the interface between a specific
+instance of file system and the system (just to make easy the
+expansion of the system with new real-time file systems).
+
+%----------------------------------------------------------------------------
+\subsection{Initialization}
+\label{sec:fs:int:init}
+%----------------------------------------------------------------------------
+
+To initialize the higher level of the system we use an interface
+similar to the device drivers interface (see Section
+\ref{sec:dd:interfaccia:init}.
+
+\begin{table}
+\begin{verbatim}
+typedef struct filesystem_parms {
+ __dev_t device;
+ __uint8_t fs_ind;
+ __uint32_t fs_showinfo:1;
+ void *fs_mutexattr;
+ struct mount_opts *fs_opts;
+} FILESYSTEM_PARMS;
+
+#define filesystem_def_rootdevice(par,rootdev)
+#define filesystem_def_fs(par,fs)
+#define filesystem_def_showinfo(par,show)
+#define filesystem_def_options(par,opts)
+
+int filesystem_init(FILESYSTEM_PARMS *);
+\end{verbatim}
+\caption{struct filesystem\_parms}
+\label{tab:fsparms}
+\end{table}
+
+The function filesystem\_init() is called to initialize the higher
+layer passing the parameters showed in Figure \ref{tab:fsparms}.
+These parameters must be initialized using the following macros:
+
+\begin{description}
+\item [filesystem\_def\_rootdevice]Set the partition that must be used as
+\emph{root device}, that is, the directory associated to ``/''. This field is
+mandatory, and that implies that the higher layer must be initialized
+\emph{after} the device drivers.
+\item [filesystem\_def\_fs]Selects the filesystem that must be used with the
+device. It must be one of the symbols defined into include/fs/fsind.h; if the
+special symbol FS\_DEFAULT is used, the system tries to autodetect the
+filesystem type.
+\item [filesystem\_def\_showinfo]If this flag is set, then initialization
+messages are printed on the screen.
+\item [filesystem\_def\_options]There are the mount options.
+\end{description}
+
+The field fs\_mutexattr has the same meaning of the correspondent
+field into bdev\_parms (see Section
+\ref{sec:dd:interfaccia:init}).
+
+You can use the macro BASE\_FILESYSTEM to initialize a struct
+filesystem\_parms with some default values. NULL is not allowed as
+a parameter of filesystem\_init.
+
+\begin{table}
+\begin{verbatim}
+struct mount_opts {
+ __uint32_t flags;
+ union {
+ struct msdosfs_parms msdos;
+ } x;
+};
+
+/* Flags */
+#define MOUNT_FLAG_RW 0x01
+\end{verbatim}
+\caption{struct mount\_opts}
+\label{tab:mountopt}
+\end{table}
+
+\label{sec:mountopt}The mount options for every device must be
+inserted into a struct mount\_opts showed in Table
+\ref{tab:mountopt}. The structure is composed by two parts: a
+general part and a filesystem-specific part. The general part
+actually contains the following fields:
+
+\begin{description}
+\item [flags]This field contains the mount fields. The only flag
+currently defined is MOUNT\_FLAG\_RW, that allows write operations
+on the file system (default is read-only).
+\end{description}
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=7cm]{images/fsinit.eps}
+\end{center}
+\caption{Filesystem init}
+\label{fig:fsinit}
+\end{figure}
+
+Filesystem initialization proceeds as shown in Figure \ref{fig:fsinit}:
+
+\begin{enumerate}
+\item The user calls filesystem\_init();
+\item filesystem\_init() initializes itself and its modules, then all the file
+systems are initialized. filesystem\_init() have to be changed if a new
+filesystem is introduced.
+\item The file systems initialization functions have to register themselves
+calling the function filesystem\_register() with a struct file\_system\_type.
+\end{enumerate}
+
+%----------------------------------------------------------------------------
+\subsubsection{Struct file\_system\_type}
+\label{sec:filesystemtype}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+struct file_system_type {
+ const char *name;
+ int fs_flags;
+ __uint8_t fs_ind;
+ struct super_block *(*read_super) (
+ __dev_t device,
+ __uint8_t fs_ind,
+ struct mount_opts *options
+ );
+};
+\end{verbatim}
+\caption{struct file\_system\_type}
+\label{src:structfs}
+\end{table}
+
+This structure (see Table \ref{src:structfs})stores the
+informations needed for the filesystem registration. Here a short
+description of its fields:
+
+\begin{description}
+\item [name]Pointer to the filesystem name (e.g., ``FAT16'').
+\item [fs\_flags]Filesystem flags (currently not used).
+\item [fs\_ind]Filesystem ID (every filesystem has a different ID).
+\item [read\_super]This the filesystem initialization function. It is called
+when a partition is mounted to initialize the correspondent struct super\_block.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Internal interface}
+%----------------------------------------------------------------------------
+
+This section describes the interface between the high layer (that
+handles the file systems), and the modules that implements a
+specific filesystem.
+
+When a user mount a device into a directory using a filesystem,
+the system uses the file system's specific struct
+file\_system\_type, calling the function read\_super() to read the
+superblock of the specified device.
+
+The struct super\_block contains a pointer to a structure that
+contains a set of ``virtual operations'' (see Section
+\ref{sec:fs:intstruct}), that implements the behavior of a
+specific filesystem.
+
+%----------------------------------------------------------------------------
+\subsubsection{struct super\_operations}
+\label{sec:superop}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+struct super_operations {
+ int (*init_inode) (struct inode *);
+ int (*read_inode) (struct inode *);
+ int (*write_inode) (struct inode *);
+ int (*put_super) (struct super_block *);
+ int (*delete_inode) (struct inode *);
+};
+\end{verbatim}
+\caption{struct super\_operations}
+\label{src:structsuperop}
+\end{table}
+
+The structure in Table \ref{src:structsuperop} is used for super
+block manipulation. All the functions should return 0 in case of
+success, or a value != 0 otherwise.
+
+\begin{description}
+\item [init\_inode]This function initializes a struct inode passed as parameter.
+That structure must have the fields i\_sp and i\_st.st\_ino already initialized
+(see Section \ref{sec:inode}).
+\item [read\_inode]This function reads the inode passed as parameter from the
+filesystem. The inode structure must have the fields i\_sp and i\_st.st\_ino
+already initialized.
+\item [write\_inode]This function writes a (valid, full initialized) inode into
+the filesystem.
+\item [delete\_inode]This function removes the inode from the filesystem (the
+inode must already exist on the filesystem).
+\item [put\_super]This function writes the super block passed as parameter into
+the filesystem. This function is called when a filesystem is unmounted. A dual
+function (that is, a function that reads a super\_block from a filesystem)
+(which is only used when mounting the filesystem) can be found into the struct
+file\_system\_type (see Section
+\ref{sec:filesystemtype}).
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsubsection{Struct dentry\_operations}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+struct dentry_operations {
+ int (*d_compare) (struct dentry *, struct qstr *, struct qstr *);
+};
+\end{verbatim}
+\caption{struct dentry\_operations}
+\label{src:structdentryop}
+\end{table}
+
+\label{sec:dentryop} This structure contains all the functions
+used to manipulate a struct dentry.
+
+\begin{description}
+\item [d\_compare]This function compares the two strings passed as
+parameter. it returns 0 if the two strings are equal, or != 0
+otherwise. The filesystem do not use directly the strcmp()
+function, because filename comparison depends on the filesystem
+(e.g., case sensitive, case insensitive).
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsubsection{struct inode\_operations}
+\label{sec:inodeop}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+struct inode_operations {
+ struct file_operations *default_file_ops;
+ struct inode* (*create) (struct inode *, struct dentry *);
+ struct inode* (*lookup) (struct inode *, struct dentry *);
+ int (*unlink) (struct dentry *);
+ void (*destroy) (struct inode *);
+ int (*truncate) (struct inode *, __off_t len);
+};
+\end{verbatim}
+\caption{struct inode\_operations}
+\label{src:structinodeop}
+\end{table}
+
+This struct contains the virtual operations on the struct inode.
+These functions returns 0 in case of success, !=0 in case of
+error, that will be interpreted as a negate errno() value (e.g.,
+-EPERM instead of EPERM).
+
+\begin{description}
+\item [default\_file\_ops]these are the file\_operations described into the
+paragraph \ref{sec:fileop}, that must be used with the inode. By default, the
+field is initialized with the file\_operation of its filesystem. These pointers
+can be modified to implement a kind of virtual filesystem that works on a
+device. For example, we can define an inode ``/dev/ide/hda1'' in a way that all
+read/write operations on it are not mapped in the operations of the filesystem
+where it is stored.
+\item [create]This function creates a new inode (a new file) with the name
+passed as parameter into the struct inode passed as parameter (that must be an
+inode of type ``directory''). It returns the new inode or NULL in case of
+error.
+\item [lookup]This function searches an inode passed as parameter into another
+inode of type directory passed as parameter. It returns the inode just found or
+NULL in case of error.
+\item [unlink]This function unlinks the filename passed as parameter from the
+parameter of the corresponding inode. The inode will be removed (by generic
+filesystem routines) if it remains without links associated to it.
+\item [destroy]This function destroys the file linked to the inode. It frees the
+space occupied by the file. Often, it is sufficient to call the truncate
+function with length 0.
+\item [truncate]This function truncates the file length of the inode passed as
+parameter at the length specified in the second parameter. If the given length
+is greater than the actual file length, the function does nothing.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsubsection{struct file\_operations}
+\label{sec:fileop}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+struct file_operations {
+ __off_t (*lseek) (struct file *, __off_t, int);
+ __ssize_t (*read) (struct file *, char *, __ssize_t);
+ __ssize_t (*write) (struct file *, char *, __ssize_t);
+ int (*readdir) (struct file *, void *);
+ int (*open) (struct inode *, struct file *);
+ int (*close) (struct inode *, struct file *);
+};
+\end{verbatim}
+\caption{struct file\_operations}
+\label{src:structfileop}
+\end{table}
+
+This structure contains all the function that must work with
+files. If not otherwise stated, the functions can operate both on
+files and on directory.
+
+\begin{description}
+\item [lseek]Moves the input/output position of the file specified as parameter.
+The new position is specified as in the lseek primitive (described in
+\cite{book:posix1003.1} or in all the Unix programming books). That is, the
+position is specified with a delta with respect to a given position (start of
+file, end of file, current position); As described in section \ref{sec:file}
+during the description of the field f\_pos, the new position can be greater than
+the end-of-file. This function must return a position inside the file or an
+error code.
+\item [read]Reads some data and puts it into the buffer. The function is called
+only for regular files. It returns the number of bytes read, that can be less
+than requested, or an error code.
+\item [write]Writes some bytes from the specified buffer. It is called only for
+regular files. It returns the number of bytes written, that can be less than
+requested, or an error code.
+\item [readdir]Reads the next filename of the directory parameter passed through
+a struct file. It inserts it into the struct dirent passed as parameter. Returns
+0 in case of success, a negative number in case of error.
+\item [open]Opens the file linked to the inode. Fills some internal fields in
+the filesystem-specific struct file. Returns 0 in case of success, an error
+otherwise.
+\item [close]Closes the file passed as parameter. returns 0 in case of success,
+an error in case of failure.
+\end{description}
+
+Most of the function described in this section works on buffers
+passed by the user. the general routines checks that these buffer
+are corrects. In case the operating system implement some memory
+protection mechanisms, the functions copyfromuser() and
+copytouser() should be used (their syntax is similar to memcpy()).
+Note that Shark currently do not provide memory protection, so
+memcpy() can be used.
+
+%----------------------------------------------------------------------------
+\subsection{External interface}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsubsection{Non standard functions}
+\label{sec:fs:mount}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+int mount (dev_t device, u_int8_t fsind, char *where, struct mount_opts
+*options);
+int umount (dev_t device);
+dev_t fdevice(char *device_name);
+\end{verbatim}
+\caption{mount/umount functions}
+\label{tab:mount}
+\end{table}
+
+The mount/umount functions are the non-standard functions provided
+by the filesystem (their prototype can be found in
+include/sys/mount.h). Here is a small description of these
+functions (see Table \ref{tab:mount}):
+
+\begin{description}
+\item [fdevice]This function returns the device serial number of a
+given filename. See Section \ref{sec:dd:interfaccia:nomi}.
+\item [mount]Is used to mount a partition. These are the informations that must
+be passed to it:
+
+\begin{itemize}
+\item The device serial number that must be mounted
+\item The filesystem identifier (fsind) that should be used (see
+include/fs/fsind.h).
+\item The directory where the device will be mounted.
+\item Other parameters (see Section \ref{sec:mountopt}).
+\end{itemize}
+
+The function returns 0 in case of success, != 0 in case of failure
+(errno is modified).
+
+\item [umount]This function unmount a device that was previously
+mounted. This function cannot unmount the ``root'' device.
+During shutdown, all the filesystem will be unmounted in the
+proper order.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Initialization: an example}
+%----------------------------------------------------------------------------
+
+This is an example of the filesystem initialization in S.Ha.R.K.
+To initialize the system, we must register the kernel modules
+first:
+
+\begin{verbatim}
+TIME __kernel_register_levels__(void *arg)} {
+ struct multiboot_info *mb=(struct multiboot_info*)arg;
+
+ EDF_register_level(EDF_ENABLE_ALL);
+ RR_register_level(RRTICK, RR_MAIN_YES, mb);
+ CBS_register_level(CBS_ENABLE_ALL, 0);
+ dummy_register_level();
+
+ SEM_register_module();
+ CABS_register_module();
+ NOPM_register_module();
+ return TICK;
+}
+\end{verbatim}
+
+The filesystem always require the registration of a module that
+can accept soft aperiodic tasks (such as the CBS, for example).
+Moreover, a mutex protocol must be present (NOPM, in this case).
+
+\begin{verbatim}
+TASK __init__(void *arg) {
+ extern int __bdev_sub_init(void);
+ extern int __fs_sub_init(void);
+ struct multiboot_info *mb = (struct multiboot_info*)arg;
+
+ /* block devices initialization */
+ __bdev_sub_init();
+
+ /* filesystem initialization */
+ __fs_sub_init();
+ __call_main__(mb);
+ return (void *)0;
+}
+\end{verbatim}
+
+This is a typical S.Ha.R.K. \_\_init\_\_ function. In this
+function, block devices and file systems should be initialized.
+
+\begin{verbatim}
+int __bdev_subinit(void) {
+ extern __dev_t root_device;
+ BDEV_PARMS bdev=BASE_BDEV;
+
+ /* low level initialization */
+ bdev_def_showinfo(bdev,TRUE);
+ bdev_init(&bdev);
+
+ /* root device specification */
+ root_device = bdev_scan_devices(choose_root_callback);
+ if (root_device < 0) {
+
+ /* in case of error... */
+ exit(1);
+ }
+ return 0;
+}
+\end{verbatim}
+
+
+This function initializes the block device layer. This function
+sets the parameters of the bdev variable, calls the low level
+initialization functions and searches for the \emph{root device};
+basically, the function must specify in some way which is the root
+device. In the function, the low level layer lists all the
+available devices, calling the function choose\_root\_callback()
+for each of them. That function will choose the root device.
+
+\begin{verbatim}
+int choose_root_callback(dev_t dev,u_int8_t fs) {
+ if (fs==FS_MSDOS)
+ return dev;
+ return -1;
+}
+\end{verbatim}
+
+In this case, the choice of the root device is quite simple: the
+first FAT16 DOS partition becomes the root device. Usually,
+DOS calls that partition ``C:''.
+
+\begin{verbatim}
+int __fs_sub_init(void) {
+ extern __dev_t root_device;
+ FILESYSTEM_PARMS fs = BASE_FILESYSTEM;
+ struct mount_opts opts;
+
+ /* mount parameters */
+ memset(&opts, 0, sizeof(struct mount_opts));
+ opts.flags = MOUNT_FLAG_RW;
+
+ /* filesystem initialization */
+ filesystem_def_rootdevice(fs,root_device);
+ filesystem_def_fs(fs,FS_MSDOS);
+ filesystem_def_showinfo(fs,TRUE);
+ filesystem_init(&fs);
+
+ /* C library initialization */
+ libc_initialize();
+
+ return 0;
+}
+\end{verbatim}
+
+This functions initializes the filesystem giving R/W permission on
+the root partition previously found. Then, the C library is
+initialized.
+
+%----------------------------------------------------------------------------
+\section{Internal structure}
+\label{sec:fs:intstruct}
+%----------------------------------------------------------------------------
+
+Many data structures are composed by two parts: a generic part,
+that is independent from the particular filesystem, and a
+filesystem specific part, that are usually stored into an union.
+
+Almost all the data structures have a set of functions that
+modifies them. Pointers to these functions are included in a
+structure that has the name of the structure that is modified by
+the functions with a suffix ``operations''. For example, the
+structure super\_block (see Section \ref{sec:superblock}) has a
+structure super\_operations (see Section \ref{sec:superop}) that
+contains a function create\_inode.
+
+Since the high layer functions influences the global system
+throughput, some informations are duplicated in the data
+structures to speed up the execution.
+
+The system is basically structured with a Unix-like approach, with
+4 fundamental structures:
+
+\begin{description}
+\item [super]contains informations on each device that is mounted (a table is
+used);
+\item [inode]contains informations on the files in a filesystem (double lists
+with hash keys are used);
+\item [dentry]contains the file names (a tree is used);
+\item [file]contains informations on each open file (a descriptor table is
+used).
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{The data structures}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsubsection{struct super\_block}
+\label{sec:superblock}
+%----------------------------------------------------------------------------
+
+From a user point of view, the filesystem exports a unix-like view
+of the system. That is, partitions can be mounted into the
+directory tree. When the system starts, the root directory is
+mounted as ``/''.
+
+\begin{table}
+\begin{verbatim}
+struct super_block {
+ struct super_block *sb_parent;
+ struct super_block *sb_childs;
+ struct super_block *sb_next;
+ __dev_t sb_dev;
+ struct inode *sb_root;
+ struct dentry *sb_droot;
+ struct file_system_type *sb_fs;
+ struct super_operations *sb_op;
+ struct dentry_operations *sb_dop;
+ struct mount_opts sb_mopts;
+ int sb_busycount;
+ __uint32_t sb_used:1;
+ __uint32_t sb_blocked:1;
+ union {
+ struct msdos_super_block msdos_sb;
+ } u;
+};
+\end{verbatim}
+\caption{struct super\_block}
+\label{src:structsuper}
+\end{table}
+
+The struct super\_block contains the fundamental information of
+the filesystem (a unix-like filesystem usually duplicates this
+informations a few times into the Hard disk). Every time a
+partition is mounted a new structure is allocated and initialized.
+These structures are maintained in a tree, that is, if a partition
+is mounted into a directory the new structure becomes a leaf of
+the structure that contains the mount directory.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=7cm]{images/supertree.eps}
+\end{center}
+\caption{Super block tree}
+\label{fig:supertree}
+\end{figure}
+
+The root super block is stored into the global pointer
+root\_superblock; Figure \ref{fig:supertree} shows a possible
+super block tree.
+
+Here a short description of the struct super\_block fields (see
+Table \ref{src:structsuper}):
+
+\begin{description}
+\item [sb\_parent,~sb\_childs,~sb\_next]are used to store the tree structure:
+sb\_parent points to the father of the structure, whereas sb\_childs points to
+the first structure of the childs; sb\_next is used to create the brothers list
+(that is the children list of the father).
+\item [sb\_dev]Contains the device, that is the partition that contains the
+filesystem (the low level part is responsible of the devices, that are typically
+associated to an hard disk partition. It is possible for example to extend the
+low level to associate to a device other entities, such a file on another
+filesystem (this is usually possible on Unix system through loopback devices).
+\item [sb\_root]This is the root directory inode of the filesystem.
+\item [sb\_droot]This is the directory entry (the filename) of the root
+directory.
+\item [sb\_fs]This is the pointer to the filesystem present in the filesystem.
+Every supported file system is registered at init time (see Section
+\ref{sec:fs:int:init}).
+\item [sb\_op]Pointer to a structure that contains the specific filesystem
+functions used to use the struct super\_block.
+\item [sb\_dop]These are the specific function used for the directory entries.
+\item [sb\_mopts]Mount options used during initialization.
+\item [sb\_busycount]This is a counter that counts the number of entities that
+are using the filesystem (e.g., a partition can be unmounted if someone is
+reading it).
+\item [sb\_used]A flag that signals if the structure is used.
+\item [sb\_blocked]Some operations on this structure must be executed in mutual
+exclusion; if this flag is set there is some operation on the structure. This
+flag can not be used/tested/modified directly by the user functions.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsubsection{struct dentry}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+struct dentry {
+ struct dentry *d_next;
+ struct dentry *d_prev;
+ struct dentry *d_parent;
+ struct dentry *d_child;
+ __time_t d_acc;
+ struct qstr d_name;
+ short d_lock;
+ struct dentry_operations *d_op;
+ struct inode *d_inode;
+ struct super_block *d_sb;
+};
+\end{verbatim}
+\caption{struct dentry}
+\label{src:structdentry}
+\end{table}
+
+\label{sec:dentry} The struct dentry contains the file names independently from
+the file type (regular file, directory, ...) \footnote{``dentry'' means
+\emph{D}irectory \emph{ENTRY}.}. Each file in the filesystem is always stored in
+two structures:
+
+\begin{itemize}
+\item struct dentry contains the filename;
+\item struct inode contains the other informations on the file.
+\end{itemize}
+
+This separation is made because in most file systems (not in the DOS FAT16)
+more than one name can be linked to the same file (inode).
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=10cm]{images/dentrytree.eps}
+\end{center}
+\caption{Directory entry tree.}
+\label{fig:dentrytree}
+\end{figure}
+
+
+These data structures are stored internally in a tree structure. Please note
+that the inodes are not structured as a tree; every dentry has a pointer to the
+correspondent inode.
+
+Figure \ref{fig:dentrytree} shows a directory entry tree.
+Directories are showed with a continuous line, whereas files are
+showed with a dashed line (note that the internal structures for
+files and directories are the same).
+
+The system do not load all the file names in the filesystem. Only
+the recent filenames are stored in memory in a partial tree. These
+informations are continuously updated removing and adding dentry
+struct.
+
+\begin{table}
+\begin{verbatim}
+struct qstr {
+ char name[MAXFILENAMELEN+1];
+ char *nameptr;
+};
+\end{verbatim}
+\caption{struct qstr}
+\label{src:structqstr}
+\end{table}
+
+Directory names are stored into a struct qstr (see Table
+\ref{src:structqstr}). A string is not used to avoid too much
+sting copies. The structure is composed by two fields:
+
+\begin{description}
+\item [nameptr]If != NULL, it is the name to use.
+\item [name]If nameptr==NULL, it is the name to use.
+\end{description}
+
+The QSTRNAME can be used on a structure QSTR to get a (char *).
+When filling the structure, one of the two fields can be used. If
+nameptr is used, the pointed string must be statically allocated.
+If name is used, nameptr must be set to NULL.
+
+The fields of the struct dentry contains the following
+informations:
+
+\begin{description}
+\item [d\_next,~d\_prev,~d\_parent~e~d\_child]can be used to store a dentry tree
+structure: d\_parent is a pointer to the father's dentry, d\_child is a pointer
+to a list of children dentry, d\_next and d\_prev are used to navigate into the
+children dentry list.
+\item [d\_acc]It is the time of the last access to the dentry structure.
+\item [d\_name]Is the name associated to the dentry.
+\item [d\_lock]is a blocking counter: it is incremented every time a routine
+needs to use the dentry, and it is decremented when it is no more needed. In
+that way, it is possible to know which are the structures currently in use. The
+filesystem routines should not directly modify this field.
+\item [d\_op]Pointer to the virtual operations used to handle this structure.
+\item [d\_inode]is the inode associated to the structure.
+\item [d\_sb]It is the super\_block that contains the directory. This a
+redundant information used to speed-up the code.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsubsection{struct inode}
+\label{sec:inode}
+%----------------------------------------------------------------------------
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=10cm]{images/inodebuckets.eps}
+\end{center}
+\caption{Inode data structures}
+\label{fig:inodebuckets}
+\end{figure}
+
+
+\begin{table}
+\begin{verbatim}
+struct inode {
+ struct stat i_st;
+ struct inode *i_next;
+ struct inode *i_prev;
+ int i_hash;
+ __rwlock_t i_lock;
+ __uint16_t i_dlink;
+ __uint32_t i_dirty:1;
+ struct inode_operations *i_op;
+ struct super_block *i_sb;
+ union {
+ struct msdos_inode_info msdos_i;
+ } u;
+};
+\end{verbatim}
+\caption{struct inode}
+\label{src:structinode}
+\end{table}
+
+An inode is a file into a filesystem. It contains all the file
+informations except the name that is maintained into a struct
+dentry (see \ref{sec:dentry}; more details can be found into
+\cite{book:unix}).
+
+All the inodes temporarily present in memory are stored into an
+hash bucket structure as showed in Figure \ref{fig:inodebuckets}:
+for each device a number is computed using an hash function, the
+inode number (file serial number) and the device number. All the
+inodes with the same hash entry are stored in a list. The first
+inode in the list is stored in a table at the index given by the
+hash key.
+
+\begin{table}
+\begin{verbatim}
+struct stat {
+ __dev_t st_dev;
+ __ino_t st_ino;
+ __mode_t st_mode;
+ __nlink_t st_nlink;
+ __uid_t st_uid;
+ __gid_t st_gid;
+ __off_t st_size;
+ unsigned long st_blksize;
+ __time_t st_atime;
+ __time_t st_mtime;
+ __time_t st_ctime;
+};
+\end{verbatim}
+\caption{struct stat}
+\label{src:structstat}
+\end{table}
+
+An inode contains the following fields:
+
+\begin{description}
+\item [i\_st]Contains all the standard informations for a file (e.g., the
+length, the type); a task can inspect these informations using the stat()
+primitive. These informations are included into a stat structure that is shared
+between the user libraries and the internal implementation, in a way that a
+memcopy should be enough to pass these informations.
+\item [i\_next,~i\_prev~e~i\_hash]These fields are used to implement the double
+linked list and the hash key: i\_next and i\_prev implement a double list,
+whereas i\_hash is the hash key (redundant information).
+\item [i\_lock]It is a lock for the structure (see Section \ref{sec:rwlock}).
+\item [i\_dlink]Number of directory entries that points to the inode (see
+Section \ref{sec:dentry}).
+\item [i\_dirty]A flag that says if this inode has been modified.
+\item [i\_op]Virtual operations used for working with this inode. Usually they
+are filesystem specific.
+\item [i\_sb]Super block where the inode is stored (see Section
+\ref{sec:superblock}).
+\end{description}
+
+The struct stat showed in Table \ref{src:structstat}, contained
+into the struct inode and described in the paragraph 5.6 of
+\cite{book:posix1003.1}, contains the following fields:
+
+\begin{description}
+\item [st\_mode]It is the file mode (informations about who can
+read/modify/execute a file).
+\item [st\_ino]An unique number that identifies a file (``file serial number''
+in the Posix terminology).
+\item [st\_dev]It is the device serial number; st\_dev and st\_ino are necessary
+and sufficient to uniquely identify a file in the system.
+\item [st\_nlink]Number of hard links to a file (Always 1 for FAT16 file
+systems).
+\item [st\_uid~e~st\_gid]File group and user identifiers. 0 is used for the
+system administrator. The FAT16 filesystem always set these fields to 0.
+\item [st\_size]File length (bytes).
+\item [st\_atime,~st\_mtime~e~st\_ctime]File times: st\_atime is the time of the
+last access, st\_mtime is the time of the last modification and st\_ctime is the
+time of the last state change (e.g., when the file has been created or modified
+using chmod).
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsubsection{struct file}
+\label{sec:file}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+struct file {
+ struct file *f_next;
+ struct dentry *f_dentry;
+ struct file_operations *f_op;
+ __loff_t f_pos;
+ unsigned int f_count;
+ __uint32_t f_flag_isdir:1;
+ union {
+ struct msdos_file_info msdos_f;
+ } u;
+};
+\end{verbatim}
+\caption{struct file}
+\label{src:structfile}
+\end{table}
+
+Every open file has a struct file associated to it (see Table
+\ref{src:structfile}).
+
+\begin{description}
+\item [f\_next]Pointer used internally to the filesystem modules.
+\item [f\_dentry]contains the filename (see Section \ref{sec:dentry}). From here
+we can get the corresponding inode number.
+\item [f\_op]Contains a pointer to the virtual operation that works on struct
+file, described in Section \ref{sec:fileop}.
+\item [f\_pos]Contains the current position into the file. read/write operations
+are done starting from this point; moreover, Posix specification allow a seek to
+a position beyond file termination: in that case read operation should fail,
+whereas write operation should fill the gap with zeroes.
+\item [f\_count]Contains the number of file descriptors that are using this
+structure for input/output operations on the file.
+\item [f\_flag\_isdir]Flag that says if this is a directory (redundant
+information).
+\item [msdos\_f]FAT16 specific informations.
+\end{description}
+
+The applications use a file descriptor to index the file to use. A
+file descriptor is a number meaningful only for the processor that
+obtained it (e.g. through an open operation) that is assigned to a
+struct file through a descriptor table. Every process has a
+different table, contained into the struct file\_descriptors
+described in section \ref{sec:filedes}. The whole S.Ha.R.K. Kernel
+can be considered a monoprocess multithread application, and for
+that reason it has only one descriptor table.
+
+%----------------------------------------------------------------------------
+\subsubsection{struct file\_descriptors}
+\label{sec:filedes}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+struct file_descriptors {
+ struct file *fd_file[MAXOPENFILES];
+ __uint16_t fd_flags[MAXOPENFILES];
+ __uint32_t fd_fflags[MAXOPENFILES];
+ __mode_t fd_umask;
+ char fd_cwd[MAXPATHNAMELEN+1];
+ struct dentry *fd_cwden;
+ __mutex_t fd_mutex;
+};
+\end{verbatim}
+\caption{struct file\_descriptors}
+\label{src:structfiledes}
+\end{table}
+
+This struct is used to store all the general parameters assigned
+to a process (e.g., the current directory). Again, S.Ha.R.K. has
+only one structure because it can be considered like a monoprocess
+multithread system. A mutex is used to guarantee mutual exclusion
+when the struct is used by more than one thread. The structure
+contains the following fields:
+
+\begin{description}
+\item [fd\_file]This is the descriptor table; every descriptor
+(with value between 0 and MAXOPENFILES) is associated an element
+that can have the following values:
+
+\begin{itemize}
+\item NULL if it is a free descriptor;
+\item RESERVED if it is reserved for special uses (e.g., descriptors assigned to
+the keyboard or to the console)
+\item pointer to the file
+\end{itemize}
+
+\item [fd\_flags]Flags associated to the file (e.g., FD\_CLOSEXEC), described in
+detail in \cite{book:posix1003.1}, when the fcntl() primitive is described.
+\item [fd\_fflags]Flag used when the file was opened (e.g., O\_APPEND,
+O\_RDONLY, etc...).
+\item [fd\_umask]Mask used during file creation;can be modified with the
+function umask().
+\item [fd\_cwd]Current working directory used by all the primitives that
+receives a relative pathname (that does not start with ``/'' (redundant
+information).
+\item [fd\_cwden]The current working directory; it can be modified using the
+function chdir().
+\item [fd\_mutex]Mutual exclusion semaphore used for concurrent multithread
+access.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsection{Disk Cache}
+\label{sec:diskcache}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsubsection{How to use the cache}
+%----------------------------------------------------------------------------
+
+The filesystem modules use the disk cache to get all the
+informations they need.
+
+\begin{table}
+\begin{verbatim}
+ dcache_t *dcache_lock (__dev_t dev, __blkcnt_t lsector);
+void dcache_unlock (dcache_t *);
+dcache_t *dcache_acquire (__dev_t dev, __blkcnt_t lsector);
+void dcache_release (dcache_t *);
+void dcache_dirty (dcache_t *d);
+void dcache_skipwt(dcache_t *d);
+\end{verbatim}
+\caption{Disk cache interface}
+\label{tab:cacheint}
+\end{table}
+
+The disk cache interface is showed in Table \ref{tab:cacheint}:
+
+\begin{description}
+\item [dcache\_lock]This function can be used to require a read only access to
+the cache. More than one thread can lock a block. the parameters are the device
+number and the sector number; it returns a pointer to the struct dcache\_t in
+case of success, or NULL in case of error. This function do not return until the
+access is granted or an error occurred. To avoid critical blocking times in case
+more than one block is needed, you must use a proper access protocol: the
+blocking must be done with increasing block numbers; moreover, if possible, only
+one block should be blocked at a time.
+\item [dcache\_unlock]This function can be used to unblock a cache entry
+previously blocked.
+\item [dcache\_acquire]This function behaves as dcache\_lock(), but it requires
+a read/write access. Only one task at a time can acquire the lock. This access
+do not imply that the cache entry is considered dirty (see the dcache\_dirty()
+function).
+\item [dcache\_release]This function is similar to dcache\_unlock(), and works
+with the locks acquired by dcache\_acquire().
+\item [dcache\_dirty]Signal that the cache entry has been modified. This
+function must be called only if we own a read/write lock and if the cache has
+been modified.
+\item [dcache\_skipwt]This function signals to the system that the cache entry
+contains system informations that are often modified. That means that the
+write\_through flag should not be considered. See section \ref{sec:modicache}
+for a detailed description.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsubsection{struct dcache}
+\label{sec:dcache}
+%----------------------------------------------------------------------------
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=10cm]{images/dcachebuckets.eps}
+\end{center}
+\caption{Data structure for disk cache}
+\label{fig:dcachebuckets}
+\end{figure}
+
+\begin{table}
+\begin{verbatim}
+typedef struct TAGdcache {
+ int prev;
+ int next;
+ int hash;
+ __dev_t device;
+ __blkcnt_t lsector;
+ __uint8_t buffer[MAXSECTORSIZE];
+ int used;
+ __time_t time;
+ int numblocked;
+ __fs_sem_t sync;
+ __fs_sem_t esync;
+ __rwlock_t rwlock;
+ __uint32_t dirty:1;
+ __uint32_t ready:1;
+ __uint32_t esyncreq:1;
+ __uint32_t skipwt:1;
+} dcache_t;
+\end{verbatim}
+\caption{struct dcache}
+\label{str:structdcache}
+\end{table}
+
+This data structure, used by the module that implements the data
+cache, represents a cache entry. All the high level functions uses
+the cache module as an interface to the lower layer.
+
+These structures are maintained in the system wit a structure
+similar to the inodes, that is a set of double linked lists that I
+can access using an hash key, as showed in Figure
+\ref{fig:dcachebuckets}; the hash key is computed using the device
+(that is the physical peripheral) and the lsector (the logical
+sector).
+
+Every struct dcache is an elementary block that can be transferred
+to a device. It is not possible to have 2 data structures that
+refers to the same block. That is, the pair (device,lsector) must
+uniquely identify the data sector on the physical device (e.g.,
+the block 64 in ``ide/hda'' could be the block 0 of
+``ide/hda1'', as explained in section
+\ref{sec:dd:interfaccia:nomi}).
+
+The field of the structure (see Table \ref{str:structdcache}) are:
+
+\begin{description}
+\item [prev,~next~e~hash]Are used to store the structures into the lists that
+are accessed using the hash key: next and prev are used to implement a double
+linked list, whereas hash is the hash key.
+\item [device,~lsector~e~buffer]These fields contain the physical device, the
+logical sector and the data contained in the corresponding physical block. These
+are the unique fields that a high level routine should use (and that shall be
+provided by a data cache).
+\item [used]The number of tasks that are using the block; -1 means that no one
+is using the block, and that the block is free.
+\item [time]The last block access time.
+\item [numblocked]It is the number of tasks that are waiting the availability of
+the block, (that is, they are waiting the flag ready to be set). That is, if a
+task asks for a block already asked by another task, but not yet available (not
+made available by the lower layer), then the task blocks on a synchronization
+semaphore, and it increments that field.
+\item [sync]This is the synchronization semaphore used by the blocked tasks that
+waits the setting of the ready flag.
+\item [esync]It is a synchronization semaphore on the errors needed during the
+cache ``purging'' phase (see later).
+\item [rwlock]This is a locker used to require the R/W access to the block (see
+Section \ref{sec:rwlock}).
+\item [dirty]This flag is set if the block has been modified.
+\item [ready]This flag is set if the block is available.
+\item [esyncreq]This flag is set if the synchronization on errors is required
+(that is, the field esync is used).
+\item [skipwt]This flag says if the write through handling should be done.
+\end{description}
+
+The fields esync and esyncreq are used during the ``purging
+phase'': a task requires a read or write operation on a block, the
+block is not into the data cache, and the cache is full. That is,
+another block must be discarded from the cache. To discard a block
+it can happen that a disk write operation must be done. While this
+write operation is in progress other tasks can require the same
+(discarded, in writing) block. These tasks can block waiting for
+synchronization on the block. In that case the cache behavior
+could be the following: the requests on the block are aborted (the
+failure is only needed if we are able to free the block; the
+blocked tasks are awakened with an error); or, the requests on the
+block are not aborted (the block can not be freed, and the tasks
+blocked on it are woken up). The problem is that after the task
+has wake up all the blocked tasks, it must wait that all the
+awakened tasks check for an error. To do that, the task set the
+esyncreq flag, and it blocks on the esync semaphore; the last task
+that checked for errors, checks the esyncreq flag and signal the
+esync semaphore waking up the waiting task.
+
+The disk cache can work in three different modes: \label{sec:modicache}
+``copy-back'', ``write-through'' and ``modified write-thought''. Usually most
+time-sharing OSes handle a copy-back cache. that is, write operations are done
+only in cache; a low priority task is used to synchronize cache and disk data.
+In such a system, if a cache request arrives and the cache is full, a block is
+freed eventually writing it on the disk. On a real-time system such a behavior
+can give some problems, because the time spent freeing the cache can be
+accounted to the running task. For example, a task that only reads can be
+delayed by another task that fills the cache memory writing blocks on the disk.
+To solve this problem there are 2 solutions: the cache is not used (that is, no
+caching on write), or the cache behavior is set to write-through, that is the
+write operations are immediately synchronized on the disk, in a way that who
+dirties the cache is also responsible for its synchronization.
+
+If the cache is used in write-through mode, another problem
+arises: sometimes a few bytes are modified frequently (e.g. the
+filesystem information for the allocation of a file on the disk),
+that leads to continuous disk writes. For that reason, the disk
+cache provides the flag skipwt, that forces the copy-back mode for
+a particular block. By default, this flag is not set. When the
+write-through policy must be disabled, the file system should call
+the function dcache\_skipwt() on the cache-entry before releasing
+it.
+
+%----------------------------------------------------------------------------
+\subsubsection{struct \_\_rwlock\_t}
+\label{sec:rwlock}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+typedef struct {
+ __mutex_t mutex;
+ int active_readers;
+ int active_writers;
+ int blocked_readers;
+ int blocked_writers;
+ __sem_t readers_semaph;
+ __sem_t writers_semaph;
+} __rwlock_t;
+\end{verbatim}
+\caption{struct \_\_rwlock\_t}
+\label{src:structrwlock}
+\end{table}
+
+\begin{table}
+\begin{verbatim}
+void __rwlock_init (__rwlock_t *ptr);
+void __rwlock_rdlock (__rwlock_t *ptr);
+void __rwlock_wrlock (__rwlock_t *ptr);
+int __rwlock_tryrdlock (__rwlock_t *ptr);
+int __rwlock_trywrlock (__rwlock_t *ptr);
+void __rwlock_rdunlock (__rwlock_t *ptr);
+void __rwlock_wrunlock (__rwlock_t *ptr);
+\end{verbatim}
+\caption{Lockers functions}
+\label{src:funcrwlock}
+\end{table}
+
+The cache module and other modules need a locker protocol, that is
+a protocol that solves the reader/writer problem: basically, there
+is a shared resource where some processes must read or write.
+These rules must be imposed by the protocol:
+
+\begin{enumerate}
+\item If someone is writing, no one is authorizes to read or write.
+\item If someone is reading, other tasks are authorized to read, but not to
+write.
+\end{enumerate}
+
+In literature, there exist different methods to solve the problem
+with different behaviors. This filesystem implements the protocol
+proposed into paragraph 4.2.3.1 of
+\cite{book:programmazioneconcorrente}. To replace that policy, the
+rwlock.c file should be modified with another algorithm,
+maintaining the same interface.
+
+Table \ref{src:structrwlock} contains the internal data structure
+of the implemented protocol. To implement a ``locker'', all the
+needed data must be inserted into a structure \_\_wrlock\_t. The
+following functions have also to be provided (see Table
+\ref{src:funcrwlock}):
+
+\begin{description}
+\item [\_\_rwlock\_init]Initializes the structure passed as parameter. That
+structure is passed to all the functions and it is used to protect a shared
+resource.
+\item [\_\_rwlock\_rdlock]Read request (read lock); when this function returns,
+the calling task is authorized to read the shared resource.
+\item [\_\_rwlock\_wrlock]Write request (write lock).
+\item [\_\_rwlock\_tryrdlock]Conditional read request (try read lock); The
+function return 0 if the calling task can read, another number otherwise. At the
+end of the read operation (if the lock has been granted), \_\_rwlock\_rdunlock
+must be called.
+\item [\_\_rwlock\_trywrlock]Conditional write request (try write lock); The
+function return 0 if the calling task can write, another number otherwise. At
+the end of the write operation (if the lock has been granted),
+\_\_rwlock\_wrunlock must be called.
+\item [\_\_rwlock\_rdunlock]Read unlock; the task has finished the use of the
+shared resource.
+\item [\_\_rwlock\_wrunlock]Write unlock; the task has finished the use of the
+shared resource, that is again in a consistent state.
+\end{description}
+
+The functions \_\_rwlock\_rdlock and \_\_rwlock\_rdunlock must always be used
+together. Nested calls are not allowed. The same rules apply to
+\_\_rwlock\_wrlock and \_\_rwlock\_wrunlock.
+
+Please note that \_\_rwlock\_rdlock and \_\_rwlock\_wrlock can
+cause undefined task blocking. The other functions do not block
+the calling task.
+
+%----------------------------------------------------------------------------
+\section{Filesystem: DOS (FAT16)}
+%----------------------------------------------------------------------------
+
+%----------------------------------------------------------------------------
+\subsection{Description}
+%----------------------------------------------------------------------------
+
+A technical description of the FAT16 filesystem can be found in
+\cite{manual:DOS330} or \cite{manual:dosfat}.
+
+%----------------------------------------------------------------------------
+\subsubsection{Internal structure}
+%----------------------------------------------------------------------------
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=7cm]{images/fatarch.eps}
+\end{center}
+\caption{Internal structure of the DOS FAT16.}
+\label{src:fatarch}
+\end{figure}
+
+As showed in Figure \ref{src:fatarch}, this filesystem is divided
+in areas:
+
+\begin{description}
+\item [Boot~sector]Contains a small program that loads the DOS operating
+system, as specified into \cite{manual:DOS330}. It also contains other
+informations like the number of FATS, the kind of support and the dimension of
+the Root Directory; It can be thought as a super-block. The informations
+contained in this sector are showed in Table \ref{tab:fatboot}.
+\item [FAT~tables]This data area contains some copies of the File Allocation
+Table (FAT) These informations are used to know where a file can be found on the
+hard disk.
+\item [Root~directory]This block is structured as all the blocks that contains a
+directory, with the exceptions that it is allocated in a contiguous way and that
+it has a fixed size.
+\item [Data~area]This is the area where the files and directories are stored.
+The minimal allocation unit is a cluster, that is a set of contiguous sectors on
+the hard disk. The boot sector stores the number of sectors that compose a
+cluster.
+\end{description}
+
+%----------------------------------------------------------------------------
+\subsubsection{The boot sector}
+%----------------------------------------------------------------------------
+
+\begin{table}
+\begin{verbatim}
+struct bootrecord {
+ __uint8_t reserved[3];
+ char oemname[8];
+ __uint16_t bytespersector;
+ __uint8_t sectorspercluster;
+ __uint16_t hiddensectors;
+ __uint8_t fatsnumber;
+ __uint16_t rootentry;
+ __uint16_t sectors;
+ __uint8_t media;
+ __uint16_t sectorsperfat;
+ __uint16_t sectorpertrak;
+ __uint16_t headsperdisk;
+ __uint32_t hiddensectors32;
+ __uint32_t sectors32;
+ __uint16_t physicaldrive;
+ __uint8_t signature;
+ __uint8_t serialnumber[4];
+ char volumelabel[11];
+ char fattype[8];
+};
+\end{verbatim}
+\caption{The DOS boot sector.}
+\label{tab:fatboot}
+\end{table}
+
+Table \ref{tab:fatboot} shows the boot sector structure. The boot
+sector is always 512 bytes large. The struct is only the first
+part of the sector, the second part is the boot loader. Here is a
+small description of some fields:
+
+\begin{description}
+\item [sectorpercluster]stores the number of sectors included into a cluster.
+\item [sectorsperfat]stores the number of sectors in the FAT
+\item [fatsnumber]stores the number of FATs on the disk.
+\end{description}
+
+A note: when DOS formats a disk, creating a FAT16 filesystem,
+the informations that comes from a pre-existing filesystem have
+precedence over the informations given by the hardware. That is,
+if an hard disk declares to have 8 heads, and the pre-existing
+filesystem has headsperdisk=13, the new file system will have 13
+heads.
+
+%----------------------------------------------------------------------------
+\subsubsection{The File Allocation Table}
+%----------------------------------------------------------------------------
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=7cm]{images/fatfat.eps}
+\end{center}
+\caption{An example of File Allocation Table (FAT)}
+\label{fig:fatfat}
+\end{figure}
+
+Every FAT is organized as a table of 16 bit elements. Every
+element is a cluster; the element value gives informations about
+the cluster:
+
+\begin{itemize}
+\item 0 means the cluster is available.
+\item values between 0xfff0-0xfff7 are reserved; for example, 0xfff7 means bad
+(damaged) cluster.
+\item 0xfff8-0xffff says that the cluster is the last cluster in a file.
+\item Every other value index which is the next cluster of the file.
+\end{itemize}
+
+The FAT is used to create a set of chains that make a file. For
+example, Figure \ref{fig:fatfat} shows the information for a file
+stored in 4 clusters (23, 27, 25, 31). The first cluster of the
+chain is contained into the directories. Please note that the
+first cluster of the data area is the number two, because cluster
+0 and 1 (the first 4 bytes) are used to store the type of FAT (12
+or 16 bit), and the disk format.
+
+Directories (except the root directory) are common files with a
+particular structure. The system usually give access to
+directories through other primitives (mkdir, creat, and so on).
+
+%----------------------------------------------------------------------------
+\subsubsection{The ``root directory''}
+%----------------------------------------------------------------------------
+
+This area has the same structure of a directory file, except that
+it has fixed dimension, it is not allocated into the data area and
+its allocation is contiguous. Common directories have the same
+structure except that they are allocated into the data area, and
+that they can be fragmented.
+
+\begin{table}
+\begin{verbatim}
+struct directoryentry {
+ __uint8_t name[8];
+ __uint8_t ext[3];
+ __uint8_t attribute;
+ __uint8_t reserved[10];
+ __uint16_t time;
+ __uint16_t date;
+ __uint16_t cluster;
+ __uint32_t size;
+};
+\end{verbatim}
+\caption{DOS Directory Entry.}
+\label{tab:fatdentry}
+\end{table}
+
+The directory structure is showed in Figure \ref{tab:fatdentry}:
+
+\begin{description}
+\item [name~and~ext]Contains the filename in the classic format 8+3. Non used
+chars are filled with spaces.
+\item [attribute]File flags: they specify if it is regular, a directory, a
+volume label, it has been archived or if it is read-only.
+\item [time]Creation time (2 seconds resolution) (all the 3 times specified by
+the POSIX standard are mapped on that date). The time format is DOS specific.
+\item [date]Creation date (until 2099). The date format is DOS specific.
+\item [cluster]The first cluster of the file. A value 0 means empty file (the
+first available cluster is the cluster 2).
+\item [size]File size (32 bit).
+\end{description}
+
+Note the difference with the typical Unix file systems, where file
+names and file informations are stored in different areas.
+
+Directory entries are not contiguous. If the first character name
+is 0xe5, the file has been deleted, if it is 0x00, it has been
+never used. Any other character means that the entry is valid.
+0x00 is used for efficiency: if it is found, directory scan is
+ended also if there are other sectors in the cluster that contains
+a directory.
+
+%----------------------------------------------------------------------------
+\subsubsection{The data area}
+%----------------------------------------------------------------------------
+
+The data area is divided in clusters, that are a set of sectors.
+It starts from cluster number 2, and it stores regular files and
+directories.
+
+linear addresses are used to identify a sector on a hard disk, and
+its cluster. Hard disk sectors are numbered starting from sector
+0. The filesystem specifies an algorithm that associates to every
+linear address an address C/H/S (Cylinder/Head/Sector).
+
+Some DOS implementation supposes a particular structure
+depending on the media used: a 1.44 Mb floppy disk has sectors
+composed by 1 sector, and a root directory of 14 sectors. The best
+way to implement a filesystem is to rely only on the super block
+informations.
+
+%----------------------------------------------------------------------------
+\subsection{Implementation notes}
+%----------------------------------------------------------------------------
+
+The filesystem maintains 2 structures to store file informations:
+an inode structure and a dentry structure. In the DOS FAT16
+filesystem unfortunately there is an unique correspondence between
+file names and inodes, and that information is contained into the
+filesystem directory entry.
+
+\begin{figure}
+\begin{center}
+\includegraphics[width=7cm]{images/fsn.eps}
+\end{center}
+\caption{The FAT16 file serial number.}
+\label{fig:fsn}
+\end{figure}
+
+When the system refers to a file, it use the inode number. That
+is, every file has a number that is unique inside the file system.
+
+The FAT16 serial number has been specified as shown in Figure
+\ref{fig:fsn}:
+
+\begin{itemize}
+\item The most significant part is the cluster number (the cluster where the
+directory is stored).
+\item The less significant part is the number into the directory entry.
+\end{itemize}
+
+For example, the inode number 0x01230008, refers to the 8th
+directory entry into the cluster 0x123.
+
+The cluster 1 is used to index the directory entries contained
+into the root directory, whereas the cluster 0 is used to index
+the root directory.
+
+\bibliographystyle{plain}
+\bibliography{../common/retis}
+
+\end{document}
/branches/new_sharkdoc/vol6/vol6.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/dentrytree.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/dentrytree.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/dentrytree.dia (revision 1676)
@@ -0,0 +1,19 @@
+‹í]Ër£8Ýç+(§jV6FâÝé¤kz¶S5‹™½K6ŠM7 Ûñf¾}ÄÃ!Ø'ÛQªB
+,ß âžszäë·§8Ò~aš†$¹Ý}{¸ù„è ÿ]Rk¼A’fg÷£cë/Óév»Õ£]Š¡znôOÿCQ„¦¼Ñtôp£i/ˆ¡ìZy1FÃù†a-A1¾ÍÑâ璒MŒŠVe»‰Õ~¡è~tû˜ÿŒ¦¥˜iMÎ+²×hé¡ØxMҐ7a»õQ“9ÙñE›²UÊ%ˇÛß­Ûâ–Ê •¬¦mUÂbD—ar¬‡buî{áý
+æ²D²PÙ
+Ât¶&”Q²c%sB"Œ’B£Ü]Oº@7•×t—þ2FNÜÿ#ŠÒ·<@qù5­,.@>W¡¦å}¯À®ý
+Ópá²+_ ˜Ìà+ñù7CI€h M´ïäiTQ•1ÒÂà~ô—QÇ÷a_paü•¦‡_“0aEO˜c§ê‡¶^h=ŸJ¦üÞQ²ŒðÞ}{lóÃàäj}~è¦G8ž-MŽùª§ÉÅoÀ­ŽŸho“ž€è—+Ö.Ûì&;]‘í¬Á‡œÆì{´Ý>£(7iû3€ҋ‹…}w6x jð@®ÅƒÊäá &>›ÍÏ +¸5ž¸qCç )îÿð,e»*ÀÉ&.¤[—VØZ +éh£%\Mùp5”‹ºõ'GqƒÕ›ÂVïŽM‰VïèÀC~¸®îÙc‡ºv{’Ìpä÷þö':þÜíêÄ8[.ևŠ+µñ3D)Ù¶“³¨äY„“åëÌUqÒE¾QCö–¹qO„UŸh+ŽŠ,Ÿá `$§~­ú”ÛÜÑÛoø.(¿kÔ¿{Ô×G7Ôn­3Ç-8Cà…\…Ü
+¹@2r›ÃL[¼
+€ì20ª:°¤Bº>
+3/$·rzÈ­€)=¹ÊerŘôìªë#©jˆª†HF¬+ŠX(¹Z_Õ.ÍAj—PÕ믾â]NRÏ%©‚*©RIU•T¹SñE‘ëŽ}ÙUL/Ãm[žXIÇm큚>îšt)؞)l +ØÚ[`\
+n‹"&0?¸ÜwMr¯¹Î‡T1è!?”Zс/*:æ0¨*:ª¢s¾Ù-žáåz[X¹[8˜»…'ü-Tþöêü­+2j({ØðüĚÐÛÇL™‡ÀÖ +Ž +ÓöáðtxcPœwS̲¾8z7õu!mÚ\I¾â£Öî`qH€Fw- D^™Øß6µŸ$¬I]v½lòÙАGS=GžýÔ
+…÷«¨›ÕiÓê¢#_DÔ¤ååê"#ÿS„¢p™Ä¸ùå4rèëË:šV]ôãÆۈÀϙ]‰<PЀSÀþ® W‘Àõ“@ͬH廇`À• ìY(øL±€â¡xÀé!¥—É°ÎPñÀ§á¨x`8pÅs¥' /8eR`~¦Xຓ Ä}Ì_–ü´˜ìK„–"‚OQ"´ Ä~yT&€u&€Š >Sb ˜`(&€F1”ø>Øf!aøcx)‚ßþÝv7-þ(>è¨a(:â…OzÀ­ +z—Å+cE"O±Á@l{(šòˆ°V64/$G(HàZüTt T@4 Ä}Ì1”dØw¬çøºk:— ,Hò.õt—*^ÊTœ0/X=”eò´t×õ+^ðuÁ¥ñBœDQ‚XaQQÂP”`÷1Â`K^è€ýB¾Ðô¹Ê‹Ê¸ô˜¿
+ÿUÌ 6ä`+jˆñ-eŽ8˜Ïƒ +æåŒ3(ÜwÁ½©FC½ÛÇä#[~ñ`”Ń 8x‚ë쉩x@l2’Š†bO|”a"u«ݱ=®Bw=ÇٶǦÇXœŸ?3PBØ,)N°š”Ôy˜a¢†ú&„–H ðìDä20²H&Ùö#åÎ_Æ;m‚lðZ†Ú‰ä*v"Í[m¾3‘â<ÿύ7µíøpó?€°m
+3v
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/dentrytree.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/fsn.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/fsn.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/fsn.dia (revision 1676)
@@ -0,0 +1,8 @@
+‹íYKs›0¾çW0øJÂ<L;ÓôڙÚS.a+X­,y„'—þö
+Lb›‡‰…ékì3ƒ´³Ÿvùö“nÔxÂ"%œMónru;'èZý–†2`iv76R®®m{³Ùú’"É d +RlÿD”"[ÙæäÊ0ö̑DÙX1Š¤$^Kl0´Äc3F³‰àk67·V…ÝŒS.Œ'DÇæà1ÿ™váÆ>ðsÄ÷
+­°(»]®xJ”‰|YULüd×=›Â*UF,™ >zƒí’Š¯º…6‚È% aUÝ&Â#÷5 §Ä}оDß$®¸Y‰9§±-Žk¬“ÎUT9Ô÷þH¤ä-ëD4}OÛá·ªi¬ÀíP©äsXŠ^°(Vv¿+v㉤$¦¸Hå^óø;žÉ¢>¿JÄæH̍Æ=6wR嘙Í/Îa}—s¡œ©Gš–+|Å “ÛL -o—‡¦,4¹Žã²g¡ÖŽXBñ+#ßªË +Œ€ã[#uуÃ/§3.XU¯ÎMî~CærQè“Aß L’…lv®¹îtÁ7ӚM¤½hë÷{GAmN®œô,¿GNft´¼œ“0ãdØ3'µ£y'Ã)éþ?”t»RÂ^9 )G¿ƒ”úñ\X©ÁÊoøYÖÐrxZ{¤¥</°\à¡ÝÀø¾§¶óüVVf‰(–›’’MÓÍۍ»RgòHT)DQ‡­—1 +Ê‘fÓ“3Y&ŸøZUƒvœJ1´•O‡8$X;Ét0òn¶e¿Íuò_7 ÕW$l‰ëV$8-eµÇÿó(ÂIPò™0\£ ^g]ð€ÚCúÜ°† ð­@µa…`ä[‘ºhâ ¹˜æk?%¢‹è¨ExÊüÉ1pUﬢn +¬+Í9Gæ ÞšT‹Û6jh:O%rŠ„à›æ€½Î¾§³äx£î ­IÒÄÀlޖ"ØÑs ÚAœ+=3ΘR¥tiåð:c,”Bf¯E”JžŸÜÝìج´à§çÔa¿«‡=ËpPRaÕÑö+Ãa›
+g¶¨ìI¾èðE‡ÿ´Þu¸¡C:Ÿ„#}1y×A8^XÐɺâàƅÀw½L‡³Û¿¿GÌè:•—ÎX³3ŽJ[Ù¥5îïeYx)ˆúT‚8#×oË\Dp¤úâämÙ@QC¼\t@S¢‹ œ*Ûûüùäêà úäêjæmkš#
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/fsn.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/dcachebuckets.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/dcachebuckets.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/dcachebuckets.dia (revision 1676)
@@ -0,0 +1,10 @@
+‹í]Ksâ8¾çW¸˜+k,É)™dkg¯[µ‡Ý;%ÀÞ16e‹<.ûÛW~€ÁX!±,mœQª‚ G¨ÝâëV¿Ôùúëó6¶Ã,Òä~lgòëÃÍ×UDoùï:£[‹HòâÝýdÃØîv6{zz²ã—œ²4³ãhoçáì_ÇtÆÍ&7–u:ÁŠ2ZÜ«ïRƲh±g¡•Ðmx?YÐåu–î“Õ¤U[¦qšY4¾Ÿ|ù^þLfõ4³³y^™{Gwa֞v»Kóˆa/»‹!‚yŠ×“1õ¨œJÖ_~s¿TTßhæêzP!¶¥Ù:J.éd!«…€6†‡Ux?…j±j™jQ>ߥËhÄ.‰,Ò4iRÑaÙ>ìO'_ҘCå5F@ÿÙ¿GŒ¥Wžÿ;ó·0PÝ>JP«[-‘/ÉÆô%Ìê'ûÖ»õåÑ"ë¥<‘âtñO¸dµ|þÅh²¢ÙÊúÅú–>OUåL¬hu?ùÓ9—ïöZðÉøWš·%|—F «NQ³¢eͽX´§ÎøÃÓd‡õôÀ&Þò—;è؎7õùK?zançË4K.5Ö ü”ó?E+¶¹äéK,1õ&ŒÖ&ž»çcç›ôiÞ±\Û÷P©Ö}žÑU´ÏÅ<€+³W7+ˆ÷Æ<Å¼«òèˆx ñ®JÀûŸðƒ@ÊC`՘AJ”£`Ëÿ–H–¾jTz +(‰rLú’Ú ùG”„˜te1É™§”n©*‹×;¯%À½Q¹L“d&«òáßÎRçß{*Ód¿]îڔc¹ß¤Üy ç9{‰ÃöÌ!§W/£0y²`"jÁ„0]`"WÀD~z0ý>³0ù²`
+¦®B,qm„¹skC€<rǑ0ß<Ëwý¨²bZ4ÛÂÖÑFS†þÎƵ¢„ßöË!»ù¾Ü:‚xá+qQ¤'MXÑâ~=ä÷tŸEÜ(˜Éй؞¯¬ÞOâXWÁՇDRî"rkvÊ9B4ŽÖÉ6ìþn¡~ëŠuÆà”*‚@^ʁ¦ðŒ&è§ £ ôh,¯ Q꬀V%—~Ÿ›˜Sè”ïÆ¥
+’-}6Ú Ÿ68E˜Q*ÝM"ms¦Ù*=NbîfBÛ÷îø+.½O¤Úå¼`«3/ןs%Ž'glN³,}û²3Ïã0Y¿4tl,KâJXòÍŠ/›C‰ã=¿Ðÿ‡¿X.!EҚ K‹¼‡7±š?Ÿ9êâƒÃ‡ƒó_D9/i˜ô¡tÎ¥ D¾sæDG±??&g>–œ9 PDiŠ²ª©r”POŽR‚%ü|Í¤só€Ø€"ôJ VéÎqG{œ´]—SºƒÐ.$S·¸ô¥üv+NÄg׎QŒ!rKb¬ºjÕ9çv|QZv†6êDbŽ†ð͈ß 7¾ßç´øfäºoFŒoöÙ|3 ׌›‹j]3‘»H1V-©%¸Ø°Õ 0¾"½x\¢ü ¢;LHW¸_iUB!Á±*o#§*a>ÞZ›7qÎÙºµD& Ñ' qŽ2“…Pª¤ • §6€ Ë´$¬• ʼäh´ÂM­–ð H`´B­pŽ3£†7òÛî6ÚPé `»Dii7L<?8ÖFpËÄEh<ŵZU1J¨·ib*$tUH<T´Ý+/@C´Ý-/àm÷mÏëMùÝÑö >ÅÑv©%QâìçŒfLQ¤îdnuÿ)‘sdbB
+ér(ä¨õCȱa…ýù1ùä±ä“¡#ú’§o€à<ŸŒ€Î|²ÏŽb7;܇Þáøv!Ê ¿‹ƒšRPºnêmõöìAÚöìAÚõسB>ŊÁسŸXÚ¥ Z¢Ø Dµ t­r•fÛ
+ÉñÝcº +v€üÑåێA-à`h¢Z½¢Zç@3A-¥&?’ïYBT·,ÁMǨ£c ¹Ò°š†%]Prå;–Õ +KpÓ¯êèWB®´+ùÉ¡$h9ç +Ðs*ï9šö^ÀSßsš_Ú|‰Œèú褼€Ub¸êŸÜ1š7¦sÏó¦*ehÓY°IC;„ꏂæØ¡òmJ‚%“&Éy[ˆ8d®øÕ)óøD ð%X2ÀM~” UTXhê8oË¥ÀuasÞ òª©è‚OqÔ’˜“zõ¤^ qà–ï4jÜ
+Ü<ä QŒ”M:øyÕѤÑøyG“L¦¤wý¯ñ÷4MB`€³IJµB±•úîQ-e ȱ^@øØh†žÇ“ŒfЕDEƒõáá²Z\uø¨¼6~W–Réò Ú|¾âÈ,‰©¤úЕTmï ñ<Mu“hˆv<®ún<¨iÆãiéÅã^mÅãšN<ŸÌ¿xÙF<Õûòߐ>ܜýŸÒ‡›ÿÖ5ˆõy
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/dcachebuckets.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/fsinit.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/fsinit.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/fsinit.dia (revision 1676)
@@ -0,0 +1,10 @@
+‹í[K£8¾÷¯@ôeW"ófzÒ£™Yíi¥=ÌÞ#܉wˆ‰ŒÓËþö-é4àÞN/‘‚„cªlS_}Uvåó—Çu¬ÜžÒ„ÍT¤ê—Û«Ïşà»äx­@–fw3u%ÄæÓtúðð ÇO) ×cºÕS2ýÇ1žB§©z{¥(‡",pÖV¶b!8]lQ^“™ºÀáÏ%O¶,R‹^e¿0‰®Üãx¦^ßåuZŠ™Vä¼ {ƒ7„×Å®7IJ¡‹xÚui‘“]ú”½RèĖ·×_íëbHeÃ^VÓ@[•ˆ5æKʎõp‚ãb!LÝ7w«ðz Ù
+bÙ
+¸l4o.8¦âXÉ"Ib‚Y¡Gð-é®' +q ¦òÒDPwéwTˆäÄøïpœž3¢ù5­,šjÏÕÆø‰ðrdßö`WîiJ1)—òÅÉâoŠŸ?fæ‘2Qþ Œ¨{_e¨
+fêŸFàõÅiðNÓ:Ä7 e¢X
+_³ö Ѷ m¢‹ºdƒÇl“Bº§#G3árãë¾£!®Ýԅ cs¢|ègO¨égdtÛ®ÃM]ñ³\ÔM(ÌhŽ9Oê‚ ¨Fò<&l)VÇoj6x)}U<Ðh +Ù[ OkÂö¿(+EÀ€HŽªì©îÑëox•Ï¢ê³Gk}4 ¢¹@é°ý–<6 õE­Ûيς­£ŽÀåkn=¸v´‘˜¬çaÂÙq 1È|rù'ÌÏî!zEèr%Úe{Ýd§+@MCôwšm›À×Yå_äQ4˜¥ÙŸL\6qOC¦n"ËF± +KCv~×M«ÈÖáÈYTcäZŸ¶÷™G¿•~µ@ù÷«-‘ò N[Œ“0Ѥ+k/»|O¶œæ¦}ôÿ©Píõ*ªuÚ¨ºèȳ©&-‡i–‘ú)‚¸vÉÖ¤ùå42úËñmSø9Œhæ%«¯€`O&/Ù/¡‚˜PFL¦)™˜ºOèbr%“ùˆÉîOL&’j—¾†RðX&²@߅ðÒo4ý©|ÇኌôԍžL4ÒӛГÓ× +ؚL/`eìdää”Ñ’fIæ¦Î³9‡šü‘šÎ¢&wj’ÊLŽ )SÆENQ“m7·3ј¤O© ët$§Žä4rÓÀÜÔ²ïõwé[ñK÷w{ño±?9µÿŽ¶âS¹´ [Þvü¡’¡6äÇóŠáÎ+PóyÅàg-Ê`w×“í û|Xh¾Éaáá”ùÓ]Ôè¢þoGª¨Ç‘ª%Ù½µ$bA_÷†&Ó½xw—†ùºí™šw)iX]4O·ÂùuÌúäaUÛú‰˜ñß'b-Žõ®‰B–Èô–æï<hº/0"¿ò+¶4nÁ ‚ü¯<lþeU–îH„þÄÐ+0³D'ËsÜ|#ÆÖ-ÙyN}bM‡ ·¡Ã-¿'óˆBhÏBÒ°NlÝu¬“|/A½õš Þi}VjPz—¤Ml͗ h{Æßøz`º;fÿt~÷|¶2çd ð£û®_µ±1º—X€z—¨Yš-јY +€•×d5ӐòË­è<›sjýá‹Zñ˜­ûœãˆnÓèMJ Pïò7dhŽÔ¿ Ž©Ù»œÖÖÛלK"ÂyɄ™ä‘;å¹ó\©Á ÖIeAÏ@…îù®n ÷4¤Aò›ÝþEǔQ1Æ]ˏ&cmìI§Ð'§÷ªy¹ñê¼¼¸Ïÿ¦|{UùóíÕ¿à´ A
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/fsinit.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/arch2.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/arch2.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/arch2.dia (revision 1676)
@@ -0,0 +1,15 @@
+‹íœßoÚ:ÇßóWDé+Û ù±®Ö»{·I“öp'íð ·&FŽ)íËþök’´@ ¥ub
+÷ºR‘ˆ¬sbû{>çÄvxÿá~Fí;³„¥WtóáÚz?Nð;ù?áxfËi¶úvåL…˜¿ëõ–Ë¥K2,wi²p3Òû)Å=Ù¨ç\[¶½i`Œ^]+¯b!x2\b§xF®œ!ÝN8[¤c§hU¶1ʸ}‡é•sñ+ÿsz¥™Þ–glÏñœðªÙٜe‰l"æ;Mjì¬>7ڔ­2Ù(\_|ô/Š[*/¬mí»ÑZ'b†ù$Iwýp‚i1ȍÐã(¼ÞÁP·ªÛ×í ÉsÆljØu2dŒœ~_u?ÙS)•ç:_`½¸ü$éÚð(.Uâ1÷GñáåMݬ#ѾK²dHIÙύcÃÈH”Áó·Àéó±Ýµoؽ³æpìd|å|ÛÁWiLŽwV +¿9KRQŒB܁þz ꆡÎöpX5ÍåÍãtBIa>rã~zòó†.èwŸj %³Áˆñt—'­t(·¿LÆbºÛ©GÑD +LOI2™Šzہší!ãcÂÝ8p¡šùlʖƒ=9äp̾Ƌ V2ÈÄ%U$]Ì
+뇦µ¸Xďr@Á¦µ’¸Æ€òó€Š7
+i(õ½$  ÒQè$$ߊ.QsÐkçüæ¡~ÌÊÊ«F“לòP7äÁ:š|툇gJxï¿Cx¿Mj¯<6
+¨¿ð€¦ðxsYö[%Ò^à +]–Èèò­u´ K_».ó’8>ÊÂG_ë‡z%ñ)ª2l®Jí¢\kêפ‘äñ$ùƒÜ‹=šŒšjŽΠºQ؁.‚^?¾”ÙzR¢ù75§b5 —Õ]©J›ºéÌ÷›¶ÚU¶¦þJ(É2Af›Ž…ù¬f·ê™=Œÿ¿X*öy_]/›üÁ<‘1Økâg'm—¼ÞŶ«LÅG¾£¹ÏËæV'Èÿš9Â4™¤3²rÖK/²½»LZ‘7EBØék$Bàöã°ã—H]xòÉó\`}´~XÐ
+ T0°¥,C€ …ÊBí¥X…~P–0¯‚ÓçÀ§$»µGx4%Šõ„GBlžV À_-:?² ô‚ÕúÊyÀà†²Ñ­=&wÉÈà@žÁÁ‘p€š? À@ûì4(ž`t&0øj}²þ4P{:ؔ•€V4>%€ÖÕlç( /È1žËBÁë«õÙúb@ ‚mihß´–% 끒gS|³¾[? +9`*‚ÖAPs6¾…³@]íç&»ÐOg´ïow¡9
+ôæ;Ü0haõ
+h=ï‡A§ Ü0
+|]BÏí#¿ŠR~†úÉñ|.‡Ý$)ŵ+`rԑŠÕ°ã.:³TìQ´:X¬d#׃Hz<“Zõ3]˜lå.fC«m |KR²ÍO½Ez®Ë
+æ'ס¬Vc7ÊߨˆËÕKÓIÇùý¿¢W{ÄÊÝÎ_ïÒö†šÀ\ 0çlYÿòjl{@I:y¾Qs')j·n® ’ÆçÀ¨åeAm¼ÞQœ£W¦{yÄ‡ƒä`‰ÐÎ!ÐÂi-g
+ŽÉræ‰crŠ¢#LÑv2Ý:Õnkå˜ìœ&Š=YÖÇ°µ‹!‚-¤y =:ä“ôà(IÀ0)þ‘âj!í¾ òEÛ¸á‹Å¯I i\ â{þƒO×ÖÖ/B][ÿùÊã¢N
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/arch2.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/archlow.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/archlow.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/archlow.dia (revision 1676)
@@ -0,0 +1,5 @@
+‹í[]£6}ϯ@ÌË®D 6MVÝnU­´ÒVj¥>F&xZbGÆIf^ö·×|L$À™fJFƒX÷bsï9¾>ÎÇOËHÙ`‡”ŒU ê§Éàc¢âÎÐR +HœœÕç«Ãáv»Õ£§qÊô(\ë1þ@Q„†¢ÑP åÐ@€8J®åWç,ô×+-ñXõÑìŸ9£k¨Y«¼ÝŒF”)Õ»‡ô£s3¶Wh…YÙìrEãP4áO«£&5v’ãA›¼U,‘ùäîgë.{¤üÂÞVՃÖ:áKÄæ!9öÃ0Š²€º ŸGáå|Ù"Ù˜la<]QÆ
+ù±ŸÒ#’ùál›û‰g(¡rª# ¹õ‡szæùP_ҁìò.kj30»TJùÔm„ž0˟ìó>ٕM‡~„ó¡<Èbêÿg<ÏÏ?8"bò“ò™>ª{¨2T% Æêw£˜ßå±ÆÄ+Ë¾¢!áÙHXš»‡ºQ¨3íûeËL<;"ógÖMݳµ‘8ÜG7l +âØÌŽðr:£ŒVÝIÍoÀ/Ž»´ JØÂö‡ó¯7ÞÐv¼ Ûi‹œÏÚj"îcð‚ ü?òŠ¨m£š'1,m…PsuLÛ»–îY®æe§ÍÜòd JNËd[jS÷BS-´+1î¼ gXùJ8fh†kø÷nÖ!'%¼Êqr=oò ]³Pd఍Ÿ£T8G/wQ ¯ó!ÖÄG:G«òr8y3ÒO;G‚-çd‰«_&ë刬’ÔºÁƒo!Áx;ÀS"x:°5(÷‚ \[ ƒÛ¥f”)&Aúì—÷¨ò~C&ñ0[•=ïí6¤0Lct[6\~,O#Læ§èW¼š¶.ÎüÅ’×,BHy|úÏw”…H‹d†T…Ót®¦ìïVŒ×‘ÑnÈØl›|#͖˜{#ÍÚó°5‚šs+<ìx3Á¼{?H¿o™pòî}ÏÇMø¸eoŽ×§ãêšÑj_3SvÑ`R5fE£'½hlڟKªF™E£s‹EcuTÚ́ÜIâ.,ÅñqÙ¢G}`vW½8m#3Y÷’˜VR½$%̽/À”_½{Tyß쫗7U½X’«—šäµ¦ 7û€±K?®•¥NU7è3ðme ý:ënôgK¥?Ûi ]EpZ†©Qzöß_Cø:ø2øµ_0h²`P «~_¦ çuÁ–\NQÀÌP@0ñMÁÀ·Áwñ÷{”¼blõH UÚo½ãÄѐˆN²É$C·,˜,ÙÜäRÂ_½ŠÐ ŠÁÕËR¡ ý6( ûÏ`àÜ$ô’b›‰ìÑàZ¢"€íUEe«Šì÷¢BKº¬a¿õõ7£š(‹P¦²èêŽëŠ`ÙÕ®¦@.hÞSý­û-¨M· B³/\¯³X¬c{²e\àît\×Ðq½Ó:nS
+“¢"Å1.IG:°-OI:tҕ–ÔKmÝImFµØí\Iìvëìžtµ;C©Lî¾L•zUÙ ª¨þ@e·ªì<ý•êdPøëdð/«Ùc?
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/archlow.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/ide.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/ide.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/ide.dia (revision 1676)
@@ -0,0 +1,10 @@
+‹í\[s£6~ϯ`È«ƒ-an›uvšî>t¦¶“íCŸ<2–mº¹BŽ“—þöŠË›‹m@d£ÌÄ3€|Ž$¾ó}Gø ŸžÖ¾òˆiè‘`¢m¤~º»ú8÷Ðþ¿¤h­ðAMÔc›Ãán·Óüç1B5ßÛj!þ‡| +y£¡zw¥(‡戡è\z1F½Ù–a%@k<QgÈý¶¤dÌÕ¤UÚÎ%>¡Ê#ò'êõ"þS‡©™á‘¶7hƒiÞìzCB7aϛB“
+;ÑçA›´UÈË»ëŸÆ×I—Ò™­²ŽV:akD—^PôC1ò“‰€š +¿ÏB}³®ø]; ];ðÂé†PF‘ÇŠNf„ø‰F·¸¹ŸÐE>‡Ê©€æÖcäLÿÈ/@rz5•˜œÊ…|ìÖGϘ¦=»Ï‚]yôBoæãt*¢˜ÌþÁ.Kãó¡`Žè\¹QîɓšQÕHU¼ùDý}tßù¹àÆø- +ó¾!^ÀRÄ Œlªf¡Êôl–·LyßQ°ôqz5ÇŒùÇ­ÎÉÕƒ6ó‡}¼žº„EÂ1œØüΛ³UqHûèrZØ^ao¹bÕÆÁ¨™ñpEvÓ9¶åJ2Ì@x€ÊÈøæ¨õp
+ΉL©Å›k¬æ´PÀk9b­±f„X`FˆuŽ[×i9h¬º|Ù-ð[ ŠP âêS„òè~ÅO¬»PvØ}€×Kƒ@7œÀº3°“ÃæÎY4-×ùT²ÐªêVÇib®e.§üåó…Ϧ äâŠôòä8ª“°rßѕ´ÑÏdK=±Ã¶ÞJbæ\®ÓÌQ}— °™§xaRîëpÍ2ŠÿÚ»ã‰â2X㪛†ƒíºþ$–fuµˆ$9s ŠBDR#’ô£’`”É$Ð{ÒÉ6ƒ“BÙ­PŽ %€8®8š"q4o#øŽî8>|cR)R˜@#O*äkSHCÃ@؇DBi¤>êQ#[OŠd·"i
+°Ù‡HB¨¦µIèhc]£"©Püï‡LŠ¥±, PŠåkKK”Xö¤•RٟRJ¡|­Bi JØ |M¾˜LŸ»F֝|{Ï]ÿÜb®‘ÊÄ÷Üg©””R
+å«JGÓè}èä^&!èO&õîUH™l*“`$è©k÷:ihPïeؚešoQ&ï}â~S>ãGÏÅÊÃvÆÏ#&§÷Vêe§zYÅ0¿z.cжȌßR½Ë*3 ƒ 0nÔlc`ñfþ\SÌãÎ_>¤ÒëV³.p¨¸›¼çÌnÃ*1†(›"JÉ.oº› +mO},O•Ð4»½“3ez}ðûÞÑí-w7A™ QÓÅ4ÎaÎXvEYqöˆÊX9Y0çÒJvu¢š…)ù.H¿ Ž¿[˜ëB‡*ŠëòÀoNçüfgüÆOôAp΂@2œd¸÷Æp Ãé/Äpº†ݧpà ‡ý$qà\d'IîݑœÞ&³^ˆåÆ­_†2ç4±4ö Uhö•ÈåUÚ@—'9î½qœQISç9ΪäÇn)ÎhÈ×íˆOäbŠ‹Ó¹[˜$r°‡D®PWRê%ÉI’{ç‰Ü¸ÉåRï‹äL«ÕØùjõ&"¶ï«Õ^«7ðÜbURœ¤¸÷Bq ü'‡ÆËÍÖ{X‚Þßìi—p°Íõõþæ°Ñþ£–Ù¢^àì~«[ƒæ8zHœ¼¿ih–Î×Λ|5%Ü`×[xîÕÒßÊ2"osÊý^¤Ž¨Š^œÖÏgÁÀì2­7ã:~#-P„F\Çoæ ëøÍQÅetr9™¨äá¯û‡¿¾~ù­’FNáäB
+¹ˆ@êú)%ÓÔQ×E‘6N¬‰2¾¸ˆ-ê:ªbŠÓ<Q-‡åqÑaÉq¼ÓÝÝÕÑVxwWÿÇeÚcS
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/ide.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/fatfat.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/fatfat.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/fatfat.dia (revision 1676)
@@ -0,0 +1,13 @@
+‹í]o£8†ïû+¢ô¶%Ø`>¦ÓŽfVÚ«•öbç>r7e—@dH“Þìo_CÈð(©±Ñu¤F
+±l ïûÀ9>5_¿6áä•Ð$ˆ£Ç)0Ìé·§›¯«akŠ7Ö J²OÓ—4Ý~™Íöû½¾%8©;#!³qâk4›>ÝL&ÕV8ÅÙ¶b+NS,v)™DxC§ ¼ügMã]´š[í–qÓÉ+§·Ïùk:+º™Õúy§ï-ÞÚìv³“€5I߶gM:úÉÞ+mŠV k­Ÿn¿Û·Ç]*6”}µíhç éÓuC '<…°=@({*{€ ™ocšR¤çƒ,â8$8:Ž“Òá'YâIå½ü½?i÷ìÿ3“Kà¸ù—k:xÜÔ°|>lˆß-öìGiöÉk‹§²ââxñ7Y¦…?ÿJq´Ât5¹ŸüˆÓUæt¬§šu7ÏëŒý¤IÓáÛ8ˆÒâDƒ;»<]§¡«ïÅ¢Ù5e;£uHŠîMÃGw{{È0ѝÃÞøÆ#!Ù̗1Î‰%äxòþ÷Á*}9?¦“,‡týB‚õKÚÝ7äë;y‰÷ó–ËH¿mÛ¯$³R„ܪTéHW%*UéÉW¥£UyeUBªô¤«Ò-UÉ6H—¥§eyeYZd Léºô+º„òuÉ{DZ˜Â„i‹&”.L*Ê´(je^Y™H„2å‡= ÷Бϵ•éˆP¦üÐTb  ø:ú¹¶2]ʔþ€JüÄ?@@×V¦'@™P~*TA©SæADZ¤é"½sa‚L˜üñÏ2Ž¢9‰VùÎ_~H­ß[|»í6Ëmsä²ßË:͎ƒ$ö3&žÊo&/ì‡Ï&_ØïœÆù4ʤü6Û<kÎ5:#/0|úÉ՗]ê ©Òêѽ¾ *}‰˜ˆòS8”ƒ–„AØÃ08:‘yu‘!U"ƒ &WdvEdH™ÈPŸÈÐøE檙ˆYK~ŒPrL +Ƭ>Š]Q_gR짝'é[Hš=6Þe‰ 5ِeI'VXjxeõáJ«©MM"¦# |8ÁJœÕŠ°—O¶–T›¤÷Tò +¡!TÂ^HýÏ%õ“Ò6I +žðïDAyôí;ۀÀBþƒo¸¦s‡ŽŸøFM³ópvc[¯o´éJMæ•íµv"xhuÁ¿S¼ÜU¾GiÛPÙö¢ÉoñŽ„V}ðñqÎÒ¸}UØ¢.§^Iñ ‘ÿŸDÛ Õ 0ó×°p¬£ +iÿmJ/_zÆZ ËåúßîWºÿšÿÝÑøßÖþçó¿«ý¯ÈÿþpÿûÒýïÕüïÆÿHûŸÏÿ¾ö¿ÿCs¸ÿ`fžw
+ +>   ˆ@,ù€5Xc!€« ÀIK@ ÈO»F4xšœÐY@U°@~85¸c!€¯ ÀITE[ä'W#€?X¦&'t&PÐp@ù™@X˱d-  ÀG¨3ª0¼¼Ì’Z ”å+Õ@ÀY9Îr1 ®*Í© p0@êt@Ó|@ñLèš^èeðPÀ—¯~'0šÂ  +pC@çT1ÀÀW>œ:FS|8hp2@Ï
+(b€eŠˆ€‚hÀ¬GcI jðG:/¨Š@$OB'
+ MOOTE(‚
+‚S•Ð‰®¦À§§€ŽTQÀA©ÁS¥Ð‰¾¦À§§€Î +ª¢€-€R‹…²õŒ<ø«Z([—xã)2¿³—&' t͐p|§Ë6 +R!¹ Re+³·v à¡üy(T°"zAªü–Á¹*ÕrG_É|$ìX—¤{Õõ{Ëð]‡ûÙDÑjŽ)÷Ý«T=ÏC­ß[“Þ4¼¡Cô¬zñ"Öx¶E¯ŒÚáK+ű;iGº5=Ã~`»ç"ûA3ëÇÕeNŸŸšhWAŒQ\Fñ [ºO\—°ì.ÖS`“ÚQµ¯©$_½líÕ×-о¢·ªëÖàÂ3¹O¾È­ +ä[ž›­™ëeϋ–nFÔûhÉWª{}©ºš7Ö‡xüâ7BŸnŽØߚâÍÓÍ’È©ë„
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/fatfat.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/ideminor.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/ideminor.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/ideminor.dia (revision 1676)
@@ -0,0 +1,16 @@
+‹íœËnã6†÷y
+AÙLW©‹åÉ8ƒN»`€.ÚÕl ÚfdvdÑ è8ÙôÙKYjdÝmêÒñ”"@$ÍCJÿùHäÃǗ] =c.t`˜úÇÇ»‚Þ‹?Ÿ¡&„Q|·Ð·œïßO§ÇãÑ^#Ä)3r0"<ýšŠFSýñNÓÎ;Ø Žâ²´qÎÈêÀ±¢^è+´þæ3z7zÒ*m·¦eÚ3
+úýÓé£OÓn¦¹~úÞ£=fÅnw{ф¿îKMjú‰¯gmÒV‘hú÷¿Ø÷ɐ҂¬¯ªÖá;Ä|–í0Œ‚äA@Ãÿ>…ë +¬†6 m€ +m€DË=eœ!ÂËFV”…‰ÎXÞN´FJÓD€|ïO„sÚ2þ'D—L )~óšZLŠ
+.2 WÌґ}ʜ]{&Y8}”g^7Ø眖®þÂkžzì…Ä6ÚÏÚ'ú¢gð2ulúïf›;‹îÄkŽÊOhOIȓçãM,ùX­ªÞîZ Þpbcf̝ —`¦3qÄEÞ(ðn¹¦,Ìñ¬ç™ŒɆo›´ëv4°ÅÄßòF7ïà{[z\V¬:ü<)NtÚAº é{í+¯;žx»Íí2õB¥^9õÂ^Ô뎡^çM½pDôv›Ûeêõ”zÛÔû…„¸B¾V/ò5Gï<c¯Ù]½k†KnN³¸nv•-: %<ìÖûò²Þ;NÄK_Fü5¨8Éaa71`¨7»½Á1p 2ÁÁq[•à.œÓ‹àÆ8³£‘7®à¼VÁyJp
+ÎíCppŒdK*wI…­K*üñ—Ô·àlŠ÷"4•:Ìê´­Ð]82ãôtîвÚÂŒê¿ +ª¿]»¨V_2ëÅCÆØÀlÇÝÀÖ=ü?î’’³`i£þ¾ÿ+òkTèå#i×`3¢ê¦p‘újè œ‰-.Ð1<g⊋¤=Ʒ˒èZ‘[®wëkê¯?e‡¼8þLP d;«3ê€Ü˜"Ž_"ÆèQ°ïe€C?ü(&LÃën¤`‘µQ¹–]¹’•4Rê´ Ò˜w¥€ðÑA)`(à +Lü|*ë½/¿¢^Q@Q ¡ø/)ÌÎÃbÀ,`@ ÌРÆÐâèW5P(P(HP`Œ‚?ñ ¯‚è|"°å} Dÿs˙?À¹á:±¹ø^r[ÍãçPz-ùT±B›Zé°bfO!_ìsÈ1{Bk\“6ÖpȬKø¡!¯²—§M~¥ÁV8G_i§â·Áæ¼¥ëMc­Ê’1rÊ-¬2sžthž>Ý ¡€øáW¿7Ū’±ê"ûìÞ°˜¥°<Xž8œn¿üÆÈ3Ö>o´w; $L£=ãŸ$©à)(Œ«(¸ÃBÁÉ 0³…µ[Âꓵðš +‰¾iïöbJâݝ¢‚,\E…‘¨`w¥Â|„‚g8óÙ¤\˜¶iMà­`a¦ü_ÆÿsŠúÜ|¿îïô7„ÃÆ +ÏÀmÀU!@^T
+ƒ"ÀíŒkXÀ<¬ÛB€£ …K!`4ÌzH"€Ã&äàÜl…)8
+£! s6!˜ +‹7€Ùm!ÀRBÀL!`4tO%6òÁ@pcÑ@¨ … +°s!6óá@xcá@  õƒ 
+Ž‡€îI„Æa>o,h*H!@…%ÜŸþ—Ûã]=Þý•äôER
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/ideminor.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/fatarch.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/fatarch.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/fatarch.dia (revision 1676)
@@ -0,0 +1,7 @@
+‹íY]o›0}ϯ@ô•æ#$m“ªÝ´×Ikß+\âÍØÈ8Mó²ß>ó±’hÝ2)H¶®Î±/çsáúæ%"Ê3â ft¦ÝToæ£ëÃKù9Œ@“t4S—Bė†±^¯u²I `\'x¥'Èø † 2ÔùHQ¶(`:WÌB!8öW)Fh¦úpñ3älE5*âŒ0®<C2S/ž²Ÿj0ÆÎØ1Œ¯ÂF1K° ›x/¤'½nÅQ‰ ¢áüâֹȗTL”Xu m$ä!¦û<A’'ÂÒ'֟,Oà÷M@ú&à}àä1f\pˆÅ>‰ÏAæ<‚¯P{žd‰”Ê[íџ°ìÀúŸ IÞ³|úµj+0Ÿª”|FKàñbewe±+Ï8Á>AE*·ª˜ù?ÐBõy/ + ”OÊ{QK«2U3õ›¹[ßÕ\H0yK“j…Ç S‘gÂÕì2MYh‚öý*2—k‡4$(Gwô©«Yòr\ÝtµôҎ=.§û~uŠÝdðkˆåþŽ^5ivÀ^".E3¸Õ;Y²õcÍ!r¸hëÏ£”`kM‚îštûÖ¤SjrÚ»&Ý3Õ¤óÿhÒê®Éiߚœ”šv¢üÛ¢´»‹ô~zƒ­ãÛrz—%8×€sæz5Êtº*˜šÓ£2Ǻ;ö4[·€íN¯¤[:¶-Ïôl؎V¤‰¨V»åJLÓ +Íúà¸JË|ǘPîåŽoèßèyšºFEg:_„|f+Žeù]xöÊàPóv<Å®²«« +Gö~¥Žeûŋ™ýºÉN7¤ª¿9ˆ®¢ãRVېöjî ¬ÀëÕ
+&ž6.Øšw.FðõöAÐ'(| ¥xƒ|ŒŒOàmŸ‘Þe®>v'0Óâ_G·K2fÃß
+¾§ÏæÙSÁf°ƒ–vÀàãÞ)ü Ïw*ž<[“ÂÒO#žd<?øT ,žÁ
+ÚZÁt°‚c­ g߬棝ZóÑo¥ÃŒa-
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/fatarch.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/ddinit.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/ddinit.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/ddinit.dia (revision 1676)
@@ -0,0 +1,16 @@
+‹í\Ûnã6}÷WÊK Ȳ¨ %m6Yl¶‹¢@hÑWƒ–›,l^úí%%'±n¶u¡“ì*Àz!™ž#Jsæ 9cüôm)÷˜¦$‰¯T ê§ëÉǐ üߒ¢µÂÄ©8ºRWŒm>Ìfzô˜"–P="[=ųÿP¡4S¯'Š²o D ‰s»³ˆ1J[†•­ñ•º@Áݒ&Û8TóQ»qA%T¹Gѕzq›ý©³™YÁÎÛ´Á´lv½IR‡°ÇMeHƒñº7f7*åƒâåõÅgû"¿¤Ý‰[uÚÂֈ.I\Å¡Eù0uÏ|º í²"ÙT6I盄2Š«‚,’$Â(ÎqÝâî8i€"î*‡&º[¿%Œ%G®ÿEé)ÈO?³¦‘ù©å3Ø=bº»²›²+÷$%‹ïnå‹“Å¿8`;~þÅP"*Såwcõ%VªBÂ+õ£HðòÍàÖø3MËß$$fù­ð4ëåF4݆&ӋEÙ2åâe„së®Íä/—žî90øk7¸ ‰ã9ŽÃìÒOžPÝÛÀèvñvlÊÀÏvA7£|FsDiòP6Œ9Ü0–玗lU}ROdã¥/Ä AO™{wñ´dìåeÅI!¨Ã9ÀÎGU^Þ½Raåñ×|ì> ŠŸ­ÜëÊå§s–îÑVðzS˜J‘o’o5<ÇT¸ÊäªoÂo· +œB×SÚÑ}GóùË%g³Á9íò×î¨8ÂëyÐ¸ˆ =· ¥ì¤7µ{¬0Y®Ø!·‡j®8ÏjòÅ^
+]õæ#Þû7þÆjÜ×Â}yhÒÝ×ÕßBd rU² +K0;êŽÍÄ]© —³íʨ¦'eÒ¥‘¥´û—É×É?“ß&_&_òhΞ’˜Õ#‹wvƒ¾$[J8_g}Ñjs,ìTv½SܯR¶r«ÇÚ_ÔÙ_8žI/ã5nzhµYÄQ¬Ú´·UÉÏì‰â "i +ex>*_$m!’ WI TÒ4Ï¢’ý&wšJBé*i~§*i£’¦|•„:ô8ÐN%}Ý&‡}w*ùk´Å£<%æ(R屝:}w~l +HÜù±„™
+éÓ¬‚þµÚe¨Õ¾ÁfS+z%Šy=LWHÜ,vml7 Ý1™«¯ Ôok´8Ø7Ҕ蓶nBî'BÆ_$f®53?ì[«Óít9+ˆÙM”wJˆïIÐ,j‡Â։‚v’œµÅ©•²ÃBÖ¢*b½« Dz¤]mštë°j5§cõŠ5D$h¨K¸ý#ÁTzabjéÞSeâ…‰é±ÊÄ*L¤ Q&©4±g[^qbd¨òÄX½®zê«7+0-”×?@Wv€ð¹tjž¥t
+ÜÃÊ4Æ5†¨­À z˜-Éá­a%æ÷ +oÀÔd†7n>­Ã nۦ濗u÷ºð§Ÿ'”›æÿã Ðu}\uYì{X‘¯¿"kˆ w«°4_fH°4ï)$Xï'ŒÌïÄü‚/{1ƒ0ÿ3 +êˆújÀÒ‰ÔŸºcù&ЀXïÀlCÆÖ-Ùëò¼êª
+÷£ƒ-½Çóð?psâ:µu}oì}+ɽÕ&¹w?+5¹f_FOm͓Ég[swRîé¾ ßš/B|?§xɉ‹)Ïî Çó5‰~v”ü.’_ô¹1Ùo%ù½ûË靳4[zë‘)¬¬q@t–kð,s½fvZß°¸Æ¹F‹ç1§($Û´ï×À†j΃tçCsÎA höÓb™ÓúšS–Ø·ßž· +ó¼£ažl0EYª4vì +Ó±Wöűcïu;ö@ï–=Q”¹g?7í™Ö9šöºÏgìÚp9Ù»møRûö„_Bðܸ'|ÓòßOãޟ+’’€{NHÒ»qíØi»Ø[÷ε]ì +d¶îùÏ¿) ¾`eCx–½ââ¤j“­î›ä'ï[:°Ûûe^yÏxÀŸ°ÏµiÜ»ã +p¦I•yñMISù÷Ì.MžˆÚ‡,}íì­Êüf¦w{{Ç£ÒwRú¢“R/5óïÝ&ækS™+RGw Ë!t׃6_%³-K›ٱὓz‰ ãA·xPt°1œòãìÇÇ®'…_'»žüÛT +öP
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/ddinit.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/archhigh.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/archhigh.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/archhigh.dia (revision 1676)
@@ -0,0 +1,18 @@
+‹í[Ú8€ßçW úš +±sït¦êE+­´R¥m÷¥/Ȁ ن%¦S^ö·×q`€Ü ‰íâ‘‰`|âpü‹ooÞþ\†ƒ8Iƒ8zݾ}¼{3 Ðkú?OÐr@ Diöîa¸ dõz4zzzÒÃMŠHœèa°ÖS<ú…!ÑB£áãÝ`pXÁ ”]Û^E„$ÁdMð BKü0œ é÷y¯£Ù0/µ-7Ã8ü@áÃðÕ7ö7m«ÕÓP÷
+­pR¬v¹ŠÓ€!›U©HM=ÙëA™m©”Šæ¯ÞY¯ò[Ú^Ø×Uu£µBÈ%ó *ËI0
+óuîžB{ÑBÑÑ‚t¼Š’ €”…Lâ8Ä(Êåd»ËI§(¤ªÒÔнöo!ñ‰ûÿ†Âôœ䗟{MmÌ/º<¢ +N¶wö~ßÙ?‚4˜„xû(zq<ùOɶ~&(š¡d6øcð>þ9ܣʂÙÃð“qÜ¿‹Ï‚VFÒ´ØÃWq‘üI˜š¹uO¡®êɤXsBïEóïôÑ·µìåÞ4uÃրK_»ÉÃ!^Ž§q•Å£9¬ú§`Få&í”Ò4zÔ½ÀÁ|Aê+V·ÊÓEü4®0#§»mµ%핰³V‚¾Z ,ͨ–ÀÌôÒËôB¦—@°^voÐ9Šé ÔKxÉj™U¾:ºvŠ
+Où>eU­üm;o[{UÒØ&e¯;¥uŽ”¶­ÜjÅåÞ¼JýmÒàNJZܤǭý•Z]îá•5ú„Á?I…
+›\TØӀ-^…©Âzj“éÜ_÷™`ö¶»t’=˜’ìb¨S*U÷c³0¦P²óüÅ3œÖÄ= +¨÷ZãˆT Í>Ùú¯“€v×Q_iÝå”ÞMPQñÎR¾n¢XÈ\-ì0š6Ø_q4„™GK\÷«áh½lÿ+ãVɯØE.vÒâ(ÅNÂ;iÊ´“PÙÉK¶“6–b'ᱝ„Wk'?R<&e'ùØI¨ì¤h;ْ)Nï<ýI +‘‰Gw<Oó3rØ~æq›€‚Å(¤ÜÎcÈù9âǟAˆkéѤg’ã,n´•SɌfb´Q¦Å Åê"¤ŠgQ¢­ :B4ó¡ÞöU³AfZÉåâkM‚·ldÞržTò3gY’¯Ü«m¿«<‰“NN7ÂÐÁ…ùãu£ŸA„Ç)لCÅû>l‰pø«û Ç¥BM‚»²>h±€ÕÈú +§öj›
+W…j¯ÏE{Mͯ½lŒ×fڛ¢ižííÕ6¥½Bµœò…®¤t¡³Ïú²’…®RßKÍÀ)YèÉÈf¾»ðaá{ùÛkÊ~ZáHe
+¹e
+=•(ä“(ìH.3K #Á³AìA\FçúòF3EN)hž"ˆt‚p™Ø]>´­›ž½CÆ=ôtØ;—äšòï¥ßB8!¤ z
+!—6«p™ÖcI¦0ŸG)”7Jaij>ÏåÆè\&ôxòû–n;®fíÆàn™æÎݾ&똍Ƨ›”ग़úÊÉFÔO™HYzþ"\.3z€È=®N}k`Ð×{àéÔí}í&qGÑG3vÿ-ZU] ã6ª/ÓUQö¾âŽËJÈ%IüT¬ºRA;Ö=q4oZ™eè^!'Vu–AyAè¹fqh/‚×ãÉzílii~Ûî“Á‚"$[¶K‰Ab¶Ôq°ÿôaè”:IÅwÁö»ðø»¥g]º¡–‹3ë çö…ìÞÛσœ¿‡”¹B«*
+Ù® § w½³^T^ooÌë:cŽ4gÌ9áŒ)_Laê–0µó§Ì—â”ß—Sžæˆ¦”AJš/åiŽ"”"”"T!Z´z„‹/…7hpHŠùÂsb‹͌p¾”Œ˜ß+š‡£ŸŠpŠp7™mç×äÍ·š= úïV5 ”olÈ÷+³²ño(|¿²îM:gÃ2ouDz¶¶ö-,Ñ¡…ñZH‰,¬‘…2»ÊìÞz`!-60{%ÙBEíåŽPЖ„¨ã&U~® ¥ usr_ˆQV
+ÏÏ– e¹YêzËð£@cŠ6ÛöÕW”R”º5J™õ9Z±˜²yLËÉ)ö ÚNËñåLËi$„ŠTŠTjZŽ4Pq™$툟$mL’–3$tÂ¥ò¨¨nT°Ï$i 8j¬rûŸ¬Å­tp¶´…Ÿ­¯õp¥ßjH¨ÿ¬ØlQ¤ùe9W˜O‹eIW6-C´ù=nUuS™_e~¯ÑürbGˆe£Æ–ÈbG¡UÕ;;nuñ˜
+ +±Ç:š6‹õósS îXŒ%WrÚÁ»/À|^OòMÔÁ>€êàƒ®´EàKì(ÙQJԇ8<rZW‚„Ðt¡Ž@éLK‘€3 j ò -|L€Mێ @Wʘ´OŒ @µPD·7&à
+½üÌ¿¢y¯zÏ[u„.ÙµŸ—ìÈXetfUœÅø$¨œæ»NÁ«®X/Òª@ëÄÔ+‰ÈYý­ô™ÑðYÇ~ZyÜQýaGŠÀŠÀ·]Bqdµóz»¾ûКœö¡’6¢;ÑY[Ѫ³¥/w/Z“Ó^´ΖvØVí»£¥}¶Sûž,ýy½Â‰Ú…–×.´ê\iAÛÐæoC´ÁÉã]þ†þÏ´|¼û.m~’
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/archhigh.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/supertree.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/supertree.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/supertree.dia (revision 1676)
@@ -0,0 +1,14 @@
+‹í\Ks£8¾çWPäʈÇd’©™­ÝÓVías؛K¶›Œ\BŽ“ËþöÄC"q"W…¸ÝD_·Z_¿=¬bힰ4¢ÉµL[ÿvsñuá/âoÁðJIš]ëKÎ×_,k»ÝšñcŠ9efm̔Xÿá8Ɩ²ô› MÛW0Çg×Ê«˜sM7œh ^‘k}Šg¿Œn’¹^H•r3S¦ÝãøZ¿¼Ë?ºUª±*z^нÆkÂêjWkšFB„?®DZôdÇ=™R*BÉâæò»{YÜRya§«éF[ðf‹(9´ÃŽ‹Ž€fŸzátSÙbÙ˜lQ:YSÆŽø¡‘)¥1ÁIa‡³ +én'áX¸ÊK +ݵßEœÓ#÷‡ãô5 +(.?£¦Å¥äs³1~$¬¼³;°k÷QMcRvåŠéô'™ñŸÿpœÌ1›k¿i·äë;®²u-š_ëÛU€×;ChÏ4­C|M£„—=í{.ÓÖmº§Óºj&î'‹˜”êé d…WÐ6=°8íf—g=Q³Z'¶šL›#æ”U‘«±£”Oҍ`ÉiLg¿Z¨îmsRšð&»ÙõRäwºa‘`g«%‰ËFK-X;ÝDÕ½Ž»Xy8l²²'íüÓϐ ¦E²"͇$›Õi]ÖÈm1ÜÚÁÿ|ðƒ>4ÐèMÐ@ré D†+ØÈÄ¡›=“ÕdFYr˜Á Ҟ\ÿ6šóåa›ž ôP}͚n§›îtI·“†´òx?ÅJÑï†çÑ&mo8¢ýDŸÿ+JHƒÓÃb #Óé‘ ²˜ÐðÌHºö{’LH2ÏoþõMjü¾ã-œ­ë–wz;""™O0ct[WÜȹ4Ob’,^³m}M¡‹ã No<øðdÂË¢€€EP@(;to’
+ï.4û½;„ßù~oïù½;‚ßå÷ÚïQ_¿—ìö{^ÆñzåôÈé[*_^_¯‡È%z=tMúb€[V¾éڎžKåËRµ®.µ®ªS©Z—Lð{ç{À¾D
+MGŒöEÖ'0ï]hz@œúùé0'«µbNïªc)IAïD 4€Ì¢7ô p pì‚йðÀ’®ˆâNÙ@Õ³Èäp€¶L@fàg¥Î‚  aðœXÀú‰Õ$xg*€¶¢‚© eFØC +\™¥`;›N>)Ìb˜ V°ÚªfïÍ ÆâùNRþ“ö‰AWM9Ž8å؆80@9NŒ‘ÜŠ\†9`zè
+†f‘’KÇÜA»šÓDW¡î3¡î9r'‰pR¥ô {úF[
+ðeKEÖ8Íç9µÝ· +Oâ@é@‡C@ÜâÞÄÃq î‡x¨ ® þ:ˆ;oqg€¥tô´Ùß-¥Ësgùké‚cI3P‹é>A€ÞÁóoø-(‹ª¿c×}ïàEÏà…ཀ*ð*ðî×}#ðö^Ä%W¬à^Å
+ŽV±‚Ç*VðU¬~àž„_çðÛ9šmxRÇÆb$ ²½'ÙÐ8«{Áð­5ªAÂíšs¨qñ§ìƒ‹[¦–?@j-uG +4‘ç¨\l* î:ŽáËbÓ|‡õDm±î³ÅÚS“Ëã¬3Á“Ë2_ºàçd@¹îÔÍÉÀ3Yi¢È`€Õ§ê… c±A8ÄÀ]ê+Xªt|²•gŠÆ£hAþtàUéÀWtðyè@íM‹À…©làæ{S¼§ÂŸïMñÏ¥pðç÷[à)èX2P40 +À!²Gîä@¾G +–YA¹WÕ9“¬@ð€tÍE#3DíБºgÝ ‚gÿχþø÷VÑ@碡¢±hÀ"FÈüj>œO> ÆÝó@Á©DPœç¯{¿¹¨¼þæ☻á«hb
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/supertree.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/inodebuckets.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/inodebuckets.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/inodebuckets.dia (revision 1676)
@@ -0,0 +1,18 @@
+‹í]]“¢8}ï_AÙUûä"IøÊôtOíìëVíÃVf\Àéî—ýíE>"JVtUK‰1—ÄsîÉMnàó—÷u ýðâďÂçЍї—‡Ï Ÿ|¢ÿ˘¬5Z L²wÏ£Ušn>M&ooozð‘4ŠõÀßê‰7ù—™ÐB“Ñ˃¦W° )ÉÎgIšÆþl›zZHÖÞóhFæߗq´ +£]©¢Ü<
+¢XûA‚çÑãkþ7šÕL*õœ¨{C6^\¯v½‰ŸI?6"Œz²×£2E©„
+—/¿™»K*N”uµ](ÓHº&ñÒ›vb»Ž€º ÷½p¹™ll±l~2ÝDq?m™EQà‘pg'·^;ɜ*§ú×þê§iÔqý¯$HÎiÀîô5LîNÕ(Ÿ› +ȇWöµ$»öÃOüYà]yÄâhö͛§?ÿJI¸ ñBûUû½JWeŒ4ñ<úÓ¨ò»Þ´2ú“&u†o"?Lw=aŽQÙ¬^`U=›ÕkŽéµ“px»Ú‘Ž­1¤/OÀÐ +klӗ~æ¼À[OçQ6ý•ˆÖäÕ¿ù‹tÕlÑ“6GÕ+Ï_®RvÝ=/;YEoÓ +éæl»ŒLJö†$à‡$pec8%(!ŽÊ¾ +R°KÈK[6*­”X:&mÉÁ ù‡z-˜D¼˜¤ŽÌ’J3w•Ù듕¸½Q9ÂpꅋüâÏoRëç=i¸]Ï7uˇzA¿Jé@֛&éGàÕkö¨½¢“É &,Ln &<˜p˜ðO¦¿½÷´L/˜œ±)KÔ¹pŒt…Ÿ(²€KÅ3×ÏjšuCÍf}²¤V†%4ù4H¥\mÆäëvþÝK¾{Ÿ ÆÜɉ˜—õFaÚf4;_ù=ÚÆ>Lxì4ä¹+x¿ÜDXàêc"Ÿ^k3r<ïfä|†Hà/õ×þ۔¤>·ÇZç#¤:›ß8ҁ]qî +: +(OÐÏ8Ê ã ~O°Ô`8(URöÛtˆéBg üÝm¹‚pMޕ7èç +Ž¦ÜÌpÓåuÀ¤ËŒ8±h˜ uÛz¢¯n}"Ù!g£Y-E GË¥ž´aSÇÑ;îä­yxáòÔ¤¡¡»¼&:¦%϶ýØJïIÃÿï?ÑV”!Ù%DeëÎH+?®êì/ƒý—qõˍYÎÆ%‰a1æf1ÖÃY,Ž¡+Sß©²»µuÓ¤–ž ԁ ñØÌ}-ŸOkV;›E!ÈÊ`¾.Q4¿RšC»ÊTx Í¡[ý²1́!B­ñjí–jM5îVk¬ÔúÞԚC¬üÄ,veSØ¡/ƒ3ŖO`·ƒ½îmQ×ù¨+ˆPÔðÕÊ`€á«™Àaøjë–ÕÛòÅÃ×F;ÙÃW®.‘Bž$%q*IùŽê–G c#W5ˆux±ÖPòǝ.ƒ ‘ÙYl‡N5XE`È`•Ùζ»âwÅö«f;2˜Qçål‡C±;ŸimùÚ¾gû^Û÷lFۙíd;¥íw¬í.‡¶×]Å`Únñ§Âbٙ°n™ ‡H„Åy°PåÁ¶AÉæO„Ųó`Ý2 +‘‹;²`r(1v29¶2Aé[™@¹kXò·2Aµod°}#ŒT,à
+ÈÅBÒÓ2©kËs±vi™À¼Å\,•ˆÕ3 ©D,Á‰X ‘âOá€rU*¨B¦à02ÅѤstʽ{b²2ëøiLþ6a· ²¡—;§¹À§`/>G“ð¯øŒQ˞Ù +Ã!²ö( L–Y{åǁ–=íd/{ru‰J÷¹Öt̓µgHÎÚc„y?½Á–çQ;>zÙæ›Ln%ÒóÃhá=,üXûåŸm”>Mvóõ‰ùjXSAŸÌ ȝ -¹®!ÓSÛ<¸†l‘Ù·æ^}ڜÂ7¼¯×‰òýýC +pÊ?H +La!‚™‡P~,C+OŸ*D¨·óDˆÀÓ%*{⪳'ꁂÃ( •=-Lù»{P¹¹ÇdoÙ¹µÇT;{î,Ô78vöÔó¢…ïìaLeÛÖpô%X®àØòpšÆ¾“ilV ë˜Þ’y—9ªT–ín3GGŠ&B·sŸ¹fûE*‚åšáR÷ëÀf~mSáƅév=§¢é/Z×GQÿG 4¼Æ©u_X.ûVÕòR«íŠ)ºm­ºyJ9{há1[?/~®SCÅ?Â¥¤½ždѤLOEÅB8bUݜŽ€Š¶B·][/~ŒL«vv*ì%Ûµ†´ŠÖ^‡Êžôçç+í™ZÛÇZ«Þv)nCMÕíd?KmÚ{¦úö1ÇRà. +>­õí:|cٝ9c!⌠ŽCˆ3>ˆ3r‡g¾¶)q¾}qF@GÌ!ęrÄqÎx‚ð}ˆóä… ’g‘ò\‡¤’ç«“g(ÂõdIõ®tßSìpʹæÚó¹d)4gó”D߁D#!<±k·¡–ÓÝäôþ~çÅätã†ç·¢ÑÇÓÔ3+…©Ð +D*‰&Ñ»·ùc^_*ρ}yø¶³#L`z
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/inodebuckets.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/devtype.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/devtype.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/devtype.dia (revision 1676)
@@ -0,0 +1,12 @@
+‹í\Ënã6Ýç+gÓª,êek2É Óm.¦{ƒ¶›SI4(:M¿½Ô£±%‘zKI ˆÑ4IÝsx.)ç뷗ÀWž0 ï@Óßn¾z~á{
+…W£øê~q`ìøe¹|~~Öü×2B5Ÿ´-ÿ…¾—¼Òrñp£(— +xÁ¸,+…ŒQ¼=1¤„0@÷‹-Üý³§äz‹´VVoG|B•'èß/n“×b™5³ÌµSÑö-6I„yöz,U‘´¿_ÔÉjE¼R¸¸ýݺM»”œÛuT
+ÂH÷8,ãPýt" mmü? í¶cøcбp´9Ê(Ĭ ²%ÄG0Lq=¡î8Ñú<Tªº·þˆ#5ý„~Ôdiñk¤ L‹
+”O`}øŠhÖ³ïg²+O8Â[eSyÁâ¸Â1GÚ\IVF¶?юe,þÁ`èAê)¿)ßÉËâ,húBÁÞýâ/½<ÅYã +ò›å*fU‡,7Gu/g­âÖTÀl·"ÊÇýR$[smuÍßî ]Óm˜ü½6òQ°Ùæ$o”a&PÏØcñPßÂÜç€ðþÀªzâDò¼¬UMõ¡ŠÃËs<‚¼ø²ÒN”…1´¢…(fV*ÐóC®™èv‘ñĉyâÆ<I¢£Ä“®ýóeÜñKÉ#ˆkg@H!D‹ì0˜ÕœjÊ«Zt1¿jYó7zaÚCÓè*ïÀ›µf®9[tͦs€æ~ ’ËaºÃâ”t¦èÃ%ue‘“8maý‚9àOB%þ¼ñèäN‹„¬ªñçYÕ?ȉb®#Ë!ñ¥„­3”ý¡ÅÁÝ"Àû€'Éaüeö¨'¯a;Àíû> PõÝGá)è7÷B÷ÝSöÒò1…9¸Dšïc-¸•xóî»z‹g`6×\Xƒ3Çys¬¼»X]©»Àáì.ÞÙ]8³»øèîBP(*ê ˜vÝÖ½H*E‹«Õ}»U Œâ}Šµo⥂èjqàZ%=lyfPÔµ¦ê×F÷rŠç¡'¼CJ„(æÔç!¸EUXCE¯¡ÜµG“H\¸µ ZmvƒËWCáj'«:™ªÚƒ•ISå1Å¥•f´³g¨³S5&:[Hòç5IZcMx²Ð{MOœ‰ŒÏx°Ðr™] +w|fNâibÄ ¬íÞ¥ù‡™^õël5m”s´Ë7ZîdvÉ¢$9Fãü¢ fӝ€×f™r)2»Âɲ‡Æ™CЪŒ¡>[hàô…YB+åÈñ¯‡püŽjî÷ùòêÕÊèšnºª]V Oâø=ŠŸf«?”Õ/àlô?ƒÑw‡rA`5™ÓΛÕ7Ì©½~ÿqÎfz³{XÎÐ'³û`óû¸Ã_{¸0þ†¿œ³ãÿŽ€!,?¿Ýx~[sìõ›é7,Í´ŒÏhú}²Ç;NËÔüÏ®×_ŒÁÙömûeÒò'‘HZŒü¯ƒê…¥œÈ]œØÈ:ßHQÄ¿HL °ãýƒôyŠµÝ +oGÂpƒB/é{㉟æÓ»uGÊîXD>7Ü­Q>¤ +¤”<f§–7>
+÷¹ ¤ ü®ô…(æ8]âÛÌcˆGyThìü‰r༈yÃiÀHr‚¥œ?-$S²ï‚ì» ÿÝÒ\—:$ ræš}™ËÅxLê‚3wÉ¸›“øa™™¼×E^·y͑É+sôV_ò®UàŽH^ÞüJ³Œ•?¹¸v9kÜä²dÁ˜73ïÍ­{θc-4¤–½íî‡À®72ëmq&Ø}«ß°Ê‡U ‘9odÍÛÉlyA>õVۇ%C.þ­ý0+¸ÝWb+jŒ¨®–>³|¶ß«ñ—ð ÄVó~Uk8®áãšh§7q)˜ºèŒƒÎdtê8è̼6š#sPæ…W½9hª†>ê&”cÄÆ(}r'³æÊàˆ…G×?ª!I€”[âãQ~A
+Ž˜üz•Œm ±v +LàÓëä?á<ÜäþUÎÃÍ•e£ÔƒK
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/devtype.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/images/archlow2.dia
===================================================================
--- branches/new_sharkdoc/vol6/images/archlow2.dia (nonexistent)
+++ branches/new_sharkdoc/vol6/images/archlow2.dia (revision 1676)
@@ -0,0 +1,19 @@
+‹í\]s£6}ϯ`È+ÅH|zw“¦Ýétf;m'ۇ>yd[±i0ò9N^ö·W`l6D“Fž 3€r/’ï=çê ùÓçÇU¤=`š„$¾Òi韯/>ÍCôÿ-(Zi¼Aœ¤gWú’±õ‡Ñh»ÝšÑS‚¡fn̏¾£(B#Þh¤__hÚ¾9b(½–_EŒÑpºaX‹Ñ
+_éS4»_P²‰çú®UÞnF"Bµ]é—wÙGåfFvŽØ^£5¦e³«5IBބ=­+Mjì¤Ç½6y«„7Šח?:—»GÊ/¶DZ넭]„qÕÅ(Ú +4ø<
+ç;˜ÊvÉv@e;“ÉšPFQȪN¦„DÅ;?Œnp{?É E<TŽu´·~2FN<ÿŠ’&Ø]~ÉšÚ Ü]*¥|æ6BO˜æOvS$»ö&á4ÂùPîe1™þƒg,ÏÏ[†â9¢síí†<êTYºίôß­Ãü.7Æ¿Ò¤œákÆ,Ã.Æ¡nêLO§e˔?;ŠοFsì>Úд\Ãç‡vîp„W“¡q¯úèMf~Îٲڣ瘴­¶—8\,Y½q§ídI¶‰œNZ1ŒŠl“_à ‚t +Jà@fTz&p +‹>ß \Ãá‡vþf$Ž'8žgß¼KÂû-C Þ¬fë²çÂn˸bˆ² ¢”l˦1wؗíI„ãűœ³Ì »“yÝÚÿÞ% +ыeyT¸èkxÒ\à‰Æ¡ )+îhK)í]c„c…§kÅ]ÁxUŒÖ@TŠëƒÇ9Há©*¸ŠZú±÷“øÜÂ¥‚]bô‚)ŸvFª %Uï€TÏõ*&Ö¾û&ä×J¨TH¶Z w¨Zk©¶C…\æÑû +?2AøÚ½„¯o¸ƒ„¯8åB`»ã,„í±áîNÛ{gé¸T|—绕VµìAË”ÊÄ÷%/áùLF›‡É}Íøh?êg0$fbß靼ÑOdCCž³£®ÞIsjBÖÎQ9üš„`;O™z"öµ/¬XÙ§»;>›]Ä+\÷¥ «“¾„Sϳdwe{!J§¤„'_h H“Š%_1Kº}Äî$i›Ðs^8X¦o{o‘#¿’…¢Èž)R1ä+gH¯”CP$(8ȑ@‘ä+&I¿—ð‚%Á!MÂ7K“7™Ýksüΰ¢É~h(ž|å<ô¢Y9°äÏ%SŽ4ÆŋL‡]»õNQ¥\ª÷Á€üv2®äSIΎ^*»¦\ @vú–¸òÏ +Þ`mM¢pö¤¸²'Õµ‚Š,û&Ës—Pt^ØølNæ
+']Cáfk(Üt +Åx€5]Þ«5j +Å{[CìžQœ RzùR1Ê+
+ Qþ „
+¡B½„²r„rÊ
+ `çåÑr
+ø/ý
+žÂ¨@a”¨÷‡QP2F‰EP`w…¨qÛtm„PA*|ÅB`KÞÂѺ;M¶p¨¶p4R6Óƒþ¤nâ°²u¤Ï‚&gëH+‚æ9~K2e3)³¹y cþúóíö¯›Û¿o¿}ù­VÇ<&T5Ô0)˜çúª—ǵËs]TuËÖƉH±l¤Wžë¨N«<®TÖkñb•Ræž.·s) +äL7t¥xÓéŽ.#›õË®¦AùíàPõ´ª§ß[=]V%J–‘4ƒÃÿµ*ƽîÛ©'{?5p÷Ö!ÒwT·íо¥þŸ¶Tû}Ôã¶ô‚o7È+Áý^‰xŠ~ý¾wúí]ϪS‚ÎHåJE*‚\5H]½Å@‰­D‚Ã`R"TÕpÜÇ/¿ø2sšž¤¥I–ÿl‡—¸þÁ€_¢ +Öø`az‡ŽlPˆp|cÀ~ˆ)Dh†»óìçÌ®/~ïìúâ_×ÕåÿHQ
\ No newline at end of file
/branches/new_sharkdoc/vol6/images/archlow2.dia
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol6/makefile
===================================================================
--- branches/new_sharkdoc/vol6/makefile (nonexistent)
+++ branches/new_sharkdoc/vol6/makefile (revision 1676)
@@ -0,0 +1,4 @@
+MAIN = vol6
+MAIN_NAME = vol6
+
+include ../common/manual.mk
/branches/new_sharkdoc/vol6/makefile
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol-oldcontent/over.eps
===================================================================
--- branches/new_sharkdoc/vol-oldcontent/over.eps (nonexistent)
+++ branches/new_sharkdoc/vol-oldcontent/over.eps (revision 1676)
@@ -0,0 +1,217 @@
+%!PS-Adobe-2.0 EPSF-2.0
+%%Title: over.fig
+%%Creator: fig2dev Version 3.2 Patchlevel 1
+%%CreationDate: Wed Jul 12 11:38:50 2000
+%%For: pj@galadriel (Paolo Gai)
+%%Orientation: Portrait
+%%BoundingBox: 0 0 248 135
+%%Pages: 0
+%%BeginSetup
+%%EndSetup
+%%Magnification: 1.0000
+%%EndComments
+/$F2psDict 200 dict def
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/col-1 {0 setgray} bind def
+/col0 {0.000 0.000 0.000 srgb} bind def
+/col1 {0.000 0.000 1.000 srgb} bind def
+/col2 {0.000 1.000 0.000 srgb} bind def
+/col3 {0.000 1.000 1.000 srgb} bind def
+/col4 {1.000 0.000 0.000 srgb} bind def
+/col5 {1.000 0.000 1.000 srgb} bind def
+/col6 {1.000 1.000 0.000 srgb} bind def
+/col7 {1.000 1.000 1.000 srgb} bind def
+/col8 {0.000 0.000 0.560 srgb} bind def
+/col9 {0.000 0.000 0.690 srgb} bind def
+/col10 {0.000 0.000 0.820 srgb} bind def
+/col11 {0.530 0.810 1.000 srgb} bind def
+/col12 {0.000 0.560 0.000 srgb} bind def
+/col13 {0.000 0.690 0.000 srgb} bind def
+/col14 {0.000 0.820 0.000 srgb} bind def
+/col15 {0.000 0.560 0.560 srgb} bind def
+/col16 {0.000 0.690 0.690 srgb} bind def
+/col17 {0.000 0.820 0.820 srgb} bind def
+/col18 {0.560 0.000 0.000 srgb} bind def
+/col19 {0.690 0.000 0.000 srgb} bind def
+/col20 {0.820 0.000 0.000 srgb} bind def
+/col21 {0.560 0.000 0.560 srgb} bind def
+/col22 {0.690 0.000 0.690 srgb} bind def
+/col23 {0.820 0.000 0.820 srgb} bind def
+/col24 {0.500 0.190 0.000 srgb} bind def
+/col25 {0.630 0.250 0.000 srgb} bind def
+/col26 {0.750 0.380 0.000 srgb} bind def
+/col27 {1.000 0.500 0.500 srgb} bind def
+/col28 {1.000 0.630 0.630 srgb} bind def
+/col29 {1.000 0.750 0.750 srgb} bind def
+/col30 {1.000 0.880 0.880 srgb} bind def
+/col31 {1.000 0.840 0.000 srgb} bind def
+
+end
+save
+-23.0 148.0 translate
+1 -1 scale
+
+/cp {closepath} bind def
+/ef {eofill} bind def
+/gr {grestore} bind def
+/gs {gsave} bind def
+/sa {save} bind def
+/rs {restore} bind def
+/l {lineto} bind def
+/m {moveto} bind def
+/rm {rmoveto} bind def
+/n {newpath} bind def
+/s {stroke} bind def
+/sh {show} bind def
+/slc {setlinecap} bind def
+/slj {setlinejoin} bind def
+/slw {setlinewidth} bind def
+/srgb {setrgbcolor} bind def
+/rot {rotate} bind def
+/sc {scale} bind def
+/sd {setdash} bind def
+/ff {findfont} bind def
+/sf {setfont} bind def
+/scf {scalefont} bind def
+/sw {stringwidth} bind def
+/tr {translate} bind def
+/tnt {dup dup currentrgbcolor
+ 4 -2 roll dup 1 exch sub 3 -1 roll mul add
+ 4 -2 roll dup 1 exch sub 3 -1 roll mul add
+ 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
+ bind def
+/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+ 4 -2 roll mul srgb} bind def
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+%%EndProlog
+
+$F2psBegin
+10 setmiterlimit
+n -1000 1164 m -1000 -1000 l 1301 -1000 l 1301 1164 l cp clip
+ 0.90000 0.90000 sc
+% Polyline
+0.500 slw
+n 44 143 m 44 149 l gs col-1 s gr
+% Polyline
+n 59 143 m 59 149 l gs col-1 s gr
+% Polyline
+n 74 143 m 74 149 l gs col-1 s gr
+% Polyline
+n 89 143 m 89 149 l gs col-1 s gr
+% Polyline
+n 104 143 m 104 149 l gs col-1 s gr
+% Polyline
+n 119 143 m 119 149 l gs col-1 s gr
+% Polyline
+n 134 143 m 134 149 l gs col-1 s gr
+% Polyline
+n 149 143 m 149 149 l gs col-1 s gr
+% Polyline
+n 164 143 m 164 149 l gs col-1 s gr
+% Polyline
+n 179 143 m 179 149 l gs col-1 s gr
+% Polyline
+n 194 143 m 194 149 l gs col-1 s gr
+% Polyline
+n 209 143 m 209 149 l gs col-1 s gr
+% Polyline
+n 224 143 m 224 149 l gs col-1 s gr
+% Polyline
+n 239 143 m 239 149 l gs col-1 s gr
+% Polyline
+n 254 143 m 254 149 l gs col-1 s gr
+% Polyline
+n 269 143 m 269 149 l gs col-1 s gr
+% Polyline
+n 284 143 m 284 149 l gs col-1 s gr
+% Polyline
+n 44 68 m 44 74 l gs col-1 s gr
+% Polyline
+n 59 68 m 59 74 l gs col-1 s gr
+% Polyline
+n 74 68 m 74 74 l gs col-1 s gr
+% Polyline
+n 89 68 m 89 74 l gs col-1 s gr
+% Polyline
+n 104 68 m 104 74 l gs col-1 s gr
+% Polyline
+n 119 68 m 119 74 l gs col-1 s gr
+% Polyline
+n 134 68 m 134 74 l gs col-1 s gr
+% Polyline
+n 149 68 m 149 74 l gs col-1 s gr
+% Polyline
+n 164 68 m 164 74 l gs col-1 s gr
+% Polyline
+n 179 68 m 179 74 l gs col-1 s gr
+% Polyline
+n 194 68 m 194 74 l gs col-1 s gr
+% Polyline
+n 209 68 m 209 74 l gs col-1 s gr
+% Polyline
+n 224 68 m 224 74 l gs col-1 s gr
+% Polyline
+n 239 68 m 239 74 l gs col-1 s gr
+% Polyline
+n 269 68 m 269 74 l gs col-1 s gr
+% Polyline
+n 284 68 m 284 74 l gs col-1 s gr
+% Polyline
+n 59 149 m 59 134 l 29 134 l 29 149 l cp gs 0.60 setgray ef gr gs col-1 s gr
+% Polyline
+n 119 149 m 119 134 l 89 134 l 89 149 l cp gs 0.60 setgray ef gr gs col-1 s gr
+% Polyline
+n 179 149 m 179 134 l 149 134 l 149 149 l cp gs 0.60 setgray ef gr gs col-1 s gr
+% Polyline
+n 284 149 m 284 134 l 254 134 l 254 149 l cp gs 0.60 setgray ef gr gs col-1 s gr
+% Polyline
+n 89 74 m 89 59 l 59 59 l 59 74 l cp gs 0.80 setgray ef gr gs col-1 s gr
+% Polyline
+n 254 74 m 254 59 l 209 59 l 209 74 l cp gs 0.80 setgray ef gr gs col-1 s gr
+/Times-Roman ff 10.00 scf sf
+26 164 m
+gs 1 -1 sc (0) col0 sh gr
+/Times-Roman ff 10.00 scf sf
+86 164 m
+gs 1 -1 sc (4) col0 sh gr
+/Times-Roman ff 10.00 scf sf
+146 164 m
+gs 1 -1 sc (8) col0 sh gr
+/Times-Roman ff 10.00 scf sf
+206 164 m
+gs 1 -1 sc (12) col0 sh gr
+/Times-Roman ff 10.00 scf sf
+266 164 m
+gs 1 -1 sc (16) col0 sh gr
+% Polyline
+n 77 17 m 77 17 l 77 17 l 77 17 l cp gs 0.75 setgray ef gr gs col0 s gr
+% Polyline
+n 29 74 m 299 74 l gs col-1 s gr
+% Polyline
+n 29 119 m 29 149 l 299 149 l gs col-1 s gr
+% Polyline
+n 89 119 m 89 149 l gs col-1 s gr
+% Polyline
+n 149 119 m 149 149 l gs col-1 s gr
+% Polyline
+n 209 119 m 209 149 l gs col-1 s gr
+% Polyline
+n 269 119 m 269 149 l gs col-1 s gr
+% Polyline
+n 29 149 m 29 152 l gs col-1 s gr
+% Polyline
+n 89 149 m 89 152 l gs col-1 s gr
+% Polyline
+n 149 149 m 149 152 l gs col-1 s gr
+% Polyline
+n 209 149 m 209 152 l gs col-1 s gr
+% Polyline
+n 269 149 m 269 152 l gs col-1 s gr
+% Polyline
+n 29 44 m 29 74 l gs col-1 s gr
+% Polyline
+n 254 44 m 254 74 l gs col-1 s gr
+$F2psEnd
+rs
/branches/new_sharkdoc/vol-oldcontent/over.eps
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol-oldcontent/hartport.tex
===================================================================
--- branches/new_sharkdoc/vol-oldcontent/hartport.tex (nonexistent)
+++ branches/new_sharkdoc/vol-oldcontent/hartport.tex (revision 1676)
@@ -0,0 +1,252 @@
+%----------------------------------------------------------------------------
+\section{Communication Ports \footnote{The S.Ha.R.K. communication ports are
+directly derived from the previous varsions of the Hartik Kernel.}}
+%----------------------------------------------------------------------------
+
+S.Ha.R.K. communication ports allow tasks to exchange messages. Each
+port is uniquely identified by a symbolic name (i.e., a string of
+characters); a task willing to use this communication facility has
+to open the channel using the \texttt{port\_create()} call, thus becoming
+the owner of the resource. Any other task that wants to use this communication
+end-point to send or receive data needs to connect to it by using
+the \texttt{port\_connect()} primitive.
+
+S.Ha.R.K. offers three types of ports:
+
+\begin{itemize}
+
+\item \texttt{STREAM}: it is a one-to-one communication facility, which
+can be opened either by the reader or by the writer task. The task
+executing the \texttt{port\_create()} must specify the message size
+and maximum number of messages in the queue. The task executing the
+
+\texttt{port\_connect()} must only specify the size of the messages
+it wants to receive/send, which can be different from the one specified
+by the owner. For example, a task may open a port for reading messages
+of 4 bytes, while another task can connect to it to write one-byte
+messages. This mechanism turns out to be useful for character oriented
+device drivers which need to fill a given structure, before the message
+can be processed further by a higher-level task.
+
+\item \texttt{MAILBOX}: it is a many-to-one communication facility, thought
+for being used in classical client/server mechanisms. This kind of
+port can only be opened by the reader task (the server) which wants
+to receive data from writer tasks (the clients). Message size is fixed
+and defined by the reader.
+
+\item \texttt{STICK}: it is a one-to-many communication facility intended
+to be used for exchanging periodic state-messages, for which the most
+recent information is relevant. It can be opened only by the (unique)
+writer task and the reading tasks must connect to it. It contains
+just one message and any new message posted by the writer will overwrite
+the previous one. Messages are non-consumable: a reader task can perform
+many readings of a given message until the writer posts a new one.
+\end{itemize}
+
+The first two kinds of port implement the synchronous communication
+paradigm, while \texttt{STICK} ports implement an asynchronous (state-message)
+paradigm. It is worth noting that in order to protect the internal
+data structures, \texttt{STREAM} ports use semaphores for synchronizing
+the accesses, \texttt{STICK} ports just use a mutual exclusion semaphore,
+and the \texttt{MAILBOX} ports use both kinds of semaphores.
+
+For this reason, \texttt{MAILBOX} and \texttt{STICK} ports should
+not be used by critical tasks, whereas \texttt{STREAM} ports can be
+used by any task requiring a state-message non-blocking semantics.
+Moreover, the execution time of a transaction depends on the message
+size (the message is copied in/from the buffer when a send/receive
+is performed). The semantics associated with each port is graphically
+illustrated in Figure \ref{fg:port-type}.
+
+An application that uses the communication ports, must register the
+HARTPORT Module. Please see Volume III - S.Ha.R.K. Modules for details.
+
+\begin{figure}
+\begin{center}\includegraphics[width=8cm]{port.eps}\end{center}
+\caption{HARTIK ports.\label{fg:port-type}}
+\end{figure}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+PORT\_CREATE\index{port\_create()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{PORT port\_create(char {*}name, int dim, int num,
+int type, int mode);}]
+
+\item [\textbf{Description:}]It opens the port identified by the string
+\texttt{name}.
+The argument \texttt{dim} specifies the message size in bytes, \texttt{num}
+specifies the queue size, \texttt{type} the port type (\texttt{STREAM},
+\texttt{MAILBOX}, or \texttt{STICK}), and \texttt{mode} the access
+mode (\texttt{READ} or \texttt{WRITE}).
+
+\item [\textbf{Return Value:}] The primitive returns the port identifier,
+which identifies the connection between the port and the task, and
+not the port itself, which is identified through its name. A return
+value -1 indicates that an error is occurred.
+
+\item [\textbf{See also}:] \texttt{port\_delete(), port\_connect(),
+port\_disconnect(), port\_send(), port\_receive()}.
+
+\end{description}
+
+\begin{description}
+\item [Example:\label{pg:port-ex}]
+\item \texttt{TASK demo(void)} \{
+\item \texttt{~~PORT p; }
+\item \texttt{~~char msg{[}6{]}; }
+\item \texttt{~~\ldots{}}
+\item \texttt{~~/{*} Demo task, of NRT type, opens the \char`\"{}goofy\char`\"{}
+port {*}/}
+\item \texttt{~~/{*} and sends a message of 6 bytes. {*}/}
+\item \texttt{~~p = port\_create(\char`\"{}goofy\char`\"{}, 6, 8, STREAM,
+WRITE);}
+\item \texttt{~~\ldots{}}
+\item \texttt{~~port\_send(p, msg, BLOCK); }
+\item \texttt{\}}
+\item \texttt{~}
+\item \texttt{TASK duro(void)} \{
+\item \texttt{~~PORT q; }
+\item \texttt{~~char msg{[}2{]}; }
+\item \texttt{~~/{*} Duro task (HARD) connects to the \char`\"{}goofy\char`\"{}
+{*}/}
+\item \texttt{~~/{*} port and receives messages of 2 bytes {*}/ }
+\item \texttt{~~q = port\_connect(\char`\"{}goofy\char`\"{}, 2, STREAM,
+READ);}
+\item \texttt{~~while (condition) \{}
+\item \texttt{~~~~\ldots{}}
+\item \texttt{~~~~if (port\_receive(q, msg, NON\textbackslash{}\_BLOCK) \{}
+\item \texttt{~~~~~~<action 1>;~/{*} Ready Message! {*}/}
+\item \texttt{~~~~\}}
+\item \texttt{~~~~else \{}
+\item \texttt{~~~~~~<action 2>;~/{*} Message not Ready! {*}/}
+\item \texttt{~~~~\}}
+\item \texttt{~~~~\ldots{}}
+\item \texttt{~~~~task\_endcycle();}
+\item \texttt{~~\}}
+\item \texttt{\}}
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+PORT\_DELETE\index{port\_delete()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{void port\_delete(PORT p)};]
+
+\item [\textbf{Description:}]It destroys the port identified by \texttt{p}.
+
+\item [\textbf{See also}:] \texttt{port\_create(), port\_connect(),
+port\_disconnect(),
+port\_send(), port\_receive()}.
+
+\item [\textbf{Example:}]see the example at page \pageref{pg:port-ex}.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+PORT\_CONNECT\index{port\_connect()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{PORT port\_connect(char {*}name, int dim, int type,
+int mode);}]
+
+\item [\textbf{Description:}]It connects the calling task to the port identified
+by \texttt{name}. The argument \texttt{dim} specifies the message
+size in bytes, \texttt{type} the port type (\texttt{STREAM}, \texttt{MAILBOX},
+or \texttt{STICK}), and \texttt{mode} the access mode (\texttt{READ}
+or \texttt{WRITE}). If the port has not been opened by \texttt{port\_create()},
+the task is blocked, waiting for port creation. To avoid synchronization
+delays, connection should be established only \underbar{after} opening
+the port.
+
+\item [\textbf{Return value:}] The function returns the port identification
+number in the case of successful operation; else -1 is returned.
+
+\item [\textbf{See also}:] \texttt{port\_create(), port\_delete(),
+port\_disconnect(), port\_send(), port\_receive()}.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+PORT\_DISCONNECT\index{port\_disconnect()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{void port\_disconnect(PORT p)};]
+
+\item [\textbf{Description:}]It closes the connection identified by \texttt{p}.
+
+\item [\textbf{See also}:] \texttt{port\_create(), port\_connect(),
+port\_delete(), port\_send(), port\_receive()}.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+PORT\_SEND\index{port\_send()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int port\_send(PORT p, char {*}msg, BYTE b);}]
+
+\item [\textbf{Description:}]It sends a message pointed by \texttt{msg} to the
+port identified by \texttt{p}. Message dimension is defined through
+\texttt{port\_create()}
+or \texttt{port\_connect()} and cannot be dynamically changed. The
+argument \texttt{b} can be \texttt{BLOCK} or \texttt{NON\_BLOCK}.
+If \texttt{b = BLOCK} and the port queue is full, then the task is
+blocked until the buffer is freed. If \texttt{b = NON\_BLOCK} and
+the port queue is full, then the primitive returns 0 and the message
+is not sent.
+
+\item [\textbf{Return value:}] 1 (TRUE) if the operation can be performed,
+0 otherwise.
+
+\item [\textbf{See also}:] \texttt{port\_create(), port\_connect(),
+port\_disconnect(),
+port\_send(), port\_receive()}.
+
+\item [\textbf{Example:}]see the example at page \pageref{pg:port-ex}.
+
+\end{description}
+
+%----------------------------------------------------------------------------
+\begin{intest}
+PORT\_RECEIVE\index{port\_receive()}
+\end{intest}
+
+\begin{description}
+
+\item [\textbf{int port\_receive(PORT p, char {*}msg, BYTE b);}]
+
+\item [\textbf{Description:}]It receives a message from the port identified by
+\texttt{p} and copies it in a memory buffer pointed by \texttt{msg}. Message
+dimension is defined through \texttt{port\_create()} or \texttt{port\_connect()}
+and cannot be dynamically changed. The argument \texttt{b} can be
+\texttt{BLOCK} or \texttt{NON\_BLOCK}. If \texttt{b = BLOCK} and the
+port queue is empty, then the task is blocked until a message is available.
+If \texttt{b = NON\_BLOCK} and the port queue is empty, then the primitive
+returns 0 and no message is received.
+
+\item [\textbf{Return value:}] 1 (TRUE) if the operation can be performed,
+0 otherwise.
+
+\item [\textbf{See also}:] \texttt{port\_create(), port\_connect(),
+port\_disconnect(), port\_send(), port\_receive()}.
+
+\item [\textbf{Example:}]see the example at page \pageref{pg:port-ex}.
+
+\end{description}
/branches/new_sharkdoc/vol-oldcontent/hartport.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol-oldcontent/vol-oldcontent.tex
===================================================================
--- branches/new_sharkdoc/vol-oldcontent/vol-oldcontent.tex (nonexistent)
+++ branches/new_sharkdoc/vol-oldcontent/vol-oldcontent.tex (revision 1676)
@@ -0,0 +1,90 @@
+\documentclass[italian,english]{report}
+\usepackage[T1]{fontenc}
+\usepackage[latin1]{inputenc}
+\usepackage{geometry}
+\geometry{verbose,a4paper}
+\usepackage{array}
+\usepackage{longtable}
+\usepackage{makeidx}
+\makeindex
+\usepackage{graphicx}
+
+\makeatletter
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
+%% Bold symbol macro for standard LaTeX users
+\newcommand{\boldsymbol}[1]{\mbox{\boldmath $#1$}}
+
+%% Special footnote code from the package 'stblftnt.sty'
+%% Author: Robin Fairbairns -- Last revised Dec 13 1996
+\let\SF@@footnote\footnote
+\def\footnote{\ifx\protect\@typeset@protect
+ \expandafter\SF@@footnote
+ \else
+ \expandafter\SF@gobble@opt
+ \fi
+}
+\expandafter\def\csname SF@gobble@opt \endcsname{\@ifnextchar[%]
+ \SF@gobble@twobracket
+ \@gobble
+}
+\edef\SF@gobble@opt{\noexpand\protect
+ \expandafter\noexpand\csname SF@gobble@opt \endcsname}
+\def\SF@gobble@twobracket[#1]#2{}
+%% Because html converters don't know tabularnewline
+\providecommand{\tabularnewline}{\\}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
+\newenvironment{intest}{\noindent\large\bf\hspace*{1pt}}
+{\vspace*{-5pt}\\\hspace*{6pt}\line(1,0){433}}
+
+\newenvironment{lyxlist}[1]
+ {\begin{list}{}
+ {\settowidth{\labelwidth}{#1}
+ \setlength{\leftmargin}{\labelwidth}
+ \addtolength{\leftmargin}{\labelsep}
+ \renewcommand{\makelabel}[1]{##1\hfil}}}
+ {\end{list}}
+
+\usepackage{babel}
+\makeatother
+
+\begin{document}
+\thispagestyle{empty}
+
+\begin{center}{\LARGE S.Ha.R.K. Manual}\end{center}{\LARGE \par}
+\vfill{}
+\begin{center}Old Content Volume\end{center}
+\begin{center}Unsupported Kernel Features\end{center}
+\vfill{}
+\begin{center}Written by\end{center}
+\begin{center}Giorgio Buttazzo (giorgio@sssup.it)\end{center}
+\begin{center}Paolo Gai (pj@sssup.it)\end{center}
+\begin{center}Luigi Palopoli (luigi@hartik.sssup.it)\end{center}
+\begin{center}Marco Caccamo (caccamo@sssup.it)\end{center}
+\begin{center}Giuseppe Lipari (lipari@sssup.it) \end{center}
+\vfill{}
+\begin{center}Restyled by\end{center}
+\begin{center}Tullio Facchinetti (tullio.facchinetti@unipv.it)\end{center}
+\vfill{}
+
+\begin{center}\includegraphics[width=2cm]{../common/sssup.ps}\end{center}
+
+\begin{center}Scuola Superiore di Studi e Perfezionamento S. Anna\end{center}
+\begin{center}RETIS Lab\end{center}
+\begin{center}Via Carducci, 40 - 56100 Pisa\end{center}
+\begin{center}\pagebreak\end{center}
+
+\tableofcontents{}
+
+\include{introd}
+\include{hartport}
+
+\appendix
+
+\printindex{}
+
+\bibliographystyle{alpha}
+\bibliography{../common/biblio}
+
+\end{document}
/branches/new_sharkdoc/vol-oldcontent/vol-oldcontent.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol-oldcontent/port.eps
===================================================================
--- branches/new_sharkdoc/vol-oldcontent/port.eps (nonexistent)
+++ branches/new_sharkdoc/vol-oldcontent/port.eps (revision 1676)
@@ -0,0 +1,235 @@
+%!PS-Adobe-2.0 EPSF-2.0
+%%Title: port.fig
+%%Creator: fig2dev Version 3.2 Patchlevel 1
+%%CreationDate: Wed Jul 12 11:38:50 2000
+%%For: pj@galadriel (Paolo Gai)
+%%Orientation: Portrait
+%%BoundingBox: 0 0 314 197
+%%Pages: 0
+%%BeginSetup
+%%EndSetup
+%%Magnification: 1.0000
+%%EndComments
+/$F2psDict 200 dict def
+$F2psDict begin
+$F2psDict /mtrx matrix put
+/col-1 {0 setgray} bind def
+/col0 {0.000 0.000 0.000 srgb} bind def
+/col1 {0.000 0.000 1.000 srgb} bind def
+/col2 {0.000 1.000 0.000 srgb} bind def
+/col3 {0.000 1.000 1.000 srgb} bind def
+/col4 {1.000 0.000 0.000 srgb} bind def
+/col5 {1.000 0.000 1.000 srgb} bind def
+/col6 {1.000 1.000 0.000 srgb} bind def
+/col7 {1.000 1.000 1.000 srgb} bind def
+/col8 {0.000 0.000 0.560 srgb} bind def
+/col9 {0.000 0.000 0.690 srgb} bind def
+/col10 {0.000 0.000 0.820 srgb} bind def
+/col11 {0.530 0.810 1.000 srgb} bind def
+/col12 {0.000 0.560 0.000 srgb} bind def
+/col13 {0.000 0.690 0.000 srgb} bind def
+/col14 {0.000 0.820 0.000 srgb} bind def
+/col15 {0.000 0.560 0.560 srgb} bind def
+/col16 {0.000 0.690 0.690 srgb} bind def
+/col17 {0.000 0.820 0.820 srgb} bind def
+/col18 {0.560 0.000 0.000 srgb} bind def
+/col19 {0.690 0.000 0.000 srgb} bind def
+/col20 {0.820 0.000 0.000 srgb} bind def
+/col21 {0.560 0.000 0.560 srgb} bind def
+/col22 {0.690 0.000 0.690 srgb} bind def
+/col23 {0.820 0.000 0.820 srgb} bind def
+/col24 {0.500 0.190 0.000 srgb} bind def
+/col25 {0.630 0.250 0.000 srgb} bind def
+/col26 {0.750 0.380 0.000 srgb} bind def
+/col27 {1.000 0.500 0.500 srgb} bind def
+/col28 {1.000 0.630 0.630 srgb} bind def
+/col29 {1.000 0.750 0.750 srgb} bind def
+/col30 {1.000 0.880 0.880 srgb} bind def
+/col31 {1.000 0.840 0.000 srgb} bind def
+
+end
+save
+-108.0 304.0 translate
+1 -1 scale
+
+/cp {closepath} bind def
+/ef {eofill} bind def
+/gr {grestore} bind def
+/gs {gsave} bind def
+/sa {save} bind def
+/rs {restore} bind def
+/l {lineto} bind def
+/m {moveto} bind def
+/rm {rmoveto} bind def
+/n {newpath} bind def
+/s {stroke} bind def
+/sh {show} bind def
+/slc {setlinecap} bind def
+/slj {setlinejoin} bind def
+/slw {setlinewidth} bind def
+/srgb {setrgbcolor} bind def
+/rot {rotate} bind def
+/sc {scale} bind def
+/sd {setdash} bind def
+/ff {findfont} bind def
+/sf {setfont} bind def
+/scf {scalefont} bind def
+/sw {stringwidth} bind def
+/tr {translate} bind def
+/tnt {dup dup currentrgbcolor
+ 4 -2 roll dup 1 exch sub 3 -1 roll mul add
+ 4 -2 roll dup 1 exch sub 3 -1 roll mul add
+ 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
+ bind def
+/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
+ 4 -2 roll mul srgb} bind def
+/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
+/$F2psEnd {$F2psEnteredState restore end} def
+%%EndProlog
+
+$F2psBegin
+10 setmiterlimit
+n -1000 6052 m -1000 -1000 l 8026 -1000 l 8026 6052 l cp clip
+ 0.06000 0.06000 sc
+/Times-Roman ff 180.00 scf sf
+1800 3450 m
+gs 1 -1 sc (Clients) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+6150 3375 m
+gs 1 -1 sc (Server) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+6150 3600 m
+gs 1 -1 sc (\(Owner\)) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+1800 4725 m
+gs 1 -1 sc (Producers) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+1800 4950 m
+gs 1 -1 sc (\(Owner\)) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+6150 4725 m
+gs 1 -1 sc (Consumers) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+2100 2325 m
+gs 1 -1 sc (Writer) col0 sh gr
+/Times-Roman ff 180.00 scf sf
+5850 2325 m
+gs 1 -1 sc (Reader) col0 sh gr
+% Polyline
+7.500 slw
+n 3375 3240 m 4950 3240 l 4950 3690 l 3375 3690 l gs col-1 s gr
+% Polyline
+n 4500 3240 m 4500 3690 l gs col-1 s gr
+% Polyline
+n 4275 3240 m 4275 3690 l gs col-1 s gr
+% Polyline
+n 4050 3240 m 4050 3690 l gs col-1 s gr
+% Polyline
+n 3825 3240 m 3825 3690 l gs col-1 s gr
+% Polyline
+n 4725 3240 m 4725 3690 l gs col-1 s gr
+% Polyline
+gs clippath
+5505 3435 m 5625 3465 l 5505 3495 l 5640 3495 l 5640 3435 l cp
+clip
+n 4950 3465 m 5625 3465 l gs col-1 s gr gr
+
+% arrowhead
+n 5505 3435 m 5625 3465 l 5505 3495 l col-1 s
+% Polyline
+gs clippath
+3255 3435 m 3375 3465 l 3255 3495 l 3390 3495 l 3390 3435 l cp
+clip
+n 2700 3465 m 3375 3465 l gs col-1 s gr gr
+
+% arrowhead
+n 3255 3435 m 3375 3465 l 3255 3495 l col-1 s
+% Polyline
+gs clippath
+3263 3322 m 3375 3375 l 3251 3381 l 3384 3407 l 3396 3349 l cp
+clip
+n 2700 3240 m 3375 3375 l gs col-1 s gr gr
+
+% arrowhead
+n 3263 3322 m 3375 3375 l 3251 3381 l col-1 s
+% Polyline
+gs clippath
+3251 3549 m 3375 3555 l 3263 3608 l 3396 3581 l 3384 3523 l cp
+clip
+n 2700 3690 m 3375 3555 l gs col-1 s gr gr
+
+% arrowhead
+n 3251 3549 m 3375 3555 l 3263 3608 l col-1 s
+/Times-Roman ff 150.00 scf sf
+3825 3060 m
+gs 1 -1 sc (MAILBOX) col-1 sh gr
+% Polyline
+n 4635 5040 m 4635 4410 l 3735 4410 l 3735 5040 l cp gs col-1 s gr
+% Polyline
+gs clippath
+3615 4695 m 3735 4725 l 3615 4755 l 3750 4755 l 3750 4695 l cp
+clip
+n 3060 4725 m 3735 4725 l gs col-1 s gr gr
+
+% arrowhead
+n 3615 4695 m 3735 4725 l 3615 4755 l col-1 s
+% Polyline
+gs clippath
+5190 4695 m 5310 4725 l 5190 4755 l 5325 4755 l 5325 4695 l cp
+clip
+n 4635 4725 m 5310 4725 l gs col-1 s gr gr
+
+% arrowhead
+n 5190 4695 m 5310 4725 l 5190 4755 l col-1 s
+% Polyline
+gs clippath
+5186 4494 m 5310 4500 l 5198 4553 l 5331 4526 l 5319 4468 l cp
+clip
+n 4635 4635 m 5310 4500 l gs col-1 s gr gr
+
+% arrowhead
+n 5186 4494 m 5310 4500 l 5198 4553 l col-1 s
+% Polyline
+gs clippath
+5198 4897 m 5310 4950 l 5186 4956 l 5319 4982 l 5331 4924 l cp
+clip
+n 4635 4815 m 5310 4950 l gs col-1 s gr gr
+
+% arrowhead
+n 5198 4897 m 5310 4950 l 5186 4956 l col-1 s
+/Times-Roman ff 150.00 scf sf
+4005 4230 m
+gs 1 -1 sc (STICK) col-1 sh gr
+% Polyline
+n 3375 2025 m 4950 2025 l 4950 2475 l 3375 2475 l gs col-1 s gr
+% Polyline
+n 4500 2025 m 4500 2475 l gs col-1 s gr
+% Polyline
+n 4275 2025 m 4275 2475 l gs col-1 s gr
+% Polyline
+n 4050 2025 m 4050 2475 l gs col-1 s gr
+% Polyline
+n 3825 2025 m 3825 2475 l gs col-1 s gr
+% Polyline
+n 4725 2025 m 4725 2475 l gs col-1 s gr
+% Polyline
+gs clippath
+5505 2220 m 5625 2250 l 5505 2280 l 5640 2280 l 5640 2220 l cp
+clip
+n 4950 2250 m 5625 2250 l gs col-1 s gr gr
+
+% arrowhead
+n 5505 2220 m 5625 2250 l 5505 2280 l col-1 s
+% Polyline
+gs clippath
+3255 2220 m 3375 2250 l 3255 2280 l 3390 2280 l 3390 2220 l cp
+clip
+n 2700 2250 m 3375 2250 l gs col-1 s gr gr
+
+% arrowhead
+n 3255 2220 m 3375 2250 l 3255 2280 l col-1 s
+/Times-Roman ff 150.00 scf sf
+3870 1890 m
+gs 1 -1 sc (STREAM) col-1 sh gr
+$F2psEnd
+rs
/branches/new_sharkdoc/vol-oldcontent/port.eps
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol-oldcontent/makefile
===================================================================
--- branches/new_sharkdoc/vol-oldcontent/makefile (nonexistent)
+++ branches/new_sharkdoc/vol-oldcontent/makefile (revision 1676)
@@ -0,0 +1,4 @@
+MAIN = vol-oldcontent
+MAIN_NAME = vol-oldcontent
+
+include ../common/manual.mk
/branches/new_sharkdoc/vol-oldcontent/makefile
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/vol-oldcontent/introd.tex
===================================================================
--- branches/new_sharkdoc/vol-oldcontent/introd.tex (nonexistent)
+++ branches/new_sharkdoc/vol-oldcontent/introd.tex (revision 1676)
@@ -0,0 +1,5 @@
+%----------------------------------------------------------------------------
+\chapter{Introduction}
+%----------------------------------------------------------------------------
+
+This Manual collects the documentation about old S.Ha.R.K. \cite{Gai01} features no more supported or developed. Since some of them may still available in the source code repository and could be useful for some specific applications, the related documentation has been kept to help possible future usage.
/branches/new_sharkdoc/vol-oldcontent/introd.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/common/retis.bib
===================================================================
--- branches/new_sharkdoc/common/retis.bib (nonexistent)
+++ branches/new_sharkdoc/common/retis.bib (revision 1676)
@@ -0,0 +1,943 @@
+@Article{Yau97,
+ author = {David K. Y. Yau and Siman S. Lam},
+ title = {Adaptive Rate Controlled Scheduling for Multimedia Applications},
+ journal = {IEEE/ACM Transactions on Networking},
+ year = {1997},
+ month = {August}
+}
+
+@inProceedings{Chu99,
+ author = {Hao-hua Chu and Klara Nahrstedt},
+ title = {{CPU} Service Classes for Multimedia Applications},
+ booktitle = {Proceedings of the IEEE International Conference on Mutimedia Computing and Systems},
+ year = 1999,
+ month = {June},
+ address = {Florence, Italy},
+ key = {multimedia, Qos, scheduling}
+}
+
+@inProceedings{Li98,
+ author = {B. Li and K. Nahrstedt},
+ title = {A Control Theoretical Model for Quality of Service Adaptations},
+ booktitle = {Proceedings of Sixth International Workshop on Quality of Service},
+ year = 1998,
+ key = {multimedia, Qos, scheduling}
+}
+
+@TechReport{Chu98-1,
+ author = {Hao-hua Chu and Klara Nahrstedt},
+ title = {{CPU} Service Classes for Multimedia Applications},
+ institution = {University of Illinois},
+ year = {1998},
+ key = {multimedia, Qos, scheduling},
+ address = {Urbana Champaign},
+ month = {August},
+ number = {UIUCDCS-R-98-2068,UILU-ENG-98-1730}
+}
+
+@TechReport{Abe00-1,
+ author = {Luca Abeni},
+ title = {Library for Operating System development},
+ institution = {Scuola Superiore di Studi e Perfezionamento S. Anna},
+ year = {2000},
+}
+
+@Misc{Abe00-2,
+ author = {Luca Abeni and Gerardo Lamastra},
+ title = {The {OSLib} Project},
+ howpublished = {http://oslib.sssup.it},
+}
+
+@inproceedings{Jon93,
+ author = {Michael B. Jones},
+ title = {Adaptive Real-Time Resource Management Supporting Composition
+ of Indipendently Authored Time-Critical Services},
+ booktitle = {},
+ year = 1993,
+ key = {soft real-time, adaptive applicatiuons}
+}
+
+@phdthesis{Hyd94,
+ author = {E. A. Hyden},
+ title = {Operating System Support for Quality of Service},
+ school = {Computer Laboratory, University of Cambridge},
+ year = 1994,
+ month = {February},
+ key = {multimedia, QOS, operating system, scheduling}
+
+}
+
+@InProceedings{Ray98,
+ author = {Raj Rajkumar and Kanaka Juvva and Anastasio Molano and
+ Shuichi Oikawa},
+ title = {Resource Kernels: A Resource-Centric Approach to Real-Time
+ and Multimedia Systems},
+ booktitle = {Proceedings of the SPIE/ACM Conference on Multimedia Computing and Networking},
+ key = {multimedia, QoS, resource reservation},
+ year = {1998},
+ month = {January}
+}
+
+@InProceedings{Opa96,
+ author = {Don Aparah},
+ title = {Adaptive Resource Management in a Multimedia Operating
+ System},
+ booktitle = {Proceedings of the 8th International Workshop on Network
+ and Operating System Support for Digital Audio
+ and Video},
+ key = {multimedia, QoS},
+ year = {1998},
+ address = {Cambridge, UK},
+ month = {July}
+}
+
+@inproceedings{Chu97,
+ author = {Hao-Hua Chu and Klara Nahrstedt},
+ title = {A Soft Real Time Scheduling Server in UNIX Operating
+ System},
+ booktitle = {European Workshop on Interactive Distributed Multimedia Systems
+ and Telecommunication Services},
+ year = 1997,
+ month = {September},
+ address = {Darmstadt, Germany},
+ key = {scheduling, multimedia, real-time Unix}
+}
+
+@inproceedings{Com94,
+ author = {Charles L. Compton and David L. Tennenhouse},
+ title = {Collaborative Load Shedding for Media-Based Applications},
+ booktitle = {Proceedings of the International Conference on Multimedia Computing and Systems},
+ year = 1994
+}
+@inproceedings{Goy96,
+ author = {Pawan Goyal and Xingang Guo and Harrik M. Vin},
+ title = {A Hierarchical CPU Scheduler for Multimedia Operating Systems},
+ booktitle = {2nd OSDI Symposium},
+ month = {October},
+ year = 1996,
+ key = {scheduling, multimedia, real-time Unix}
+}
+
+@inproceedings{Sto96,
+ author = {Ian Stoica and Hussein Abdel-Wahab and Kevin Jeffay and Sanjoy
+ K. Baruah and Johannes E. Gehrke and C. Greg Plaxton},
+ title = {A Proportional Share Resource Allocation Algorithm for
+ Real-Time, Time-Shared Systems},
+ booktitle = {Proceedings of the IEEE Real Time Systems Symposium},
+ year = 1996,
+ month = {December},
+ key = {scheduling, multimedia, real-time Unix}
+}
+
+@inproceedings{Abe98-2,
+ author = {Luca Abeni and Giorgio Buttazzo},
+ title = {Integrating Multimedia Applications in Hard Real-Time Systems},
+ booktitle = {Proceedings of the IEEE Real Time Systems Symposium},
+ year = 1998,
+ month = {December},
+ address = {Madrid, Spain},
+ key = {scheduling, multimedia}
+}
+
+@inproceedings{Sta99,
+ author = {John A. Stankovic and Cheyang Lu and Sang H. Son},
+ title = {The Case for Feedback Control in Real-Time Scheduling},
+ booktitle = {Proceedings of the IEEE Euromicro Conference on Real-Time},
+ year = 1998,
+ month = {June},
+ address = {York, England},
+ key = {scheduling}
+}
+
+@inproceedings{Abe98-3,
+ author = {Luca Abeni and Giorgio Buttazzo},
+ title = {QoS Guarantee Using Probabilistic Dealines},
+ booktitle = {Proceedings of the IEEE Euromicro Conference on Real-Time},
+ year = 1998,
+ month = {June},
+ address = {York, England},
+ key = {scheduling}
+}
+
+@inproceedings{Abe98-4,
+ author = {Luca Abeni and Giorgio Buttazzo},
+ title = {Constant Bandwidth vs Proportional Share Resource Allocation},
+ booktitle = {Proceedings of the IEEE International Conference on Mutimedia Computing and Systems},
+ year = 1999,
+ month = {June},
+ address = {Florence, Italy},
+ key = {scheduling, multimedia}
+}
+
+@inproceedings{Wan98,
+ author = {Y.C. Wang and K.J. Lin},
+ title = {Enanching the Real-Time Capability of the Linux Kernel},
+ booktitle = {IEEE Real Time Computing Systems and Applications},
+ year = 1998,
+ month = {October},
+ address = {Hiroshima, Japan},
+}
+
+@inproceedings{Wan99,
+ author = {Y.C. Wang and K.J. Lin},
+ title = {Implementing a General real-Time Scheduling Framework in the RED-Linux Real-Time Kernel},
+ booktitle = {Proceedings of IEEE Real-Time Systems Symposium},
+ year = 1999,
+ month = {December},
+ address = {Phoenix},
+}
+
+@inproceedings{Lip98,
+ author = {Giuseppe Lipari and Giorgio Buttazzo and Luca Abeni},
+ title = {A Bandwidth Reservation Algorithm for Multi-Application Systems},
+ booktitle = {IEEE Real Time Computing Systems and Applications},
+ year = 1998,
+ month = {October},
+ address = {Hiroshima, Japan},
+}
+
+@inproceedings{Che98,
+ author = {Chen Lee and Raj Rajkumar and John Lehoczky and Dan Siewiorek},
+ title = {Pratical Solutions for QoS-Based Resource Allocation},
+ booktitle = {Proceedings of the IEEE Real Time Systems Symposium},
+ year = 1998,
+ month = {December},
+ address = {Madrid, Spain},
+ key = {scheduling, multimedia}
+}
+
+@inproceedings{But98,
+ author = {Giorgio Buttazzo and Luca Abeni and Giuseppe Lipari},
+ title = {Elastic Task Model for Adaptive Rate Control},
+ booktitle = {Proceedings of the IEEE Real Time Systems Symposium},
+ year = 1998,
+ month = {December},
+ address = {Madrid, Spain},
+ key = {scheduling, multimedia}
+}
+
+@inproceedings{Jef98,
+ author = {Kevin Jeffay and F.D. SMith and A. Moorthy and J.H. Anderson},
+ title = {Proportional Share Scheduling of Operating System Services
+ for Real-Time Applications},
+ booktitle = {IEEE Real Time System Symposium},
+ year = 1998,
+ month = {December},
+ address = {Madrid, Spain},
+ key = {scheduling, multimedia, real-time Unix}
+}
+
+@inproceedings{Den97-1,
+ author = {Z. Deng and J. W. S. Liu and J. Sun},
+ title = {A scheme for scheduling Hard Real-Time Applications in Open
+ System Environment},
+ booktitle = {Ninth Euromicro Workshop on Real-Time Systems},
+ year = {1997},
+ key = {scheduling}
+}
+
+@inproceedings{Den97-2,
+ author = {Z. Deng and J. W. S. Liu},
+ title = {Scheduling Real-Time Applications in Open Envirovment},
+ booktitle = {IEEE Real-Time Systems Symposium},
+ year = {1997},
+ month = {December},
+OPTaddress = {San Francisco},
+ key = {scheduling}
+}
+
+@inproceedings{Cou93,
+ author = {Geoff Coulson and Gordon S. Blair and Philippe Robin and
+ others},
+ title = {Extending CHORUS micro-kernel to support continuous media
+ applications},
+ booktitle = {4th International Workshop on Network and Operating System
+ Support for Digital Audio and Video},
+ year = 1993,
+ address = {Lancaster, UK},
+ key = {operating system, multimedia}
+}
+
+@inproceedings{Jef93-1,
+ author = {Kevin Jeffay and Donald L. Stone},
+ title = {Accounting for Interrupt Handling Costs in Dynamic Priority
+ Task Systems},
+ booktitle = {IEEE Real Time System Symposium},
+ year = 1993,
+ pages = {212--221},
+ key = {scheduling, DMA}
+}
+
+@inproceedings{Jef93-2,
+ author = {Kevin Jeffay and Donald L. Stone and T. Talley and F. D. Smith},
+ title = {Adaptive, Best-Effort Delivery of Digital Audio and Video
+ Across Packet Switched Networks},
+ booktitle = {Network and Operating System Support for Digital Audio and
+ Video},
+ year = 1993,
+ key = {multimedia, networking}
+}
+
+@inproceedings{Hua95,
+ author = {Tay-Yi Huang and Jane W. S. Liu},
+ title = {Predicting the Worst-Case Execution Time of Concurren
+ execution of Instructions and Cycle-Stealing DMA I/O
+ Operations},
+ booktitle = {ACM SIGPLAN Workshop on Language, Compilers and Tools for
+ Real-Time Systems},
+ address = "La Jolla, California",
+ year = 1995,
+ key = {DMA, guarantee}
+}
+
+@inproceedings{Hua96,
+ author = {Tay-Yi Huang and Jane W. S. Liu and Jen-Yao Chung},
+ title = {Allowing Cycle-Stealing Direct Memory Access I/O Concurrent
+ with Hard-Real-Time Programs},
+ booktitle = {Int. Conf. on Parallel and Distributed Systems},
+ address = {Tokyo},
+ year = 1996,
+ key = {DMA, guarantee}
+}
+
+@inproceedings{Gov91,
+ author = {Ramesh Govindan and D. P. Anderson},
+ title = {Scheduling and IPC Mechanisms for Continuous Media},
+ booktitle = {ACM Symposium on Operating Systems Principles},
+ address = {Pacific Grove},
+ year = 1991,
+ key = {multimedia, scheduling}
+}
+
+@TechReport{Str,
+ author = {Hermann Streich},
+ title = "``TaskPair-Scheduling: An Approach for Dynamic Real-Time
+ Systems''",
+ institution = {Research Division of Responsive Systems National Center for
+ Computer Science},
+ year = {},
+ key = {scheduling, dynamic real-time systems, guarantee, exception
+ handling}
+}
+
+@Unpublished{Ger,
+ author = {M. Gergeleit and H. Streich},
+ title = {TaskPair-Scheduling with Optimistic Case Execution
+ Times - An Example for an Adaptive Real-Time System},
+ institution = {Research Division of Responsive Systems National Center for
+ Computer Science},
+ key = {scheduling, dynamic real-time systems, guarantee, exception
+ handling}
+}
+
+@InProceedings{Tia95,
+ author = {T.-S. Tia and Z. Deng and M. Shankar and M. Storch and J.
+ Sun and L.-C. Wu and J. W.-S. Liu},
+ title = {Probabilistic Performance Guarantee for Real-Time Tasks
+ with Varying Computation Times},
+ booktitle = {Real-Time Technology and Applications Symposium},
+ key = {formal methods, probabilistic guarantee},
+ year = {1995},
+ address = {Chicago,Illinois},
+ month = {January},
+ pages = {164-173}
+}
+
+@InProceedings{Jan96,
+ author = {Pierre G. Jansen and Emiel Wijgerink},
+ title = {Flexible scheduling by Deadline Inheritance in Soft
+ Real-Time Kernels},
+ booktitle = {},
+ key = {resource constraints, operating system, pre announcements,
+ multimedia},
+ year = 1996
+}
+
+@InProceedings{Nak98,
+ author = {Tatsuo Nakajima},
+ title = {Resource Reservation for Adaptive QOS Mapping in Real-Time Mach},
+ year = {1998},
+ month = {April},
+ booktitle = {Sixth International Workshop on Parallel and Distributed Real-Time Systems (WPDRTS)},
+ key = {multimedia, QoS}
+}
+
+
+@InProceedings{Nak94,
+ author = {Tatsuo Nakajima and Hiroshi Tezuka},
+ title = {A Continuous Media Application supporting Dynamic QOS
+ Control on Real-Time Mach},
+ year = {1994},
+ booktitle = {ACM Multimedia},
+ key = {multimedia, QoS, application}
+}
+
+@inproceedings{Fuj95,
+ author = {Hiroshi Fujita and Tatsuo Nakajima and Hiroshi Tezuka},
+ title = {A Processor Reservation System supporting Dynamic QOS
+ control},
+ booktitle = {2nd International Workshop on Real-Time Computing Systems
+ and Applications},
+ year = {1995},
+ month = {October}
+}
+
+
+@InProceedings{Mer93-1,
+ author = {Clifford W. Mercer and Raguanathan Rajkumar and Hideyuki
+ Tokuda},
+ title = {Applying Hard Real-Time Technology to Multimedia
+ Systems},
+ booktitle = {Workshop on the Role of Real-Time in Multimedia/Interactive
+ Computing System},
+ year = {1993},
+ key = {multimedia}
+}
+
+
+@InProceedings{Diot,
+ author = {Christophe Diot and Christian Huitema and Thierry Turletti},
+ title = {Mutlimedia Applications should be Adaptive},
+ key = {multimedia}
+}
+
+@TechReport{Mer93-2,
+ author = {Clifford W. Mercer and Stefan Savage and Hideyuki Tokuda},
+ title = {Processor Capacity Reserves for Multimedia Operating
+ Systems},
+ institution = {Carnegie Mellon University},
+ year = {1993},
+ key = {multimedia, Qos, scheduling},
+ address = {Pittsburg},
+ month = {May},
+ number = {CMU-CS-93-157}
+}
+
+@Article{Sha90,
+ author = {Lui Sha and Ragunathan Rajkumar and john P. Lehoczky},
+ title = {Priority Inheritance Protocols: An Approach to Real-Time Synchronization},
+ journal = {IEEE transaction on computers},
+ key = {sinchronization},
+ volume = {39},
+ number = {9},
+ month = {september},
+ year = {1990}
+}
+
+@InProceedings{Kan96,
+ author = {Hiroyuki Kaneko and John A. Stankovic and Subhabrata Sen
+ and Krithi Ramamritham},
+ title = {Integrated Scheduling of Multimedia and Hard Real-Time
+ Tasks},
+ booktitle = {IEEE Real Time System Symposium},
+ key = {multimedia},
+ month = {December},
+ year = {1996}
+}
+
+@Article{Spu96,
+ author = {M. Spuri and G. Buttazzo},
+ title = {Scheduling Aperiodic Tasks in Dynamic Priority Systems},
+ journal = {Real-Time Systems},
+ year = {1996},
+ volume = {10},
+ number = {2}
+}
+
+@InProceedings{Bak90,
+ author = {T. P. Baker},
+ title = {A Stack-Based Allocation Policy for Realtime Processes},
+ booktitle = {IEEE Real-Time Systems Symposium},
+ year = {1990},
+ month = {december}
+}
+
+@Article{Jef92,
+ author = {K. Jeffay and D. L. Stone and F. D. Smith},
+ title = {Kernel Support for live digital audio and video},
+ journal = {Computer Communications},
+ year = {1992},
+ volume = {15},
+ number = {6}
+}
+
+@Article{Spr89,
+ author = {B. Sprunt and L. Sha and J. P. Lehoczky},
+ title = {Aperiodic scheduling for hard real-time systems},
+ journal = {The Journal of Real-Time Systems},
+ year = {1989}
+}
+
+@InProceedings{Spu94,
+ author = {M. Spuri and G. C. Buttazzo},
+ title = {Efficient Aperiodic Service Under the Earliest Deadline
+ Scheduling},
+ booktitle = {IEEE Real-Time Systems Symposium},
+ year = {1994},
+ month = {December}
+}
+
+
+@InProceedings{Jef95,
+ author = {K. Jeffay and D. Bennet},
+ title = {A Rate-Based Execution Abstraction For Multimedia
+ Computing},
+ booktitle = {Network and Operating System Support for Digital Audio
+ and Video},
+ year = {1995}
+}
+
+@Article{Gha95,
+ author = {T. M. Ghazalie and T.P. Baker},
+ title = {Aperiodic Servers In A Deadline Scheduling Environment},
+ journal = {Real-Time Systems},
+ year = {1995},
+ volume = {9}
+}
+@Article{Liu73,
+ title = {Scheduling alghorithms for multiprogramming in a hard
+ real-time environment},
+ author = {C. L. Liu and J. Layland},
+ journal = {Journal of the ACM},
+ year = {1973},
+ volume = {20},
+ number = {1}
+}
+
+@TechReport{Abe98,
+ author = {Luca Abeni},
+ title = {Server Mechanisms for Multimedia Applications},
+ institution = {Scuola Superiore S. Anna},
+ number = {RETIS TR98-01},
+ year = {1998}
+}
+
+@InProceedings{Spu95,
+ author = {Marco Spuri and Giorgio Buttazzo and Fabrizio Sensini},
+ title = {Robust Aperiodic Scheduling under Dynamic Priority
+ Systems},
+ booktitle = {IEEE Real-Time Systems Symposium},
+ year = {1995},
+ month = {December}
+}
+
+@InProceedings{But93-1,
+ author = {G. C. Buttazzo},
+ title = {HARTIK: A Real-Time Kernel for Robotics Applications},
+ booktitle = {IEEE Real-Time Systems Symposium},
+ year = {1993},
+ month = {December}
+}
+
+
+@InProceedings{But93-2,
+ author = {G. C. Buttazzo and J. Stankovic},
+ title = {RED: Robust Earliest Deadline Scheduling},
+ booktitle = {Third International Workshop on Responsive Computing
+ Systems},
+ year = {1993},
+ OPTaddress = {Austin}
+}
+
+@InProceedings{Lam97,
+ author = {G. Lamastra and G. Lipari and G. Buttazzo and A. Casile
+ and F. Conticelli},
+ title = {HARTIK 3.0: A Portable System for Developing Real-Time
+ Applications},
+ booktitle = {Proceedings of the IEEE Conference on Real-Time Computing Systems and Applications},
+ year = {1997},
+ where = {Taipei, Taiwan},
+ month = {October}
+}
+
+@inproceedings{Rau97,
+ author = {Rauganathan Rajkumar and Chen Lee and John Lehoczky and
+ Dan Siewiorek},
+ title = {A Resource Allocation Model for QoS Management},
+ booktitle = {Proceedings of the IEEE Real Time Systems Symposium},
+ mounth = {December},
+ year = 1997,
+ address = ""
+}
+
+@inproceedings{Kor95,
+ author = {Gilad Koren and Dennis Shasha},
+ title = {Skip-Over: Algorithms and Complexity for Overloaded Systems
+ that Allow Skips},
+ booktitle = {IEEE Real Time System Symposium},
+ year = 1995,
+ address = "Pisa"
+}
+
+@inproceedings{Liu87,
+ author = {J. W. S. Liu and K. J. Lin and S. Natarjan},
+ title = {Scheduling Real-Time, Periodic Jobs Using Imprecise
+ Results},
+ booktitle = {IEEE Real Time System Symposium},
+ year = 1987,
+ month = "December",
+ address = "San Jose, California"
+}
+
+@inproceedings{Bar93,
+ author = {Sanjoy K. Baruah and Aloysius K. Mok and Louis E. Rosier},
+ title = {Preemptively Scheduling Hard-Real-Time Sporadic Tasks on One
+ Processor},
+ booktitle = {},
+ year = 1993,
+ pages = "182--190"
+}
+
+@MastersThesis{Mas92,
+ author = {Henry Massalin},
+ title = {Synthesis: An Efficient Implementation of Fundamental
+ Operating System Services},
+ school = {Columbia University},
+ year = {1992}
+}
+
+@InProceedings{Sch,
+ author = {Henning Schulzrinne and James F. Kurose},
+ title = {Distribution of the Loss Period for Some Queues in
+ Continuous and Discrete Time},
+ booktitle = {}
+}
+
+@Book{Kle75,
+ author = {L. Kleinrock},
+ title = {Queuing Systems},
+ publisher = {Wiley-Interscience},
+ year = {1975},
+}
+
+@Manual{VESA,
+ title = {VESA BIOS Extensions - Core Functions - Version 2.0},
+ organization = {VESA}
+}
+
+@TechReport{Lip97,
+ author = {Giuseppe Lipari},
+ title = {Resource Constraints Among Periodic and Aperiodic Tasks},
+ institution = {RETIS Lab - Scuola Superiore di Studi Universitari e
+ Perfezionamento S. Anna},
+ number = {9702},
+ year = {1997},
+ address = {Via Carducci, 40 - 56100 Pisa},
+ month = {November}
+}
+
+@InProceedings{Tal96,
+ author = {T. Talley and Kevin Jeffay},
+ title = {A General Framework for Continuous Media Transmission
+ Control},
+ year = {1996},
+ booktitle = {21st IEEE Conference on Local Computer Network},
+ address = {Minneapolis},
+ OPTmonth = {October}
+}
+
+@InProceedings{Jef91,
+ author = {Kevin Jeffay and D. F. Stanat and C. U. Martel},
+ title = {On Non-Preemptive Scheduling of Periodic and Sporadic
+ Tasks},
+ booktitle = {IEEE Real Time System Symposium},
+ year = {1991},
+ address = {San Antonio},
+ month = {December}
+}
+
+
+@Article{ Par93,
+ Author = "A. K. Parekh and R. G. Gallager",
+ Title = "{A generalized processor sharing approach to flow control in
+ integrated services networks: the single-node case}",
+ Journal = "IEEE/ACM Transactions on Networking",
+ Volume = "1",
+ Number = "3",
+ Month = "June",
+ Year = "1993",
+ Pages = "344--357" }
+
+@Article{ Par94,
+ Author = "A. K. Parekh and R. G. Gallager",
+ Title = "{A generalized processor sharing approach to flow control in
+ intergrated services networks: the multiple node case}",
+ Journal= "IEEE/ACM Transanctions on Networking",
+ Volume = "2",
+ Month = "April",
+ Year = "1994",
+ Pages = "137--150" }
+
+@InProceedings{Wal94,
+ author = {C. A. Waldspurger and W. E. Weihl.},
+ title = {Lottery Scheduling: Flexible Proportional-Share Resource Management},
+ booktitle = {First Symposium on Operating System Design and Implementation},
+ pages = {1-12},
+ year = {1994},
+ OPTmonth = {November}
+}
+
+@TechReport{Wal95,
+ author = {Carl A. Waldspurger and William E. Weihl},
+ title = {Stride Scheduling: Deterministic Proportional-Share Resource Mangement},
+ institution = {Massachusetts Institute of Technology},
+ year = {1995},
+ number = {MIT/LCS/TM-528},
+ month = {June}
+}
+
+@InProceedings{Sto97,
+ author = {I. Stoica and H. Abdel-Wahab and K. Jeffay},
+ title = {On the Duality between Resource Reservation and Proportional Share Resource Allocation },
+ booktitle = {SPIE Multimedia Computing and Networking},
+ pages = {207-214},
+ year = {1997},
+ volume = {3020},
+ address = {San Jose, CA},
+ month = {February}
+}
+
+@InProceedings{Cas98,
+ author = {Antonino Casile and Giorgio Buttazzo and Gerardo Lamastra and Giuseppe Lipari},
+ title = {Simulation and Tracing of Hybrid Task Sets on Distributed Systems},
+ booktitle = {Real Time Computing Systems and Applications},
+ year = {1998}
+}
+
+@InProceedings{Dem89,
+ author = {A. Demers and S. Keshav and S. Shenker},
+ title = {Analysis and Simulation of a Fair Queueing Alorithm},
+ booktitle = {ACM SIGCOMM},
+ pages = {1-12},
+ year = {1989},
+ month = {September}
+}
+
+@InProceedings{Bry97,
+ author = {Bryan Ford and Godmar Back and Greg Benson and Jay Lepreau and
+ Albert Lin and Olin Shivers},
+ title = {The Flux OSKit: A Substrate for OS and Language Research},
+ booktitle = {16 ACM Symposium on Operating Systems Principles},
+ year = {1997},
+ address = {Saint-Malo, France},
+ month = {October}
+}
+
+@InProceedings{Bry96,
+ author = {Bryan Ford and Sai Susarla},
+ title = {CPU Inheritance Scheduling},
+ booktitle = {Proceedings of OSDI},
+ year = {1996},
+ month = {October}
+}
+
+@Article{Bar96,
+ author = {S.K. Baruah and N.K. Cohen and C.G. Plaxton and D.A. Varvel},
+ title = {Proportionate Progress: A Notion of Fairness in Resource
+ Allocation},
+ journal = {Algorithmica},
+ year = {1996},
+ keyword = {Scheduling, fairness},
+ volume = {6}
+}
+
+@inproceedings{Tok90,
+key = {Tokuda90},
+author = {H. Tokuda and T. Nakajima and P. Rao},
+title = {Real-Time Mach: Toward a Predictable Real-Time System},
+booktitle = {USENIX Mach Workshop},
+pages = {73-82},
+month = {October},
+year = {1990},
+}
+
+
+@MastersThesis{Abe98-1,
+ author = {Luca Abeni},
+ title = {Progetto e Realizzazione di Meccanismi di Sistema per
+Applicazioni Real-Time Multimediali},
+ school = {Universit\`a degli studi di Pisa},
+ year = {1997},
+ OPTkey = {},
+ OPTtype = {},
+ OPTaddress = {},
+ month = {Aprile},
+ OPTnote = {},
+ OPTannote = {}
+}
+
+@inproceedings{Jef91-2,
+ author = {K.Jeffay and D.L. Stone and D.Poirier},
+ title = {YARTOS: Kernel suppoprt for efficient, predictable real-time
+ systems},
+ booktitle = {IEEE Workshop on Real-Time Operating Systems and Software},
+ year = {1991},
+ month = {May},
+ key = {scheduling, multimedia, real-time, kernel }
+}
+
+@inproceedings{Daw95-1,
+ title = {Exterminate all operating system abstractions},
+ author = {Dawson R. Engler and M. Frans Kaashoek},
+ booktitle = {Proceedings of the 5th {W}orkshop on {H}ot {T}opics in
+ {O}perating {S}ystems ({HotOS-V})},
+ organization = {{IEEE} {C}omputer {S}ociety},
+ year = {1995},
+ month = {May},
+ address = {Orcas Island, Washington},
+ pages = {78--83}
+}
+
+@inproceedings{Daw95-2,
+ title = {{E}xokernel: an operating system architecture for application-level
+ resource management},
+ author = {Dawson R. Engler and M. Frans Kaashoek and James {O'Toole Jr.}},
+ booktitle = {Proceedings of the 15th {ACM} {S}ymposium on {O}perating
+ {S}ystems {P}rinciples ({SOSP} '95)},
+ year = {1995},
+ month = {December},
+ address = {Copper Mountain Resort, Colorado},
+ pages = {251--266}
+}
+
+@inproceedings{Lie95-1,
+ title = {On $\mu$-Kernel Construction},
+ author = {Jochen Liedtke},
+ booktitle = {Proceedings of the 15th {ACM} {S}ymposium on {O}perating
+ {S}ystems {P}rinciples ({SOSP} '95)},
+ year = {1995},
+ month = {December},
+ address = {Copper Mountain Resort, Colorado},
+}
+
+@inproceedings{Lie95-2,
+ title = {Achieved IPC Performance (Still The Foundation For
+ Extensibility)},
+ author = {J. Liedtke and K. Elphinstone and S. Schönberg and H. Härtig and G. Heiser and N. Islam and T. Jaeger},
+ booktitle = {Proceedings of the 4th Hot Topics in Operating Systems (HotOS-VI)},
+ year = {1997},
+ month = {May},
+ address = {Cape Cod, Massachusetts}
+}
+
+@Misc{GRUB,
+ author = {Erich Stefan Boleyn},
+ title = {GRUB, GRand Unified Bootloader},
+ howpublished = {http://www.gnu.org/software/grub/grub.html},
+}
+
+@MastersThesis{Gai00,
+ author = {Paolo Gai},
+ title = {Progetto e Realizzazione di un kernel Real-Time Modulare},
+ school = {Universit\`a di Pisa, Facolt\`a di Ingegneria, Corso di laurea in Ingegneria Informatica},
+ year = {2000},
+ address = {Via Diotisalvi, Pisa},
+ month = {May},
+}
+
+
+
+@MastersThesis{Gio00,
+ author = {Massimiliano Giorgi},
+ title = {Progetto e Realizzazione di un File System Modulare},
+ school = {Universit\`a di Pisa, Facolt\`a di Ingegneria, Corso di laurea in Ingegneria Informatica},
+ year = {2000},
+ address = {Via Diotisalvi, Pisa},
+ month = {May},
+}
+
+@Misc{GPL,
+ author = {{F}ree {S}oftware {F}oundation},
+ title = {{GNU} {G}eneral {P}ublic {L}icense ({GPL})},
+ howpublished = {http://www.gnu.org/copyleft/gpl.html},
+}
+
+@inproceedings{Dav95,
+ author = {Robert Davis and Andy Wellings},
+ title = {{D}ual {P}riority {S}cheduling},
+ booktitle = {Proceedings of the IEEE Real Time Systems Symposium},
+ year = 1995,
+ month = {December},
+ key = {scheduling}
+}
+
+
+
+
+
+
+
+
+@Book{POSIX1003.1,
+ editor = {IEEE Computer Society},
+ title = {International Standard ISO/IEC 9945-1: 1996 (E) - IEEE Std 1003.1, 1996 Edition - Information technology - Portable Operating System Interface (POSIX)},
+ publisher = {IEEE},
+ year = {1996},
+}
+
+
+@Book{POSIX1003.13,
+ editor = {IEEE Computer Society},
+ title = {IEEE Standard for Information Technology - Standardized Application Environment Profile - POSIX Realtime Application Support (AEP)},
+ publisher = {IEEE},
+ year = {1998},
+}
+
+
+
+
+
+@InProceedings{But97,
+ author = {G. C. Buttazzo and F. Sensini},
+ title = {Optimal Deadline Assignment for Scheduling Soft Aperiodic Tasks in Hard Real-Time Environments},
+ booktitle = {Proceedings of the 3rd IEEE International Conference on Engineering of Complex Computer Systems (ICECCS)},
+ pages = {pp. 39-48},
+ year = {1997},
+ address = {Como, Italy},
+ month = {September, 8-12},
+}
+
+@Misc{QNXNeutrino,
+ author = {{QNX} {S}oftware {S}ystems {L}td.},
+ title = {QNX Neutrino Real-Time OS},
+ howpublished = {http://www.qnx.com/products/os/neutrino.html},
+}
+
+@Misc{VXWorks,
+ author = {Wind River},
+ title = {VxWorks 5.4},
+ howpublished = {http://www.wrs.com/products/ html/vxwks54.html},
+}
+
+@Misc{Nemesis,
+author = "Ian Leslie and Derek McAuley and Richard Black and Timothy Roscoe and Paul Barham and David Evers and Robin Fairbairns and Eoin Hyden",
+title = "The Design and Implementation of an Operating System to Support Distributed Multimedia Applications",
+ howpublished = "http://www.cl.cam.ac.uk/Research/SRG/netos/pegasus/ papers/jsac-jun97/paper.html"
+}
+
+@InProceedings{Foh95,
+ author = {G. Fohler},
+ title = {Joint scheduling of distributed complex periodic and hard aperiodic tasks in statically scheduled systems.},
+ booktitle = {Proceedings of the 16th Real Time System Symposium, Pisa, Italy, Dec. 1995},
+ year = {1995}
+}
+
+@inproceedings{Cac00,
+ author = {Marco Caccamo and Giorgio Buttazzo and Lui Sha},
+ title = {Elastic Feedback Control},
+ booktitle = {Proceedings of the IEEE Euromicro Conference on Real-Time},
+ year = 2000,
+ month = {June},
+ address = {Stocolm, Sweden},
+ key = {scheduling}
+}
+
+
+
+
+
+
+
+
+
+
/branches/new_sharkdoc/common/retis.bib
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/common/manual.mk
===================================================================
--- branches/new_sharkdoc/common/manual.mk (nonexistent)
+++ branches/new_sharkdoc/common/manual.mk (revision 1676)
@@ -0,0 +1,52 @@
+# common part of the Shark manual makefiles
+
+# /toOl: build only if $(MAIN).pdf is not already present
+all: eps $(MAIN).pdf
+
+# /toOl: commented stuff is for MikTex
+$(MAIN).pdf: *.tex
+ latex $(MAIN).tex
+# makeindex $(MAIN)
+ bibtex $(MAIN)
+ latex $(MAIN).tex
+ latex $(MAIN).tex
+# dvips -R0 -t a4 -I c $(MAIN) -o $(MAIN).ps
+ dvips $(MAIN)
+ ps2pdf $(MAIN).ps
+ if test $(MAIN_NAME); then cp $(MAIN).pdf ../$(MAIN_NAME).pdf; fi
+
+clean:
+ rm -rf *.aux
+ rm -rf *.dvi
+ rm -rf *.log
+ rm -rf *.idx
+ rm -rf *.ind
+ rm -rf *.toc
+ rm -rf *.ilg
+ rm -rf *.out
+ rm -rf *.bbl
+ rm -rf *.blg
+ rm -rf *~
+ rm -rf $(MAIN).ps $(MAIN).pdf
+ rm -f $(EPS_DIA_FILES) $(EPS_FIG_FILES)
+
+cleanall: clean
+
+# automatic generation of eps files from sources
+
+DIA_FILES = $(shell find . -iname *.dia)
+EPS_DIA_FILES = $(patsubst %.dia,%.eps, $(DIA_FILES))
+
+FIG_FILES = $(shell find . -iname *.fig)
+EPS_FIG_FILES = $(patsubst %.fig,%.eps, $(FIG_FILES))
+
+.PHONY: eps
+
+eps: $(EPS_DIA_FILES) $(EPS_FIG_FILES)
+
+%.eps : %.dia
+ dia $< -t eps-builtin -e $@
+
+%.eps : %.fig
+ fig2dev -L eps $< $@
+
/branches/new_sharkdoc/common/manual.mk
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/common/biblio.bib
===================================================================
--- branches/new_sharkdoc/common/biblio.bib (nonexistent)
+++ branches/new_sharkdoc/common/biblio.bib (revision 1676)
@@ -0,0 +1,64 @@
+@inproceedings{Abe98,
+ author = {L. Abeni and G. Lipari and G. Buttazzo},
+ title = {Integrating Multimedia Applications in Hard Real-Time Systems},
+ booktitle = {In IEEE Proc. of the Real-Time System Symposium 98 Real-Time System},
+ year = {1998},
+ month = {December},
+}
+
+@book{But97,
+ author = {G. Buttazzo},
+ title = {Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications},
+ publisher = {Kluwer Academic Publishers},
+ year = {1997},
+ address = {Boston},
+}
+
+@inproceedings{Cla89,
+ author = {D. Clark},
+ title = {Hic: An Operating System for hierarchies of servo loops},
+ booktitle = {Proc. Of IEEE International Conference on Robotics and Automation},
+ year = {1989}
+}
+
+@inproceedings{Gai01,
+ author = {Paolo Gai and Luca Abeni and Massimiliano Giorgi and Giorgio Buttazzo},
+ title = {A New Kernel Approach for Modular Real-Time systems Development},
+ booktitle = {Proceedings of the 13th IEEE Euromicro Conference on Real-Time Systems},
+ month = {June},
+ year = {2001},
+ pages = {199-206},
+ address = {Delft, The Netherlands}
+}
+
+@inproceedings{Fac05,
+ author = {Tullio Facchinetti and Giorgio Buttazzo and Mauro Marinoni and Giacomo Guidi},
+ title = {Non-Preemptive Interrupt Scheduling for Safe Reuse of Legacy Drivers in Real-Time Systems},
+ booktitle = {ECRTS '05: Proceedings of the 17th Euromicro Conference on Real-Time Systems (ECRTS'05)},
+ year = {2005},
+ isbn = {0-7695-2400-1},
+ pages = {98--105},
+ doi = {http://dx.doi.org/10.1109/ECRTS.2005.21},
+ publisher = {IEEE Computer Society},
+ address = {Washington, DC, USA},
+}
+
+@article{Lip03,
+ author = {Giuseppe Lipari and Enrico Bini},
+ title = {Resource Partitioning among Real-Time Applications},
+ booktitle = {Proceedings of the 15th Euromicro Conference on Real-Time Systems},
+ location = {Porto, Portugal},
+ month = {July},
+ year = {2003}
+}
+
+@article{Liu73,
+ author = {C.L. Liu and J.W. Layland},
+ title = {Scheduling algoritms for multiprogramming in a hard real-time environment},
+ journal = {Journal of ACM},
+ year = {1973},
+ volume = {20},
+ number = {1},
+ month = {January},
+}
+
/branches/new_sharkdoc/common/biblio.bib
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/common/sssup.ps
===================================================================
--- branches/new_sharkdoc/common/sssup.ps (nonexistent)
+++ branches/new_sharkdoc/common/sssup.ps (revision 1676)
@@ -0,0 +1,1877 @@
+%!PS-Adobe-2.0 EPSF-2.0
+%%Title: /home/dad/doc/sssup.ps
+%%Creator: XV Version 3.10a Rev: 12/29/94 - by John Bradley
+%%BoundingBox: 13 684 153 832
+%%Pages: 1
+%%DocumentFonts:
+%%EndComments
+%%EndProlog
+
+%%Page: 1 1
+
+% remember original state
+/origstate save def
+
+% build a temporary dictionary
+20 dict begin
+
+% define string to hold a scanline's worth of data
+/pix 420 string def
+
+% define space for color conversions
+/grays 140 string def % space for gray scale line
+/npixls 0 def
+/rgbindx 0 def
+
+% lower left corner
+13 684 translate
+
+% size of image (on paper, in 1/72inch coords)
+139.96800 148.03200 scale
+
+% define 'colorimage' if it isn't defined
+% ('colortogray' and 'mergeprocs' come from xwd2ps
+% via xgrab)
+/colorimage where % do we know about 'colorimage'?
+ { pop } % yes: pop off the 'dict' returned
+ { % no: define one
+ /colortogray { % define an RGB->I function
+ /rgbdata exch store % call input 'rgbdata'
+ rgbdata length 3 idiv
+ /npixls exch store
+ /rgbindx 0 store
+ 0 1 npixls 1 sub {
+ grays exch
+ rgbdata rgbindx get 20 mul % Red
+ rgbdata rgbindx 1 add get 32 mul % Green
+ rgbdata rgbindx 2 add get 12 mul % Blue
+ add add 64 idiv % I = .5G + .31R + .18B
+ put
+ /rgbindx rgbindx 3 add store
+ } for
+ grays 0 npixls getinterval
+ } bind def
+
+ % Utility procedure for colorimage operator.
+ % This procedure takes two procedures off the
+ % stack and merges them into a single procedure.
+
+ /mergeprocs { % def
+ dup length
+ 3 -1 roll
+ dup
+ length
+ dup
+ 5 1 roll
+ 3 -1 roll
+ add
+ array cvx
+ dup
+ 3 -1 roll
+ 0 exch
+ putinterval
+ dup
+ 4 2 roll
+ putinterval
+ } bind def
+
+ /colorimage { % def
+ pop pop % remove 'false 3' operands
+ {colortogray} mergeprocs
+ image
+ } bind def
+ } ifelse % end of 'false' case
+
+
+
+140 148 8 % dimensions of data
+[140 0 0 -148 0 148] % mapping matrix
+{currentfile pix readhexstring pop}
+false 3 colorimage
+
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffcfcfcfffffffcfcfcfafafafffffff8f8f8fcfcfcffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffedededf7f7f7fffffffffffffffffffafafafcfcfc
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffdfdfdfffffffdfdfdefefeffffffffffffffdfdfd
+fdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff3f3f3fafafafffffffffffffffffffffffffffffffcfcfc
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffeeeeeefffffffffffff6f6f6f7f7f7ffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff2f2f2fffffffcfcfcf7f7f7fcfcfcf6f6f6fdfdfdffffff
+fdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffe8e8e8fffffffffffff9f9f9fffffffffffffcfcfc
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff0f0f00c0c0c0000000303030000000d0d0d000000070707
+000000000000000000000000000000000000000000000000ffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffcfcfcfffffffffffffffffffffffffafafaffffff
+fefefefffffff5f5f5fffffffafafaf8f8f8fffffffbfbfbfffffffbfbfbf6f6f6000000
+0f0f0f000000010101030303040404000000030303fffffff1f1f1fefefeffffffffffff
+fdfdfdfafafafffffffffffff7f7f7ffffff000000010101070707000000070707000000
+000000000000fffffffbfbfbfffffffdfdfdecececfffffffdfdfdf7f7f7fffffff1f1f1
+f9f9f9fffffff8f8f8fafafafffffffdfdfdfbfbfbfdfdfdfffffff3f3f3ffffffffffff
+fbfbfbfffffffffffff4f4f4ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff9f9f9fffffff2f2f2fcfcfcfffffff6f6f6ffffffffffff
+fdfdfdfffffff2f2f2ffffffffffffffffff0000000000000000001e1e1e000000ededed
+fffffffdfdfdfcfcfcfcfcfcfffffff5f5f5fefefefffffffffffffffffffffffffefefe
+fffffffffffff2f2f2fafafafffffff2f2f2fffffffffffff6f6f6fffffff5f5f5ffffff
+fbfbfbffffff000000000000000000070707fffffffdfdfdfffffffbfbfbefefefffffff
+fffffff9f9f9f4f4f4fffffffffffffffffffffffffffffffdfdfdfffffffffffffafafa
+f6f6f6f9f9f9ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffefefefffffffffffff8f8f8
+ffffffecececfffffff3f3f30000000d0d0d0000000d0d0df3f3f3ffffffffffffffffff
+f7f7f7fdfdfdfffffffffffffcfcfcfffffffffffff7f7f7fafafaffffffecececfbfbfb
+f7f7f7fffffffffffff6f6f6f6f6f6fffffffffffff5f5f5fafafafffffff3f3f3fcfcfc
+fffffff5f5f5edededffffffffffff020202000000000000000000fbfbfbfffffff8f8f8
+fffffff1f1f1fffffff7f7f7f0f0f0f8f8f8fffffff8f8f8f0f0f0fffffff2f2f2ffffff
+fffffffafafafbfbfbffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff4f4f4fffffff8f8f8fffffff1f1f1ffffffffffffffffff
+030303000000000000f9f9f9ffffffecececfffffff6f6f6ffffffedededffffffffffff
+fdfdfdfefefefcfcfce7e7e7f8f8f80f0f0f000000f5f5f5ffffff000000ffffffffffff
+fefefefffffff8f8f8fffffffefefeffffffecececffffff0d0d0d0000000c0c0cf9f9f9
+fbfbfbffffffffffffe8e8e8f8f8f8fffffffbfbfbffffffffffff050505010101000000
+f9f9f9fffffff4f4f4fffffffffffffffffff5f5f5fffffffffffffffffffbfbfbfdfdfd
+fffffffcfcfcfcfcfcffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffcfcfcfffffff4f4f4fffffffefefe000000000000
+000000ffffffffffffffffffecececfffffffffffffffffff9f9f90d0d0df9f9f9ffffff
+000000060606020202ffffff000000f0f0f0fffffffffffff2f2f2000000fffffffdfdfd
+ffffff000000fbfbfbfdfdfdf4f4f4f3f3f3fffffff8f8f8f7f7f7f7f7f70000000f0f0f
+000000fffffffbfbfbffffffffffffe4e4e4fffffff9f9f9fbfbfbfdfdfdffffffffffff
+0808080000000a0a0afffffff2f2f2ffffffefefeffdfdfdf9f9f9f5f5f5fffffffbfbfb
+ebebebfffffffffffffbfbfbffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff0f0f0fffffff8f8f8f0f0f0090909000000f4f4f4ffffff
+fffffff6f6f6f9f9f9fdfdfdffffffffffff000000000000000000fafafafffffff9f9f9
+050505f8f8f8000000000000000000fffffffefefee7e7e7ffffff101010f5f5f5f7f7f7
+fbfbfb040404fffffffffffff5f5f5fffffff6f6f6fdfdfdfcfcfcffffff000000f3f3f3
+ffffffe0e0e0161616fafafaf6f6f6ffffffffffffefefeffffffffffffff6f6f6f8f8f8
+fffffffdfdfdeeeeee000000000000fffffffefefefffffffffffff3f3f3ffffffffffff
+fffffffffffffefefef8f8f8ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffefefef0b0b0b0b0b0bfafafafffffffffffff3f3f3
+f3f3f3fffffffdfdfd000000ffffffffffff000000ffffff030303fcfcfcfffffffefefe
+010101fffffff6f6f60d0d0df8f8f8121212000000ffffffeeeeee000000ebebebffffff
+020202000000ecececeaeaeafffffffffffff7f7f7fffffffcfcfc000000ffffffffffff
+f3f3f3ffffff010101f8f8f8fefefef8f8f80000000000000d0d0df8f8f8fbfbfbffffff
+f4f4f4ffffffffffffffffffffffff0000000f0f0ff8f8f8f1f1f1fffffffbfbfbffffff
+ffffffefefefffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffff000000040404fcfcfcf5f5f5fffffff8f8f8ffffffffffff
+ffffff000000fafafa0f0f0ff2f2f2fffffffffffffcfcfc000000fffffff8f8f8ffffff
+f7f7f7f4f4f40b0b0bf7f7f7ffffffffffff000000060606ffffff000000fffffffdfdfd
+040404fcfcfc0e0e0efffffff5f5f5fffffffffffff9f9f9f6f6f60d0d0df6f6f6fdfdfd
+ffffffffffff000000fffffffbfbfbffffff000000fefefe000000fdfdfdfffffff4f4f4
+fffffff4f4f4fffffffcfcfcfafafafffffffdfdfd0000000d0d0df1f1f1fffffffafafa
+fffffff0f0f0fffffff6f6f6ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffff2f2f2fffffffffffffefefef7f7f7fffffffefefefffffffafafafcfcfcf6f6f6
+ffffffffffff000000000000f7f7f7fffffff1f1f1f9f9f9fffffffffffff7f7f7080808
+f7f7f70d0d0df5f5f5ffffff121212f9f9f9030303f5f5f5000000191919010101eeeeee
+ffffff000000000000fffffffdfdfdffffffffffff000000fefefe000000fefefefefefe
+ffffff000000060606fafafafcfcfcfffffffffffff8f8f8ffffff000000fffffff8f8f8
+fffffff0f0f0131313f7f7f7f6f6f6fffffff9f9f9fdfdfd000000fefefefbfbfb070707
+000000fffffff6f6f6f9f9f9fefefefffffffcfcfcf9f9f90f0f0f000000ffffffffffff
+f8f8f8fffffff7f7f7f9f9f9fffffff6f6f6fffffff8f8f8fffffffbfbfbf8f8f8ffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+f6f6f6fffffffbfbfbe5e5e5fffffffffffff5f5f5fffffffffffffafafafffffffafafa
+000000000000eeeeeeffffffffffffffffffffffff0b0b0b000000fffffffffffff3f3f3
+fefefefcfcfc000000ffffffececec060606fbfbfbffffff060606f1f1f1f9f9f9ffffff
+e6e6e60e0e0effffff030303fffffff3f3f3fffffff9f9f9ffffff0b0b0bfefefefdfdfd
+fcfcfc070707000000ffffff000000070707e7e7e7ffffffffffff090909f8f8f8ffffff
+000000000000010101fdfdfdffffff000000020202000000101010ffffffffffff000000
+fffffff3f3f3fffffffffffffafafafffffffffffffffffff8f8f8ffffff000000020202
+000000f2f2f2ffffffffffffffffffeeeeeefffffffffffffafafaf3f3f3fffffff6f6f6
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffafafaf1f1f1fffffffdfdfdf2f2f2fffffffffffffdfdfdfefefefafafa111111
+000000fffffffffffff3f3f3fffffff6f6f6000000ffffff000000060606fbfbfbffffff
+0a0a0affffff080808ffffffffffff000000fffffff1f1f1ffffff101010fffffff9f9f9
+ffffff000000f1f1f1000000ffffff000000ffffff060606dcdcdc0e0e0ef4f4f4ffffff
+000000010101010101000000080808000000ffffffecececffffff000000fbfbfbfafafa
+ffffff000000000000fffffffafafa0303030c0c0c000000f0f0f0ffffffffffff050505
+fffffffffffffcfcfcffffffffffff000000f7f7f7fffffffffffffafafafffffff6f6f6
+0d0d0d000000fdfdfdfefefefdfdfdfdfdfdfffffff6f6f6fefefeffffffefefefffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffebebebfffffffafafafcfcfcfdfdfdf4f4f4fefefeffffffffffff000000ffffff
+ffffffefefeffafafa010101fefefeffffffffffff000000fdfdfd000000121212000000
+000000ffffff000000f9f9f9ffffffececec060606fffffffcfcfc000000fffffffcfcfc
+ffffff030303fbfbfbffffff000000ffffff000000fcfcfcffffff000000000000070707
+020202000000010101030303111111000000f7f7f7ffffff000000070707ffffffffffff
+ffffffffffff000000fdfdfdfdfdfd090909000000ffffffffffffefefef010101f9f9f9
+f0f0f0fffffff8f8f8f4f4f4080808ffffff030303efefeffafafafcfcfcfdfdfdffffff
+fefefe050505000000f6f6f6fffffff0f0f0fffffff1f1f1ffffffffffffefefefffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffefefefefefef7f7f7ffffffffffffffffff000000000000fffffff9f9f9
+ffffffffffffffffff000000010101f4f4f4f1f1f1fffffffdfdfd000000ffffff010101
+0d0d0d000000ffffff000000ffffffffffff000000fefefeffffff060606060606000000
+f1f1f1060606fffffffffffffafafaf9f9f9fffffff0f0f00606060909090a0a0a000000
+000000ffffff030303000000f1f1f1020202ffffff000000000000fdfdfdf6f6f6f6f6f6
+fafafaffffff080808ffffff010101f9f9f9070707fffffff4f4f4f9f9f9171717ffffff
+101010000000fcfcfc080808000000fffffffafafafffffffffffff3f3f3fafafaffffff
+edededfffffff5f5f5080808efefeffffffffffffffffffffdfdfdfdfdfdffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fbfbfbfffffff6f6f6f7f7f7fffffffafafaf3f3f30000000a0a0afffffffcfcfcffffff
+f5f5f5f6f6f6ffffffffffff000000fffffffffffffbfbfb030303ffffffebebebffffff
+000000000000ffffff000000f3f3f3fffffffffffff9f9f9f8f8f8ecececffffffffffff
+ffffffe8e8e8fffffff6f6f6fffffffdfdfdffffffffffff0000000000000000000b0b0b
+fcfcfcfafafa000000ffffff0000000404040b0b0b000000000000ffffffffffffffffff
+fffffffbfbfbeaeaeaffffff060606ebebeb0b0b0b000000ffffff010101fafafaf3f3f3
+000000000000ffffff000000000000ecececfffffff8f8f8fffffffffffff9f9f9ffffff
+fffffffffffff9f9f9ffffff0b0b0b000000fcfcfcf5f5f5f3f3f3ffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fcfcfcffffffffffffebebebfffffff7f7f7050505fffffff1f1f1f8f8f8fffffffefefe
+fffffffefefefffffffafafaf9f9f9151515f4f4f4f6f6f6fffffff4f4f4000000ffffff
+ffffff0000000000000000000c0c0cfdfdfdf7f7f7fefefefffffffbfbfbf8f8f8ffffff
+fbfbfbfffffffffffffffffff1f1f1ffffffffffff0000000d0d0d080808000000ffffff
+ffffff000000030303ffffffffffff000000000000090909000000000000fffffffcfcfc
+e5e5e5f8f8f8fffffffcfcfcf9f9f9ffffffffffff000000ffffff000000f9f9f9ffffff
+fffffff9f9f9000000ffffff0000000d0d0dfffffffafafaf3f3f3ffffff000000000000
+fffffff9f9f9fffffff9f9f9fafafa000000070707ffffffffffffeeeeeefffffffcfcfc
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fcfcfcfffffff1f1f1fffffffbfbfb000000fffffff9f9f9fffffffbfbfb000000f6f6f6
+fffffff4f4f4fcfcfcfffffffafafa000000f8f8f8fffffff6f6f6090909fffffffafafa
+f5f5f5fffffffffffffafafafffffff7f7f7fcfcfcfffffff8f8f8fffffffffffffafafa
+ffffff000000000000fbfbfb030303000000000000030303000000030303f0f0f0ffffff
+000000000000ffffff000000fbfbfbffffff0000000202020000000a0a0a000000000000
+ffffffffffff000000fafafafffffff3f3f3fafafafdfdfdffffff000000fefefefefefe
+f9f9f9ffffff000000fffffffffffffbfbfbf3f3f3ffffffffffff010101000000ffffff
+000000fffffffffffffdfdfdffffffffffffffffff000000fefefefefefeffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffecececfffffffdfdfdf8f8f8fefefefffffffbfbfb
+fffffffffffffdfdfd0000000d0d0dfcfcfcf7f7f7fffffffafafafffffff9f9f9000000
+f8f8f8ffffff000000020202000000fbfbfb040404ffffffffffff000000ffffff000000
+f9f9f9fffffff3f3f3fefefefffffffffffff7f7f7fffffffefefefcfcfcfffffff7f7f7
+ffffff0c0c0c000000ffffff000000040404000000000000080808f1f1f1ffffff000000
+000000fefefeffffffffffff030303f8f8f8ffffff0000000000000000000707070d0d0d
+fafafafbfbfb0c0c0cf9f9f9fffffffffffffffffffbfbfbfffffff3f3f3fffffff1f1f1
+fdfdfd060606fbfbfbfffffffdfdfdffffff0a0a0a000000f9f9f9090909fefefe000000
+0e0e0e0b0b0b000000030303fcfcfcf9f9f9ffffffffffff030303000000fdfdfdfdfdfd
+fffffffffffffffffff4f4f4f2f2f2fffffffafafaffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff8f8f8fffffff4f4f4fffffffffffff4f4f4fffffff9f9f9
+ffffffffffff000000000000f6f6f6fbfbfbfffffff0f0f0ffffffffffffffffff000000
+060606fefefefefefe000000f9f9f9ffffff000000000000fcfcfc030303fbfbfbffffff
+fafafaffffffffffffffffffedededf4f4f4ffffffe9e9e9fffffffffffffdfdfdffffff
+e9e9e9000000000000f8f8f8ffffff0e0e0e000000060606ffffffffffff000000000000
+050505000000070707f4f4f4ffffff010101f6f6f61b1b1b030303000000000000050505
+f9f9f9ffffff000000fffffffffffffffffff4f4f4fcfcfcfffffffbfbfbffffffffffff
+ffffff000000000000fffffffffffff7f7f7eeeeeeffffff0707070000000707070b0b0b
+f8f8f80000001313130e0e0efffffffffffffdfdfdffffffdfdfdf161616fafafaffffff
+ffffffefefefebebebfffffffffffffcfcfcffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffff2f2f2fffffff7f7f7fefefeffffff
+fffffff7f7f7010101fffffffdfdfdf4f4f40404040606060000000e0e0effffffffffff
+000000f3f3f3fffffffffffffffffff7f7f7fffffffbfbfb000000000000fbfbfbffffff
+fffffff1f1f1fbfbfbfffffffffffffffffffafafa171717000000e2e2e2fffffffbfbfb
+ffffff101010000000ffffff000000000000000000ffffffffffff000000ededed0a0a0a
+0000001010100d0d0d000000000000121212000000eaeaea0505050404040b0b0b000000
+0a0a0aefefef000000ffffffefefeffffffffffffffffffffbfbfbfdfdfdf9f9f9fefefe
+fefefeffffffffffff000000fffffffffffffffffffdfdfd0000000c0c0c000000000000
+000000000000efefeffdfdfdf8f8f8fffffffcfcfcfbfbfbfffffff0f0f0020202f0f0f0
+f9f9f9fffffffbfbfbffffffffffffefefefffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffdfdfdffffffe2e2e2fcfcfcf7f7f7fffffffefefefafafa
+020202000000ffffffe7e7e7ffffff000000040404fdfdfdfefefef3f3f3060606000000
+ffffff000000f7f7f7fdfdfdefefeffffffffefefefafafafffffffdfdfdfffffff7f7f7
+fffffff3f3f3fffffffffffffdfdfdfdfdfdffffff000000040404fffffff8f8f8ffffff
+ffffffe7e7e70c0c0c000000000000171717fdfdfdffffff0000000000000b0b0b000000
+000000050505000000000000000000000000fdfdfd070707f0f0f0ffffff000000070707
+090909090909020202000000fffffffffffffefefefffffffefefe0d0d0df7f7f7ffffff
+ffffffffffffedededffffffefefeffffffffefefe080808fffffffffffff9f9f90b0b0b
+080808fbfbfbfffffffafafaffffff000000000000fdfdfdf9f9f9f8f8f8ffffff181818
+000000f5f5f5f8f8f8f6f6f6ebebebfffffffafafaffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffbfbfbfffffffffffffffffffffffffdfdfdffffff000000
+010101fffffffafafafbfbfb040404ffffffffffff000000fffffffffffff8f8f8000000
+fdfdfdffffff040404fffffffffffff8f8f8ebebebfffffff8f8f8fffffffffffffcfcfc
+fffffffffffffffffffdfdfdfefefef4f4f4ffffff0b0b0b000000fffffff5f5f5f7f7f7
+fdfdfdffffff000000000000fffffff8f8f8fafafa000000040404ffffff050505f5f5f5
+070707ffffffededed0c0c0c090909000000ffffffffffff131313000000f9f9f9060606
+0000000000000c0c0c000000f9f9f9fafafaffffffeeeeeefcfcfc020202fffffffafafa
+f6f6f6f7f7f7f9f9f9f0f0f0ffffffffffff050505000000fefefef6f6f60b0b0b000000
+f5f5f5080808ffffffffffff040404fdfdfdffffffe8e8e8f9f9f9fffffff1f1f1eeeeee
+000000fffffffffffffffffffffffff6f6f6fefefef7f7f7ffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffedededf1f1f1f9f9f9ffffffefefefffffff040404
+fcfcfcf9f9f9fffffffcfcfcf0f0f0040404fafafa1d1d1dfafafafffffff2f2f2ffffff
+0c0c0ceaeaea000000000000fefefefdfdfdfffffff7f7f7f8f8f8fffffffcfcfcffffff
+fffffffffffffbfbfbf8f8f8fffffffffffff6f6f6000000090909f8f8f8ffffffffffff
+f5f5f5ffffff0000000d0d0df4f4f4f9f9f9ffffff020202fcfcfcffffff000000070707
+f9f9f9f5f5f5ffffff000000111111000000050505f9f9f9000000080808000000f4f4f4
+171717000000fbfbfb090909fffffff2f2f2f5f5f5fffffff2f2f2010101fffffff8f8f8
+fffffffdfdfdfffffffffffffdfdfdf7f7f7fffffffbfbfbfffffff7f7f7000000ffffff
+fffffffbfbfbf4f4f4040404000000fafafa000000fffffffdfdfdf4f4f4ffffffffffff
+f8f8f81b1b1be8e8e8f5f5f5f5f5f5fffffffbfbfbffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff4f4f4ffffffffffffefefefffffffffffff000000fbfbfb
+fcfcfcfffffffafafafffffffffffffbfbfb000000ededed000000f7f7f7fffffff4f4f4
+000000fffffffffffffbfbfbf7f7f7f7f7f7fdfdfdffffffffffffffffffe7e7e7ffffff
+fdfdfdfbfbfbfffffff8f8f8fffffffefefefefefe101010000000fafafafffffffcfcfc
+ffffffffffff000000000000ffffffffffff000000020202000000040404000000000000
+f7f7f7ffffffffffff0d0d0d0202020000000a0a0afdfdfd0b0b0bf5f5f5232323f2f2f2
+f5f5f50a0a0af2f2f2080808000000fffffffffffff9f9f9ffffff000000fffffffdfdfd
+e6e6e6fffffffafafaf4f4f4fffffffffffff2f2f2fffffff5f5f5040404ffffffffffff
+fffffff8f8f80d0d0d000000fcfcfc101010040404f9f9f9fffffffbfbfbf7f7f7ffffff
+f9f9f9fbfbfb0b0b0bfffffffffffffffffff9f9f9fcfcfcffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffff2f2f2ffffffffffff000000000000fffffffcfcfc
+fdfdfdf7f7f7070707fafafaf7f7f7ffffffffffff020202ffffff040404efefefffffff
+060606f8f8f8fefefefafafafefefefffffffafafafefefefefefefffffffffffffefefe
+fffffff6f6f6fffffffefefef8f8f8fffffff9f9f90000000101010a0a0afdfdfdf7f7f7
+ffffff000000080808000000fffffff2f2f2050505010101000000000000ffffffffffff
+070707f3f3f3ffffff000000080808fdfdfd060606fcfcfcfffffffffffff0f0f0ffffff
+ffffff030303fcfcfc0000000e0e0ee8e8e8fefefeffffff0000000e0e0ef8f8f8ffffff
+fffffff7f7f7fffffffdfdfdfffffff6f6f6ffffffffffffffffffe9e9e90d0d0d000000
+080808060606000000070707000000fffffff8f8f8fdfdfdffffff000000000000ffffff
+fcfcfcfffffffafafa090909f2f2f2f8f8f8ffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffff4f4f4fffffffffffffbfbfb
+fffffffffffff3f3f3fffffffefefefffffffffffffafafa030303f8f8f8fbfbfbfdfdfd
+000000060606fcfcfc000000fbfbfbfffffffbfbfbfdfdfd070707eeeeee0202020b0b0b
+000000fffffffdfdfdfdfdfdffffffffffffffffffffffffffffffffffffffffffffffff
+f9f9f9fffffffffffffffffffdfdfdfafafaffffffffffff0404040000000f0f0ffcfcfc
+ffffff000000000000000000fffffff3f3f3080808000000060606000000fefefeffffff
+fdfdfdffffff000000000000000000f7f7f70a0a0a000000fdfdfdfefefeffffff000000
+040404000000ffffff000000020202ffffffffffffffffff000000000000fafafafdfdfd
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff9f9f9ffffff000000
+010101000000ffffff000000fffffffafafaffffffffffff000000fcfcfc000000030303
+fffffff9f9f9f9f9f9ffffff000000fffffff7f7f7fffffffffffff9f9f9fefefef6f6f6
+fdfdfdfffffff4f4f4ffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff9f9f9f6f6f6
+fafafafffffffffffffdfdfdfffffff9f9f9f6f6f6010101fffffffafafaffffff000000
+0e0e0efafafafcfcfcffffff000000fffffff1f1f1fdfdfdfdfdfdffffff010101ffffff
+fffffff6f6f6fffffffdfdfdffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffff9f9f9f8f8f8fffffffffffffffffff5f5f5000000181818000000050505
+0000000b0b0b000000040404000000ffffff000000111111f6f6f6000000ffffff000000
+000000090909010101000000191919fdfdfd000000030303fcfcfcfffffffbfbfb111111
+f7f7f7000000ffffff000000020202f9f9f9fffffffefefe040404000000fdfdfdfdfdfd
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff4f4f4ffffff
+f3f3f3fefefefafafa000000f9f9f9fffffff5f5f5000000fefefeffffffffffff000000
+fffffffafafafdfdfdffffff000000fdfdfdf8f8f8fbfbfbf2f2f2fffffffffffffdfdfd
+fffffffbfbfbfffffff4f4f4ffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffbfbfbfafafaffffff
+fffffff2f2f2fffffff0f0f0f4f4f4ffffff000000fffffffffffff5f5f5f5f5f5000000
+000000040404fffffff3f3f3fafafa0000000f0f0ffffffffbfbfb000000f6f6f6ffffff
+fefefefffffffdfdfdffffffffffffffffffffffffffffffffffffffffffffffffffffff
+f9f9f9fefefefffffffffffff9f9f9f3f3f3fbfbfbffffff090909000000040404080808
+000000000000000000040404070707f9f9f90101010b0b0bffffff070707ededed050505
+0b0b0b050505000000090909000000000000080808000000f6f6f6fffffff9f9f9f9f9f9
+ffffff050505ffffff000000000000080808000000000000000000000000ffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff8f8f8fefefeffffff
+f9f9f9fefefe080808ffffffffffff0909090000000c0c0c000000f7f7f7ececec040404
+000000fffffffafafaf6f6f6ffffff0b0b0bfffffffdfdfdfffffff6f6f6f7f7f7fafafa
+f6f6f6fffffff9f9f9ffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffcfcfcfcfcfcffffff
+fdfdfdfbfbfbffffffffffffffffff000000131313edededf5f5f5ffffffefefefffffff
+ffffff000000181818ffffffffffffffffff0000000000000a0a0a000000fcfcfcf6f6f6
+f8f8f8fffffff9f9f9fdfdfdffffffffffffffffffffffffffffffffffffffffffffffff
+fffffff3f3f3fafafafdfdfdfffffffbfbfbf9f9f9f5f5f50707070d0d0d000000010101
+050505000000fcfcfcfefefe000000000000030303f5f5f5f8f8f8010101ffffff060606
+0000000000000d0d0d0101010505050d0d0d000000070707ffffff000000fffffff4f4f4
+f7f7f7000000ffffff0606060202020000000000000b0b0b000000111111f3f3f3ffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffafafaffffffffffffe9e9e9
+fffffffefefefafafa000000000000000000f5f5f5ffffff000000fcfcfc0e0e0e000000
+f0f0f00f0f0fffffffedededf8f8f8fbfbfb000000ffffffeeeeeeffffffffffffffffff
+ecececf3f3f3fffffff2f2f2ffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffbfbfbffffffffffffebebeb
+fbfbfbfffffff5f5f5f9f9f9ffffff000000f6f6f6fafafaffffffffffffffffffefefef
+f8f8f8fefefe000000fffffff0f0f0f9f9f9f9f9f9101010000000ffffffffffffffffff
+f6f6f6f3f3f3fffffffcfcfcffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffbfbfbfffffffcfcfcf8f8f8fffffffffffffbfbfb0000000000000f0f0f040404
+000000000000181818000000040404000000000000000000ffffff0e0e0efcfcfc060606
+0a0a0a0000000505050303030a0a0aececec131313000000f7f7f7040404ffffffeaeaea
+ffffff0d0d0df3f3f3000000000000181818000000000000000000010101fffffff6f6f6
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffefefefbfbfbffffff
+ffffffffffffeeeeeeffffff0a0a0af6f6f6fffffffefefefbfbfb050505000000fbfbfb
+ffffff000000f8f8f8fffffffffffffafafa000000000000fffffffefefefffffffbfbfb
+fffffffcfcfcf6f6f6fbfbfbffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffff8f8f8fefefeffffffffffff
+fffffffffffff3f3f3ffffff000000ffffffffffffffffff000000000000fffffffcfcfc
+ffffffffffffffffff000000070707f7f7f7fffffff3f3f3fffffffdfdfdfafafaf7f7f7
+fffffff9f9f9fafafaffffffffffffffffffffffffffffffffffffffffffffffffffffff
+f7f7f7fcfcfcfffffffdfdfdffffffffffffdadada0000000a0a0a000000000000ffffff
+0d0d0d000000000000000000000000ffffff090909ffffff000000000000ffffff000000
+fafafa000000f6f6f6101010ffffff0000000000000c0c0c000000fffffffdfdfdffffff
+fdfdfd000000ffffff030303fefefee7e7e7ffffffffffffffffff000000fffffffbfbfb
+fffffffffffffffffffffffffffffffffffffffffffffffffcfcfcffffffffffffffffff
+ffffffecececffffffe7e7e7fbfbfbf2f2f2ffffffffffff040404000000010101f7f7f7
+efefefffffffffffff000000eeeeeefffffffdfdfd080808f4f4f4fefefee8e8e8ffffff
+edededfffffffffffffdfdfdffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffefefefffffff
+fffffffbfbfbfffffff1f1f1fffffff0f0f0f5f5f5ffffffe6e6e60d0d0dfffffff6f6f6
+f7f7f7ffffffedededf7f7f7ffffff070707f3f3f3fffffff9f9f9fffffff8f8f8ffffff
+fffffff8f8f8fffffff9f9f9ffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffff6f6f6f3f3f3ffffffffffff0e0e0e0000000808080f0f0ff2f2f2
+f9f9f90000000000000c0c0c0c0c0cfdfdfd000000000000030303050505131313ffffff
+090909ffffff030303000000fafafaffffff050505000000070707020202020202f9f9f9
+f9f9f90e0e0effffff000000ffffff000000000000070707e6e6e60e0e0effffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff3f3f3fbfbfb
+fcfcfcfffffff3f3f3ffffffffffffffffff000000000000fafafaf9f9f9ffffffffffff
+fffffffffffffffffff5f5f50b0b0bebebebffffffffffff000000ffffffeeeeeeffffff
+fffffffcfcfcfdfdfdffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffff6f6f6fffffff0f0f0ffffff
+fafafafffffff1f1f10d0d0dfffffffffffffdfdfdffffffffffff0000000000000b0b0b
+030303000000090909fffffff2f2f2010101fffffffbfbfbfffffff8f8f8ffffffffffff
+f3f3f3fffffff9f9f9fdfdfdffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffafafaf4f4f4fffffffffffff7f7f7ffffff000000050505050505000000ffffff
+ffffff0000000a0a0a000000000000ffffff030303000000ffffff000000000000030303
+0000000707070000001414140000000000000f0f0ffafafa040404000000000000050505
+ffffff000000fbfbfb000000f2f2f20b0b0bffffff020202ffffff000000fffffffdfdfd
+fffffffffffffffffffffffffffffffffffffffffffffffff3f3f3fffffffffffffefefe
+f3f3f3fffffff9f9f9fffffff7f7f7fbfbfb000000fffffffdfdfdf9f9f9fffffffdfdfd
+f6f6f6fffffff6f6f6ffffff090909fffffffafafafefefe010101000000fffffffefefe
+f7f7f7fffffffffffffcfcfcffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffafafaffffffffffff
+fbfbfbffffff000000000000f8f8f8fffffffffffffbfbfbf9f9f9ffffffffffffffffff
+fafafaffffff090909000000fffffffffffff6f6f6ffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffefefefffffffffffffdfdfdfffffffcfcfc010101ffffff000000020202ffffff
+ffffff000000000000020202000000010101000000000000ffffff050505fefefe080808
+0a0a0af9f9f90d0d0d000000fdfdfd000000000000070707040404060606000000040404
+000000040404ffffff000000000000000000fafafa030303ffffff000000fffffffbfbfb
+fffffff9f9f9fafafaf5f5f5fffffff5f5f5fffffff7f7f7ffffffffffffffffffffffff
+fffffffffffffffffffffffffffffff6f6f6ffffff000000fffffffffffffffffffbfbfb
+fdfdfd000000090909000000000000fcfcfcfdfdfdfefefefafafa040404fffffffdfdfd
+fefefefffffffafafafefefeffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffff1f1f1fffffffefefeffffff
+f1f1f1ffffff0f0f0ffffffffffffffffffffdfdfdfffffffffffff9f9f9fcfcfcf1f1f1
+fffffffefefefefefe000000f9f9f9fdfdfdffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffefefefffffffffffffdfdfdfffffffcfcfc010101f9f9f9131313080808e4e4e4
+ffffff000000000000020202090909000000ffffffffffffeeeeee0e0e0efdfdfd000000
+000000ffffff000000080808ffffffffffff000000fbfbfb030303f1f1f1ffffff010101
+000000000000f0f0f0090909040404000000ffffff030303f8f8f8010101fffffffdfdfd
+edededfafafafffffffefefefffffffefefef3f3f3ffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffff7f7f7ffffffffffff0000000000000000000a0a0a
+0a0a0af1f1f1ffffffffffffffffff000000030303fefefef8f8f8ffffff000000f2f2f2
+f8f8f8ffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff5f5f5fefefeffffff
+ffffff020202f8f8f8f1f1f1ffffffefefeffdfdfdfffffff2f2f20101010e0e0effffff
+ebebebffffff000000070707fffffffffffff4f4f4ffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffefefefffffffffffffdfdfdfffffffcfcfc010101f8f8f8000000000000101010
+f9f9f90000000707070a0a0affffff000000fbfbfbfafafaffffff0000000d0d0df8f8f8
+ffffff0303030e0e0efcfcfc000000000000fcfcfcffffffffffff030303010101ffffff
+0101010101010b0b0b000000000000060606eeeeee020202ffffff020202ebebebffffff
+fffffffffffffffffff7f7f7fdfdfdfffffff1f1f1ffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff4f4f4fffffffffffff5f5f5ffffff090909ffffffefefef
+fffffff1f1f1ffffffeeeeee0000000d0d0decececfffffffffffff3f3f3040404ffffff
+f8f8f8fdfdfdffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff9f9f9fffffff9f9f9
+f6f6f6000000ffffffffffff0505050a0a0afdfdfdf8f8f8ffffff020202000000fcfcfc
+fffffff3f3f3fffffffffffffcfcfce9e9e9ffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffefefefffffffffffffdfdfdfffffffcfcfc010101ffffff0202020a0a0a000000
+ffffff0606060000000000000000000d0d0d000000f9f9f9ffffff030303efefefffffff
+f1f1f1030303f2f2f2ffffff040404000000101010e8e8e8000000fffffffbfbfbf4f4f4
+0c0c0c000000040404070707fcfcfc000000ffffff0c0c0cf1f1f1000000fffffff9f9f9
+f5f5f5f5f5f5fefefeffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffefefefffffffffffffcfcfc000000edededffffff
+ffffffffffffffffff090909000000fffffffffffff9f9f9f7f7f7f5f5f5ffffff000000
+f9f9f9fffffffffffff4f4f4ffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffff1f1f1fffffffcfcfcfdfdfd
+030303fffffff2f2f2fefefe050505f6f6f6fffffffdfdfdffffffffffffffffffffffff
+fefefefffffffbfbfbf4f4f4f6f6f6fffffffffffffbfbfbffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffefefefffffffffffffdfdfdfffffffcfcfc010101ffffff0000000000000c0c0c
+f8f8f8010101ffffffffffff050505000000ffffff060606000000040404060606000000
+0202020f0f0f000000000000ffffff0000000000000c0c0c0000000e0e0efffffff1f1f1
+fffffffcfcfc000000000000000000060606e0e0e0030303fdfdfd020202fffffffcfcfc
+fffffffffffffffffffffffffafafaf9f9f9ffffffecececffffffffffffffffffffffff
+ffffffffffffffffffffffffecececfffffffffffffdfdfdfcfcfcffffff050505000000
+f1f1f10000000303030000000b0b0b000000000000070707fffffffffffff4f4f4020202
+090909edededfdfdfdffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffefefeffffffff6f6f6
+000000edededfffffffefefe000000ffffffffffffffffff000000f8f8f8ffffffeeeeee
+f4f4f4fffffffffffff3f3f3fffffff5f5f5f6f6f6ffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffefefefffffffffffffdfdfdfffffffcfcfc010101fdfdfd010101000000121212
+f1f1f1000000ffffff000000000000000000010101e8e8e8ffffffffffff060606000000
+000000000000ffffffffffff0000000b0b0b0000000a0a0a000000020202000000060606
+000000010101000000151515ffffffffffffffffff000000f8f8f8090909ebebebffffff
+f5f5f5fffffff3f3f3f4f4f4fffffffffffff6f6f6ffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffff9f9f9fffffffffffff2f2f2ffffffffffff020202
+0404040000000a0a0a060606000000ecececfffffffcfcfcfdfdfdf6f6f6ffffffffffff
+000000fffffff6f6f6ffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffafafa030303
+fffffffffffffffffff5f5f5000000020202010101000000fefefef5f5f5ffffff040404
+fcfcfcfffffffefefef3f3f3fefefefdfdfdfffffff2f2f2ffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffefefefffffffffffffdfdfdfffffffcfcfc010101ffffff000000090909000000
+ffffffffffffffffff010101090909000000000000171717070707000000fffffffefefe
+fbfbfb0707070202020a0a0a000000131313000000000000020202000000000000000000
+111111000000060606000000f5f5f5000000f2f2f2070707f5f5f50d0d0df9f9f9ffffff
+ffffff0000000e0e0efffffff7f7f7fffffff4f4f4ffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffdfdfdfdfdfdfffffffefefefffffff7f7f7f6f6f6ffffff
+000000040404000000fefefeffffffffffffffffffeeeeeefffffffffffffbfbfbfafafa
+020202f0f0f0fffffff0f0f0ffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffff9f9f9fcfcfcffffff000000
+fbfbfbffffffe7e7e7fffffffffffffbfbfb000000000000fffffffffffff3f3f3030303
+fffffff2f2f2fffffffffffffdfdfdfffffffbfbfbffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffefefefffffffffffffdfdfdfffffffcfcfc010101fcfcfc030303ffffff060606
+fafafaffffff000000000000000000000000fffffff6f6f6ffffff000000010101060606
+0202020202020000000505050000000000000202020a0a0a010101ffffff010101000000
+040404040404000000ffffffffffffffffffffffff000000ffffff0000000a0a0a000000
+000000000000010101000000000000fffffff9f9f9ffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffdfdfdfffffff6f6f6fffffffffffffbfbfbfffffff6f6f6
+ffffff000000fffffffffffffffffff7f7f7f8f8f8060606fcfcfcfafafaffffffffffff
+fcfcfc020202ffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff0f0f0101010f3f3f3
+fbfbfbffffff000000060606000000ffffffffffffffffffffffff000000000000000000
+fffffffffffffffffffffffffffffffffffffffffffffffffcfcfcfffffffffffff5f5f5
+fffffffffffff4f4f4fffffffffffffffffff9f9f9f3f3f3fffffff1f1f1fdfdfdfcfcfc
+000000f7f7f7fffffffafafafffffff5f5f5ffffff0000000808080000000e0e0e000000
+0000000808080000000505050606060000000000000101010000000e0e0e0000000f0f0f
+0000000b0b0b000000000000020202000000000000090909060606000000050505020202
+000000050505fefefefffffffffffff1f1f1ffffff000000ffffff000000000000ffffff
+090909000000111111020202050505000000fefefefdfdfd040404000000000000ffffff
+ffffffefefeffffffff5f5f5ffffffffffffffffffffffffffffffffffffffffffffffff
+000000fffffffffffff3f3f3ffffff000000000000ffffff000000000000fffffff5f5f5
+ffffff030303f5f5f5fffffffdfdfdfffffff6f6f6ffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffefefeffffff000000ffffff
+ffffff000000000000f5f5f50c0c0c000000fffffffffffff4f4f4fcfcfc040404ffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffefefefdfdfdf2f2f2ffffff
+f9f9f9f8f8f8fffffffcfcfc000000fffffffefefeffffffe8e8e8ffffff0000000d0d0d
+0606060d0d0d000000f8f8f8fffffffafafaffffff050505000000030303000000070707
+1212120707070000000202020000000000000c0c0c000000000000000000222222000000
+0404040000000000000606060b0b0b0707070000000000000a0a0a000000060606050505
+000000f7f7f7070707000000000000fffffff1f1f1000000ffffff000000050505f0f0f0
+ebebebffffffefefef0000000505050000000303030909090b0b0b000000020202000000
+090909ffffffdededeffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffff000000020202000000000000090909000000000000030303ffffffedededffffff
+fffffff7f7f7000000ffffffeeeeeefffffffcfcfcffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffdfdfdffffff000000ffffff
+f8f8f80000001c1c1cfdfdfdfcfcfc0b0b0bfffffff5f5f5fffffffffffffffffff2f2f2
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffafafaffffffebebeb
+f8f8f8fcfcfc010101020202090909000000ffffffffffffffffff000000f7f7f7000000
+0000000000000f0f0f040404f3f3f3fffffffffffffafafa000000161616000000030303
+000000000000060606050505080808fbfbfb000000080808010101f6f6f6ffffffffffff
+fffffffafafafffffffafafaecececfffffffffffffafafaf8f8f8fffffffbfbfbf6f6f6
+0606060b0b0b040404030303090909f1f1f1f5f5f51e1e1ef0f0f0101010ffffffffffff
+121212000000ffffff1414140000000a0a0a000000000000020202050505141414040404
+000000fcfcfcfffffff4f4f4ffffffffffffffffffffffffffffffffffffffffffffffff
+efefefffffff010101090909080808000000ffffff0c0c0cf9f9f9f7f7f7f8f8f8ffffff
+fdfdfdffffff0d0d0dfffffffffffffffffffbfbfbeeeeee
+ffffffffffffffffffffffffffffffffffffffffffffffffffffff0b0b0bfffffff5f5f5
+ffffffffffffededed000000000000000000050505000000090909000000f3f3f3ffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffefefeffffff
+0a0a0a020202000000000000fafafa0e0e0eeeeeeef0f0f0ffffff000000fefefeffffff
+ffffffffffff000000000000fffffffefefef4f4f40f0f0f080808f4f4f4fcfcfcffffff
+fffffffffffff0f0f0fffffffafafafffffffffffffffffff5f5f5fffffffffffff9f9f9
+f3f3f3fafafafffffffffffffffffffffffffffffffbfbfbfbfbfbffffffffffffffffff
+000000080808000000060606090909000000ffffff000000ffffff000000050505f0f0f0
+000000ffffff000000000000000000000000000000070707000000000000040404000000
+000000090909eaeaeaffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffafafa000000fffffffafafaffffff010101000000ffffffffffff000000ffffff
+fbfbfbf4f4f4000000000000f3f3f3f0f0f0ffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffff4f4f4000000ffffffffffff
+f2f2f20000000b0b0b0101010000000c0c0c000000000000fffffffffffffefefef3f3f3
+ffffffffffffffffffffffffffffffffffffffffffffffffedededffffffeeeeee000000
+f8f8f8ffffff0303030a0a0affffff000000070707ffffff000000fffffffffffffdfdfd
+fafafaf8f8f8ffffff000000f4f4f4fefefeffffff000000000000fcfcfcfffffffefefe
+f5f5f5fdfdfdfffffff5f5f5f2f2f2fffffff1f1f1fffffffffffff5f5f5ffffffffffff
+fffffffffffff0f0f0fffffffffffff8f8f8f9f9f9ffffffffffffebebebfffffffbfbfb
+0505050000000909090000000000000e0e0effffff000000ffffff030303000000ffffff
+ffffffffffff0303030b0b0b060606060606fffffff0f0f0fffffffffffffcfcfcf9f9f9
+111111000000ffffffe4e4e4ffffffffffffffffffffffffffffffffffffffffffffffff
+fffffff3f3f3fcfcfcfefefeffffff000000060606ffffff0e0e0e000000fffffff4f4f4
+f7f7f7fffffffdfdfd191919fffffffcfcfcfdfdfdffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff080808f9f9f9fafafaffffff
+0f0f0f0000000303030d0d0d000000030303020202020202030303e8e8e8ffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff030303
+f7f7f7ffffff000000fafafaffffff0000000000000404040202020000000d0d0d000000
+010101000000eaeaea060606f5f5f5ffffffffffff000000000000fffffffefefeffffff
+fffffffffffff4f4f4fffffffffffffffffffffffffefefef0f0f0fffffff5f5f5fbfbfb
+f2f2f2fffffffcfcfcf7f7f7fcfcfcf6f6f6fdfdfdfffffffffffffffffffefefeffffff
+000000ffffff000000050505010101000000fefefe000000fefefe0000000b0b0bffffff
+fcfcfc020202000000050505040404f7f7f7fffffffffffff8f8f8000000000000ffffff
+000000000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+f4f4f4fffffffffffff8f8f8f5f5f5090909000000000000f5f5f5fffffffcfcfcf3f3f3
+fffffffffffffcfcfc000000e7e7e7fffffff6f6f6ffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff000000fffffffafafaeeeeee
+000000fffffff9f9f9f4f4f4fefefefefefefefefe000000fbfbfbffffffffffffefefef
+fffffffffffffffffffffffffffffffffffffffffffffffff3f3f3fffffffdfdfd050505
+ffffffffffff000000fffffff3f3f3ffffff060606050505040404000000ffffffffffff
+000000fffffff8f8f8000000ffffffeaeaeaffffff000000070707fbfbfbfffffff5f5f5
+0f0f0f0000000000000505050000000303030000000f0f0f0707070202020b0b0b000000
+101010000000060606020202000000111111010101000000fffffff4f4f4fffffff1f1f1
+000000080808000000000000000000040404ffffff000000ffffff070707080808f3f3f3
+f5f5f50c0c0c0808080d0d0d000000090909f4f4f4ffffffffffff000000fffffff8f8f8
+020202000000000000f8f8f8ffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffdfdfdfefefe000000fffffff1f1f1fffffffffffffcfcfcfbfbfbffffff
+f5f5f5fffffff7f7f7ffffff151515e9e9e9ffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff050505f7f7f7ffffffffffff
+020202f1f1f1fffffffcfcfcfefefefffffffafafafffffff5f5f5f9f9f9ffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffafafafffffff0f0f0000000
+fbfbfbf8f8f80a0a0afbfbfbfffffffdfdfd000000ffffff000000fffffffcfcfcffffff
+000000ffffffffffff000000f9f9f9fbfbfbfcfcfc050505090909f5f5f5ffffffffffff
+000000060606020202000000050505090909000000f7f7f7fcfcfcffffff0000000a0a0a
+f0f0f00c0c0c0000000303030000000d0d0d000000070707f9f9f9ffffffedededffffff
+000000fcfcfc060606fefefeffffff000000fffffffefefeffffff000000080808020202
+ffffffe9e9e90404040404040202020b0b0b000000000000f6f6f6fffffff2f2f2fafafa
+0b0b0b010101050505010101ffffffffffffffffffffffffffffffffffffffffffffffff
+fffffff8f8f8f9f9f9ffffff0000000000000e0e0e000000000000000000131313000000
+fffffffcfcfcffffffffffff000000fffffffbfbfbf5f5f5
+fbfbfbfffffff9f9f9fffffffcfcfcfffffff4f4f4040404fffffffffffffffffffcfcfc
+ffffff000000000000030303fefefefffffffffffff0f0f0fffffffdfdfdf3f3f3ffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffcfcfcfdfdfdfefefe000000
+000000ffffff000000fbfbfbfffffff7f7f7000000fcfcfc010101000000ffffffffffff
+010101010101000000000000000000fffffffbfbfb030303fffffffffffffefefef4f4f4
+0c0c0c000000010101ffffff010101000000fdfdfdfffffffffffffffffffffffff7f7f7
+fffffff2f2f2fafafaffffff030303ffffffffffff000000fffffff5f5f5fdfdfdffffff
+000000ffffff0e0e0ef5f5f5090909000000fffffffdfdfdffffff000000000000040404
+0000000f0f0f000000111111000000070707000000fffffffbfbfbf3f3f3ffffffffffff
+000000000000090909000000fbfbfbfffffffffffffffffff4f4f4ffffffecececffffff
+fefefefefefefffffff9f9f9fffffffefefefefefe020202040404000000fffffffbfbfb
+fbfbfbfffffffffffffcfcfc060606f4f4f4ffffffffffff
+fbfbfbfffffffffffff9f9f9fbfbfbfffffff4f4f4030303fafafafafafafffffff2f2f2
+f6f6f6ffffffffffff0000000505050000000000000b0b0bfffffff9f9f9ffffffececec
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff7f7f70f0f0ffefefe
+020202000000000000fffffff5f5f50000000a0a0a1010100000000303030a0a0af9f9f9
+020202030303080808000000000000040404f3f3f3000000ecececfffffffafafafcfcfc
+000000000000000000000000000000fcfcfcfefefef4f4f4fefefe090909000000ffffff
+0202020000000e0e0e000000fafafaf0f0f0ffffff000000f1f1f1fffffffffffff8f8f8
+090909f6f6f60000000c0c0c080808000000fffffffafafaf9f9f9040404070707000000
+0000000505050000000000000e0e0e000000060606010101080808101010fbfbfb000000
+030303000000030303010101fffffffbfbfbfffffff8f8f8fffffff3f3f3ffffffffffff
+fffffffdfdfdffffffffffffefefeffffffffefefe000000000000fbfbfbfdfdfdf8f8f8
+fffffff2f2f2ffffffffffff000000fffffffdfdfdffffff
+fffffffffffff1f1f1fffffffffffff3f3f3ffffff000000fafafaffffffefefef090909
+1717170000000c0c0cfffffffbfbfbfffffffffffffffffff0f0f0fffffffffffff9f9f9
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff5f5f5050505e7e7e7
+1d1d1d0f0f0f000000070707000000181818000000000000111111ffffffebebeb060606
+060606000000040404181818f7f7f7030303000000191919070707f6f6f6ffffffffffff
+020202000000040404fffffffffffffdfdfdffffff0b0b0b000000070707030303000000
+0101010404040000000000000d0d0d040404000000050505fefefefffffffafafaffffff
+000000ffffff000000070707000000fffffff9f9f9000000ffffff0000000000000e0e0e
+0b0b0bffffff0000000b0b0b000000000000000000070707030303000000fffffffbfbfb
+0000000000000000000a0a0a000000fffffff7f7f7fffffffdfdfdfbfbfbfffffff2f2f2
+f9f9f9fcfcfcf8f8f8ffffffffffff000000161616000000fffffffbfbfbfffffff6f6f6
+fffffff4f4f4fffffff4f4f4ffffff000000f9f9f9ffffff
+fffffff3f3f3fffffffffffffffffff7f7f7f6f6f6fbfbfbfffffffafafaffffffffffff
+f4f4f4fcfcfcfcfcfc0000000a0a0a010101000000fefefefffffffffffff8f8f8ffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffcfcfcffffff0000000b0b0b
+000000000000121212000000000000000000ffffff030303f6f6f6ffffffffffffffffff
+fcfcfcffffffe5e5e5fcfcfcffffff060606000000000000010101ffffffffffffffffff
+000000000000fffffff0f0f0fcfcfcffffff000000000000fffffff7f7f7141414000000
+f2f2f2131313fffffffefefe0000000d0d0d000000000000fcfcfcfffffff4f4f4fbfbfb
+000000f9f9f9020202020202000000f6f6f6090909010101e6e6e6191919000000f9f9f9
+f6f6f60000000d0d0d0000000303031b1b1bfffffff1f1f1ffffffffffff080808090909
+070707060606fdfdfdf3f3f3121212000000fffffffffffffffffffffffff9f9f9ffffff
+fffffffcfcfcf3f3f3ffffffececec000000f3f3f3fefefef2f2f2ffffff000000080808
+020202000000edededfffffff8f8f8070707fffffffefefe
+fefefefffffffafafaf4f4f4e9e9e9ffffffedededfffffffffffffdfdfdf6f6f6fcfcfc
+f6f6f6fffffffffffffffffff2f2f2ffffff131313fcfcfcfffffffbfbfbffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff2f2f2050505000000
+040404fcfcfc0404040b0b0b050505020202000000000000ffffffffffffffffff000000
+0000000707070707070000000d0d0d0707070000000e0e0e000000ffffffeaeaeafafafa
+010101fffffff9f9f9ffffff0202020000000f0f0f010101010101050505000000000000
+ffffffe6e6e6000000ffffffffffff0000000808080b0b0bfefefeecececfbfbfbffffff
+070707fafafaffffff0000000a0a0a000000000000fffffffdfdfd000000ffffffffffff
+ffffffffffff000000060606080808f6f6f6f2f2f2ffffffffffffffffffe9e9e9f5f5f5
+020202fffffff1f1f1ffffffffffff000000070707fefefef5f5f5ffffffffffffeeeeee
+f6f6f6fffffffffffff4f4f4ffffffffffff0000000808080b0b0b000000171717000000
+000000fffffff6f6f6ffffffffffff000000f9f9f9fcfcfc
+f6f6f6fbfbfbfffffffffffffffffff8f8f8020202fffffff9f9f9f3f3f3202020000000
+080808000000f9f9f9fdfdfdffffff050505ecececfffffffafafaf9f9f9fffffffbfbfb
+fffffffffffffffffffffffffffffffffffffffffffffffff8f8f8ffffff000000fbfbfb
+f8f8f8ffffffececec020202080808000000010101020202000000000000000000060606
+0a0a0a000000000000fdfdfdf1f1f1ffffff040404020202ffffffffffffffffffffffff
+070707f6f6f6ffffff0000000000000000000000000d0d0d0000000000000d0d0d0c0c0c
+000000101010000000000000fffffff1f1f1f1f1f1fffffffffffffffffff8f8f8f0f0f0
+000000f5f5f5ffffff000000ffffff000000000000fefefeffffff000000fffffff4f4f4
+fefefe020202000000000000fffffffcfcfcffffffefefeffbfbfbffffffffffffffffff
+fdfdfdffffffffffffececece8e8e8ffffff000000f6f6f6fcfcfcfafafaffffffffffff
+fcfcfcfffffff8f8f8fffffff7f7f7eaeaeafffffffcfcfc000000000000f6f6f6ffffff
+fffffffffffffffffff1f1f1ffffff000000ffffffffffff
+fffffffcfcfcedededfffffffbfbfbffffff060606f3f3f3fffffff2f2f2efefefffffff
+ebebeb151515111111000000000000000000fbfbfbfffffffffffffffffffffffffdfdfd
+ffffffffffffffffffffffffffffffffffffffffffffffffffffff000000fdfdfdffffff
+ffffffefefefffffff000000f7f7f7fffffffffffff5f5f5ffffff0c0c0c0000000a0a0a
+fcfcfceaeaeafffffffefefefffffff5f5f5080808000000fffffff4f4f4fffffff1f1f1
+000000040404ffffffffffff0909090000000f0f0f000000040404080808000000000000
+010101000000060606000000000000fffffffcfcfcfffffffefefef7f7f7ffffffffffff
+000000ffffffeaeaea070707fcfcfc030303080808fffffffefefe050505ffffffffffff
+fcfcfc000000151515070707f1f1f1fffffffffffffffffffffffff9f9f9fffffff5f5f5
+fffffff2f2f2ffffffffffff0909090101010d0d0d000000ffffffffffffe9e9e9ffffff
+fffffffffffff3f3f3ffffffffffffffffff0b0b0b000000000000121212000000ffffff
+f3f3f3000000fafafaffffffffffffffffff000000eaeaea
+fafafafefefefffffffafafafbfbfbffffff000000fffffff5f5f5ffffff060606000000
+080808030303000000080808fdfdfdfafafafffffffffffff3f3f3fffffffcfcfcffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffcfcfc000000f9f9f9ffffff
+000000080808fbfbfb020202000000000000fffffff4f4f4ffffff000000050505f8f8f8
+fffffffffffffbfbfb020202000000ffffff000000050505000000ffffffffffffffffff
+000000060606000000fbfbfb0000000b0b0b0000000000000c0c0cfcfcfc000000101010
+000000070707000000060606050505eeeeeefffffffffffffffffffdfdfdfffffffafafa
+030303f7f7f7ffffff000000ffffff000000000000fffffff7f7f7000000030303000000
+ffffff030303000000fffffffffffffffffffdfdfd000000f7f7f7ffffffecececffffff
+fffffffefefefefefefdfdfd000000010101000000060606fffffffffffffffffffcfcfc
+f8f8f8fffffff6f6f6fffffff6f6f6f9f9f9fdfdfdfdfdfdf9f9f9010101050505000000
+101010070707000000fffffff6f6f6ffffff000000ffffff
+fffffffcfcfcfffffffffffffbfbfbf9f9f9080808fcfcfcfffffff0f0f0ffffffffffff
+ffffff020202000000090909020202000000f3f3f3fffffffffffffefefefffffff8f8f8
+fcfcfcfffffff7f7f7fffffffcfcfcf7f7f7fffffff8f8f8030303121212eeeeeef8f8f8
+080808000000101010000000040404000000eeeeeefffffff9f9f9010101010101000000
+ffffff000000000000030303000000020202000000000000000000fffffffcfcfcefefef
+fffffffffffff9f9f9080808fffffff8f8f80a0a0a000000010101000000000000000000
+ffffff000000000000ffffffffffff000000030303000000fffffff0f0f0fdfdfdffffff
+000000ffffffffffff010101fafafa040404090909fafafaffffff000000fdfdfdffffff
+ffffff000000010101fffffffafafaf7f7f7111111000000fffffffdfdfdf6f6f6ffffff
+fffffffffffffbfbfbffffffffffffffffff000000050505f9f9f9ffffffffffffffffff
+f8f8f8fffffffefefefffffffffffff8f8f8020202000000000000040404030303f6f6f6
+fffffffffffff5f5f5fffffffafafaffffff000000ffffff
+fafafafffffffcfcfcf5f5f5ffffff030303fcfcfcf8f8f8f6f6f6080808ffffffe9e9e9
+fffffff9f9f9f9f9f9f7f7f7ffffff080808fffffffffffff8f8f8fffffff1f1f1ffffff
+fafafafffffffffffff6f6f6f7f7f7ffffffffffffffffff000000ecececffffffffffff
+0000000e0e0e000000fffffffcfcfc0d0d0d0d0d0d0d0d0df2f2f2fefefe060606ffffff
+0000000000000b0b0bf7f7f7000000000000111111050505050505f5f5f5ffffffffffff
+ffffff000000ffffff000000fcfcfcfffffff5f5f50000000707070c0c0c101010000000
+030303080808fafafaffffff000000020202000000000000eaeaeaffffffffffffffffff
+000000fffffff8f8f8000000030303000000000000000000ffffff040404ffffff000000
+000000000000020202000000ffffffffffff000000ffffffffffffffffffffffffffffff
+eeeeeef6f6f60a0a0a000000f2f2f2f9f9f9ffffff000000000000fffffff4f4f4f8f8f8
+fdfdfdfffffff4f4f4fffffff8f8f8fefefeffffff040404fdfdfdfffffff4f4f4ffffff
+fffffffbfbfbfffffffbfbfbffffffeeeeee141414f2f2f2
+fffffffffffffffffffbfbfbf5f5f5000000ffffffffffffffffff000000fcfcfcffffff
+000000fffffffbfbfbffffff000000fbfbfbfffffffcfcfcfffffffafafafefefefcfcfc
+fffffff8f8f8fafafafbfbfbffffffffffffedededfdfdfd090909fffffffffffff8f8f8
+010101000000030303fbfbfbfafafafcfcfcefefefffffff141414fefefef0f0f0000000
+0000000b0b0b000000ffffffffffff080808000000020202000000ffffffe6e6e6ffffff
+000000000000000000000000030303000000fffffffbfbfb000000000000000000000000
+000000f9f9f9ffffff000000050505090909060606080808ffffffffffffffffffffffff
+000000ffffff0101010505050000000000000a0a0a010101fdfdfd000000fbfbfbffffff
+0e0e0e0000000505050404040000000505050b0b0b000000000000fafafafdfdfd010101
+000000181818000000070707ffffffffffffefefef080808000000ffffffffffffffffff
+fefefef8f8f8fffffff2f2f2ffffffffffffe3e3e3fefefefffffffcfcfc090909010101
+000000060606000000ffffffffffffffffff000000ffffff
+fafafafffffffffffff6f6f6ffffff101010e5e5e5fffffff6f6f60d0d0df6f6f6fdfdfd
+fffffffefefeffffffececec070707f4f4f4fffffff8f8f8f9f9f9fffffffffffffbfbfb
+fefefefdfdfdfffffffffffffafafaf4f4f4ffffffffffff000000fdfdfdffffff000000
+0606060a0a0a000000ffffff000000ffffffffffffececec000000ffffffffffff0f0f0f
+111111f4f4f4fffffff6f6f6030303000000111111000000020202fffffff7f7f7f6f6f6
+0c0c0c0000000f0f0f000000000000000000000000ffffffffffffffffff000000ffffff
+fffffff8f8f8ffffffebebebffffff000000030303000000f9f9f9fffffff2f2f2ffffff
+0000000a0a0af9f9f9fafafafdfdfdf3f3f3000000020202ffffffffffffffffff000000
+0000000707070000000606060000000000000a0a0a000000010101111111010101080808
+000000000000111111000000000000eaeaeaffffff050505000000ffffffe7e7e7ffffff
+fbfbfbfffffff4f4f4fffffff1f1f1ffffffffffff0a0a0a0000000000000000000a0a0a
+fffffff2f2f2ffffff000000eeeeeeffffffffffff010101
+fcfcfcfcfcfcfffffffefefeffffff000000fffffffefefefdfdfd080808000000000000
+0a0a0a0000000000000f0f0f080808fdfdfdf3f3f3f6f6f6fffffffefefef7f7f7ffffff
+fdfdfdfffffff6f6f6fcfcfcffffffffffffeeeeee000000fffffffefefef3f3f3020202
+fdfdfdeeeeeefffffff3f3f3040404fefefef9f9f9ffffff060606050505000000000000
+000000fcfcfcffffff000000f6f6f6ffffffffffff000000f6f6f6fdfdfdffffffffffff
+0000000000000000000c0c0c0000000e0e0e000000050505ffffffe9e9e9ffffffffffff
+ffffff0000000000000b0b0b000000090909ffffff000000ffffffecececfffffffcfcfc
+ffffff000000000000fffffffffffff5f5f5000000ffffffe2e2e2fffffffdfdfd000000
+010101050505ffffff000000000000fdfdfd040404080808000000000000000000010101
+0404040e0e0e000000fcfcfcf7f7f71b1b1b020202000000000000fefefeffffffffffff
+fffffff7f7f7fffffff7f7f7ffffffebebebffffff000000ffffffffffffffffff020202
+fffffff4f4f4fefefe000000ffffffecececfefefe000000
+fffffff8f8f8fffffffffffff3f3f3000000fffffffcfcfcfefefefefefe020202111111
+000000000000080808000000000000ffffffffffffffffffedededfffffffbfbfbfefefe
+f6f6f6fffffffffffffffffff1f1f1ffffffffffff010101f9f9f9efefefffffff0e0e0e
+ffffff000000090909000000000000fffffff4f4f40b0b0b0000000000000f0f0f0e0e0e
+ffffffededed0606060b0b0bffffffffffffebebeb040404fcfcfcfffffff4f4f4ffffff
+000000070707070707f3f3f30000000d0d0d000000ffffff000000000000080808000000
+000000000000171717010101000000030303f0f0f0fffffff7f7f7fffffffffffffbfbfb
+f4f4f4ffffff000000010101060606f1f1f1fffffff1f1f1ffffff0505050000000b0b0b
+020202000000eeeeee121212080808fdfdfd0909090000000c0c0c0000000c0c0c020202
+050505000000000000ffffff000000000000000000080808000000f4f4f4fffffffbfbfb
+f8f8f8fdfdfdfffffffcfcfcfffffff7f7f7efefef151515fefefef4f4f4fefefe010101
+fffffffffffff7f7f7fffffffffffffcfcfcffffff070707
+fefefefffffff7f7f7f8f8f8ffffff000000ffffffeeeeee070707040404000000050505
+000000f4f4f4fbfbfbfffffff8f8f8ffffffeaeaeaf8f8f8ffffffefefefffffffffffff
+fffffffbfbfbf5f5f5fffffffffffffbfbfbfcfcfc000000fffffffbfbfbffffffe5e5e5
+000000010101000000f8f8f8ffffff000000ffffff030303000000ffffff161616ebebeb
+f9f9f9ffffff040404f0f0f0fdfdfdfafafa070707000000fffffffdfdfdffffffffffff
+0000000505050000000c0c0c0808080000000000000404040000000000000d0d0d000000
+0000000a0a0a000000050505000000040404060606f7f7f7090909000000000000040404
+000000f9f9f9ffffff030303000000fffffff1f1f1ffffffffffff0000000a0a0a000000
+ffffff070707ffffffffffffeaeaeaffffff0000000a0a0a000000000000000000030303
+0000000505050b0b0b000000050505090909070707000000000000fffffff5f5f5f7f7f7
+fffffffffffff5f5f5fcfcfcf2f2f2ffffffffffffeeeeeefffffffdfdfdfffffff7f7f7
+f5f5f5f0f0f0fafafa0c0c0cf3f3f3f9f9f9ffffff000000
+fdfdfdf5f5f5ffffffffffffededed0a0a0afdfdfdffffff000000fffffffffffffafafa
+0a0a0afffffffffffff7f7f7fffffff5f5f5ffffffffffffe9e9e9fffffffefefef7f7f7
+fffffffffffffffffff6f6f6fffffffffffff9f9f9060606000000060606000000fefefe
+ffffff000000000000fefefefdfdfd060606000000020202ffffff020202f1f1f1ffffff
+ffffff040404ffffffffffffffffff0000001c1c1c000000000000fefefefefefeffffff
+fffffff7f7f7fffffff9f9f9f7f7f7ffffff000000f0f0f0ffffff050505000000ffffff
+f8f8f8fffffffffffff7f7f7fffffffffffffcfcfc000000f6f6f6ffffffffffff030303
+020202000000000000fbfbfb050505000000fffffff8f8f8000000ffffff000000030303
+fbfbfbfffffffbfbfb000000ffffffffffff0000000404040d0d0d0000000d0d0d000000
+fefefeffffffffffff000000000000000000000000070707000000fffffff9f9f9ffffff
+fffffffdfdfdfffffffffffffffffff2f2f2fffffffdfdfd000000000000000000030303
+010101010101141414000000fffffff8f8f8ffffff000000
+fdfdfdfffffff8f8f8fffffff9f9f9030303fffffff7f7f7000000020202000000040404
+0000000e0e0e0000000707070a0a0af2f2f2fffffffffffffffffff1f1f1ffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff0000000d0d0d000000000000
+0d0d0d000000020202fcfcfc020202000000050505fafafa000000fffffff9f9f9fbfbfb
+0b0b0b0000000505050000000a0a0a000000010101000000030303fdfdfdfefefeffffff
+f9f9f9fffffffffffffcfcfc040404010101f7f7f7ffffff040404010101070707000000
+060606fcfcfcfefefefbfbfbf7f7f7ffffff0303030000000a0a0af0f0f0ffffff000000
+0303030000000404040202020a0a0a000000ffffff000000030303ffffff000000fefefe
+fffffff4f4f4ffffffffffffeeeeeeffffff000000000000060606000000000000fdfdfd
+fffffffffffffdfdfdffffff030303000000000000020202060606fefefefbfbfbffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffdfdfdfbfbfb010101
+000000000000fffffffcfcfcfefefefffffffcfcfc040404
+fffffff3f3f3f8f8f8fffffffafafa000000fdfdfdfdfdfdfdfdfdffffffffffffffffff
+f5f5f5f1f1f1ffffffecececf6f6f6fffffffefefeecececfcfcfcfffffffffffff5f5f5
+ffffffffffffffffffffffffffffffffffffffffffffffff000000010101030303000000
+0000000b0b0b000000050505121212000000ffffffffffff000000f7f7f7ffffff070707
+000000fdfdfd0707070000000101010a0a0a000000000000000000f9f9f9ffffffffffff
+f7f7f7fffffffbfbfb060606000000fcfcfcffffff000000fffffff9f9f9000000040404
+0000000808080202020707070000000b0b0bedededfefefe000000131313ffffffffffff
+0000001010100000000d0d0d0000000a0a0affffff030303020202070707000000ffffff
+e9e9e9ffffff000000ffffffffffffffffff050505000000000000000000ffffffffffff
+e9e9e9fffffffffffff0f0f0010101000000030303070707eaeaeaffffffffffffececec
+fffffffffffffffffffffffffffffffffffffffffffffffff3f3f3ffffff040404000000
+fffffffffffff2f2f2fcfcfcfefefefffffffcfcfc040404
+f6f6f6fffffffffffffdfdfdfdfdfdfffffff7f7f7ffffff030303000000000000000000
+070707010101070707020202fffffffffffffbfbfbfffffffffffff9f9f9ecececffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff7f7f7ffffffffffff
+000000000000101010000000000000fffffffbfbfb000000ffffffffffff0f0f0f000000
+ffffffffffffffffff0000000000000000000e0e0e0000000000000d0d0d000000000000
+0e0e0e000000000000000000ffffffe9e9e90a0a0a000000000000060606030303000000
+040404000000040404000000000000000000191919fbfbfb000000000000000000000000
+040404000000000000000000040404000000000000060606fffffff7f7f7020202000000
+0a0a0afffffffcfcfcffffff0000000000000000001a1a1affffff040404fbfbfbfcfcfc
+ffffffffffffebebebffffff060606000000ffffff0c0c0cfefefefffffff3f3f3ffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff0b0b0b000000000000090909
+0000000000000000000c0c0cfefefefffffffcfcfc040404
+ffffffedededfafafafffffff5f5f5fffffff7f7f7fdfdfdfffffffffffff9f9f9ffffff
+fbfbfbffffffe1e1e1ffffff000000fffffffffffffbfbfbfdfdfdf8f8f8fffffffefefe
+ffffffffffffffffffffffffffffffffffffffffffffffff000000fffffffafafaffffff
+0c0c0c000000040404090909fffffffbfbfb111111000000f7f7f7ffffff000000ffffff
+fbfbfbf6f6f6f9f9f9ffffff010101000000fffffff9f9f9fdfdfdfcfcfcf6f6f6111111
+ffffff000000000000ffffffffffff040404010101fafafafffffffefefe000000080808
+000000010101000000121212000000090909f1f1f1ffffff000000080808000000fdfdfd
+0a0a0a0b0b0b030303040404030303000000ffffffededed040404fffffff7f7f7121212
+f9f9f90000000000000000000d0d0d000000ffffff000000000000000000fffffffefefe
+fafafaefefeffffffffdfdfd000000000000f3f3f3000000fffffffffffffffffff8f8f8
+fffffffffffffffffffffffffffffffffffffffffffffffff5f5f5fdfdfdffffffffffff
+fefefeffffffffffff000000fefefefffffffcfcfc040404
+f7f7f7fffffffbfbfbffffff010101e8e8e8fffffff3f3f3f9f9f9fffffffefefef2f2f2
+fffffff9f9f9fffffff9f9f9000000ffffffe8e8e8f7f7f7fffffffefefeffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff070707fdfdfdfffffff1f1f1
+0b0b0b000000030303f7f7f7fcfcfcffffff000000f9f9f9ffffff0808080c0c0cf7f7f7
+fffffffffffffffffff7f7f7ffffff000000fffffffafafa000000000000fffffff7f7f7
+000000fffffffafafaf4f4f4fafafa000000fffffff7f7f7ffffffffffff000000000000
+fafafa1a1a1a030303ebebeb040404000000fffffffefefe131313000000ffffffffffff
+000000070707000000060606000000ffffffffffffffffff000000fefefefefefe000000
+030303020202000000111111000000000000ffffff000000ffffff080808ffffffffffff
+f7f7f7f7f7f7fffffff5f5f5ffffffffffffffffff020202fffffff8f8f8fffffff4f4f4
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffefefeebebebffffff
+fefefefbfbfbffffff000000fefefefffffffcfcfc040404
+fffffffffffff9f9f9f8f8f8f6f6f6fffffff7f7f7fefefeeaeaeafffffff7f7f7ffffff
+fffffffefefe000000000000000000e8e8e8ffffffffffffedededfffffffffffff8f8f8
+ffffffffffffffffffffffffffffffffffffffffffffffff080808f6f6f6ffffffffffff
+000000101010000000fffffffcfcfc151515f3f3f3fcfcfcf8f8f8000000fdfdfdffffff
+fbfbfbffffffedededfffffff1f1f1000000ffffff0000000b0b0b000000040404000000
+060606fefefefffffffafafaffffff0b0b0bf6f6f6ffffff000000000000000000070707
+0e0e0e000000fffffffffffff6f6f6060606fefefef8f8f80000000e0e0ef6f6f6000000
+1818180000000d0d0d000000050505fdfdfd000000ffffff000000050505ffffff030303
+000000010101ffffff000000000000fffffff3f3f3010101ffffff000000070707fcfcfc
+ffffffffffffe0e0e0fffffffefefefbfbfbffffff000000ecececfffffffafafaffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff000000010101020202000000
+0505050000000d0d0d0b0b0bfefefefffffffcfcfc040404
+f5f5f5f3f3f3ffffffffffffffffff000000ffffffffffff171717000000000000000000
+000000020202fffffff8f8f8fffffffffffff6f6f6fffffffdfdfdfffffffffffffcfcfc
+ffffffffffffffffffffffffffffffffffffffffffffffff000000fffffff4f4f4ffffff
+0c0c0c000000060606000000010101000000fffffffffffff5f5f5080808fffffff5f5f5
+fefefefffffffffffff8f8f8ffffff040404000000fffffff8f8f8ffffffffffff000000
+fffffff4f4f4f6f6f6ffffffeeeeee1a1a1afbfbfbf1f1f1020202ffffff000000030303
+000000ffffff000000fffffff3f3f3060606000000ffffff030303000000000000050505
+ffffff000000000000020202060606000000fafafaffffff000000000000040404000000
+0c0c0cf0f0f0fffffffefefe000000000000ffffffffffff000000ffffff000000000000
+000000020202020202060606fcfcfcffffffe5e5e5111111fffffffafafafdfdfdf8f8f8
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffbfbfbf7f7f7
+ffffffffffffe6e6e6060606fefefefffffffcfcfc040404
+fcfcfcfffffffffffffafafaffffff000000fdfdfdfffffff4f4f4fffffffffffffafafa
+fffffffefefeececec0c0c0cfbfbfbfffffffffffff7f7f7fdfdfdf0f0f0fffffffbfbfb
+ffffffffffffffffffffffffffffffffffffffffffffffff020202ffffffffffff000000
+000000010101000000060606000000fffffffdfdfdf0f0f0fffffff7f7f7f0f0f0ffffff
+fffffff9f9f9050505ffffff050505000000050505fefefe101010e5e5e50e0e0e000000
+f5f5f5ffffff070707fefefeffffff000000050505ffffff010101000000ffffff000000
+060606fbfbfbfffffffffffffdfdfd050505000000040404090909000000000000ffffff
+f3f3f3080808010101000000000000060606ffffff000000050505ffffff000000020202
+f8f8f8fffffff6f6f6ffffff000000fffffffffffff9f9f9000000ffffffffffff040404
+000000000000080808000000060606fdfdfdffffff000000f9f9f9fffffff4f4f4ffffff
+fffffffffffffffffffffffffffffffffffffffffffffffff6f6f6080808000000060606
+000000fdfdfdffffff000000fefefefffffffcfcfc040404
+fffffffffffffbfbfbffffffffffff0e0e0efbfbfbfcfcfcffffff000000ffffffffffff
+f6f6f60000000b0b0b000000000000fffffff2f2f2fbfbfbfffffffffffff6f6f6ffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff0a0a0afffffff2f2f2141414
+f0f0f0050505000000000000fffffff8f8f8fcfcfcfbfbfbfcfcfcfffffff4f4f4ffffff
+fffffffcfcfc000000ffffff0000000b0b0b010101000000000000070707080808f8f8f8
+fffffff7f7f7040404fdfdfd0000000d0d0d000000f9f9f90f0f0f070707f4f4f4000000
+000000fffffff7f7f7ffffffffffff000000080808000000050505000000090909fcfcfc
+ffffff0000000101010000000000000b0b0bf7f7f7111111000000fafafa000000030303
+fafafafffffffdfdfdfefefe020202fdfdfdfffffff5f5f50a0a0af7f7f7040404000000
+0000000a0a0afafafaffffff0000000c0c0c000000010101fffffff7f7f7fdfdfdfdfdfd
+f6f6f6fffffffafafafffffffffffff9f9f9fffffffbfbfb030303000000000000000000
+000000020202050505f3f3f3fbfbfbfffffffbfbfb040404
+f0f0f0ffffffffffffffffffe8e8e8090909f2f2f2ffffff000000f8f8f8fdfdfdffffff
+070707f9f9f9ffffffefefef080808e4e4e4fffffffffffffcfcfcfffffff7f7f7ffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff000000000000070707efefef
+ffffffffffff0c0c0c020202fffffffffffffffffffafafa000000e7e7e7fffffffbfbfb
+fcfcfcffffff070707f9f9f9010101000000000000121212070707000000000000f6f6f6
+f8f8f8060606fdfdfdffffff000000ffffff000000090909000000efefef111111000000
+0707070606060606060b0b0b0000000000000505050404040202020f0f0f0000000a0a0a
+e7e7e7000000050505fcfcfc000000020202050505000000fefefe1c1c1c000000ffffff
+ffffffefefeff7f7f7ffffff000000f8f8f8fefefeffffff000000ffffff030303050505
+151515000000fffffff8f8f8f9f9f9070707000000fffffff6f6f6fefefefffffff4f4f4
+fffffff6f6f6fafafaffffffe9e9e9ffffffeaeaea040404eaeaeafffffffefefeffffff
+fffffffbfbfbfcfcfc101010fffffff1f1f1ffffff000000
+fffffffffffff6f6f6ffffffffffff000000fffffffdfdfdffffff040404000000000000
+060606fffffff1f1f10d0d0d020202fffffffbfbfbefefeffffffff8f8f8ffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff030303010101ffffffffffff
+fefefefffffff1f1f1000000000000f5f5f5fdfdfdffffff121212fffffffffffffafafa
+fcfcfcf4f4f40a0a0a0000000101010c0c0c000000000000000000000000ffffffffffff
+f8f8f8000000fdfdfdf6f6f6000000ffffffffffff000000000000111111000000020202
+0000000303030000000000001c1c1c060606050505000000000000000000000000ffffff
+ffffff010101000000ffffff0a0a0a000000000000fffffff4f4f4000000fffffffdfdfd
+fcfcfcffffffffffff000000080808080808fcfcfcffffff050505ffffff000000000000
+000000030303efefeffffffffcfcfcfbfbfb141414fbfbfbfffffff6f6f6f7f7f7ffffff
+f1f1f1fffffffbfbfbfdfdfdfffffffafafaffffffffffff0b0b0bffffffe8e8e8fdfdfd
+f7f7f7ffffffffffff000000fefefefffffff2f2f2171717
+f9f9f9fffffffcfcfcffffffffffff000000fffffffdfdfdebebebffffffffffffffffff
+f2f2f2fffffffffffffffffff7f7f7fffffff9f9f9fffffffdfdfdfefefef1f1f1ffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff000000090909fffffff0f0f0
+fafafafafafafffffffffffffcfcfc151515000000000000000000f9f9f9ecececffffff
+ffffffffffff000000ffffff000000010101070707070707181818000000f9f9f9fdfdfd
+ffffff040404fcfcfcffffff060606f2f2f2e9e9e9ffffff000000050505ffffff000000
+0303030000000e0e0e000000000000020202000000fffffffffffff7f7f7fffffff5f5f5
+f5f5f5ffffff000000fdfdfdffffff000000171717fafafa131313000000fbfbfbffffff
+fffffff4f4f4ffffff0000000c0c0c070707fefefefafafa080808ffffff020202030303
+0e0e0e000000ffffffebebebf7f7f7ffffff000000f7f7f7f5f5f5fffffffefefef2f2f2
+fffffffffffff4f4f4fffffffffffff5f5f5fafafaf5f5f5000000000000131313000000
+020202020202060606080808fefefefffffff2f2f20e0e0e
+fcfcfcfffffffffffffdfdfdeeeeee1e1e1ef7f7f7ffffffffffffffffffedededffffff
+020202000000fffffff1f1f1ffffffebebebfffffffdfdfdfffffffdfdfdfefefef9f9f9
+ffffffffffffffffffffffffffffffffffffffffffffffff000000f5f5f5fffffff8f8f8
+fafafafffffffafafa000000fefefef8f8f8ffffff0000000d0d0dfafafafffffffefefe
+ffffff000000ffffffffffff000000f8f8f80e0e0e000000000000080808fffffff2f2f2
+000000fdfdfdfffffff8f8f8000000fffffffffffffafafa000000050505f5f5f5101010
+ffffffefefefffffffffffff040404000000141414fcfcfcfffffffffffffffffffdfdfd
+ffffff000000000000fffffffbfbfb111111000000ffffff000000020202ffffffededed
+fdfdfdfefefeffffffffffffe9e9e9020202eeeeee0d0d0d000000ececec0707070f0f0f
+000000060606020202ffffffffffffffffff000000ffffffffffffeaeaeafffffffdfdfd
+fffffff5f5f5ffffffffffffe6e6e6fcfcfcfffffff8f8f8ffffffffffff000000090909
+020202000000000000fefefefffffff4f4f4ffffff000000
+fffffffffffff5f5f5fdfdfdffffff000000fffffffffffff7f7f7fffffffffffffbfbfb
+000000030303f2f2f2fffffffdfdfd030303fcfcfcffffffeeeeeefffffffdfdfdfcfcfc
+ffffffffffffffffffffffffffffffffffffffffffffffff0c0c0ce7e7e7ffffffffffff
+fffffffefefefcfcfc0b0b0bfffffff6f6f6f5f5f5ffffffffffffeeeeeefffffff7f7f7
+ffffff000000f1f1f1ffffff000000000000040404000000000000eeeeeeffffffffffff
+020202ffffffffffff030303fffffffffffffcfcfcffffff000000080808010101000000
+000000121212000000f4f4f4000000080808fafafafbfbfbf8f8f8ffffffe7e7e7ffffff
+ffffffeeeeee0d0d0dfbfbfbffffff0000000000000b0b0b131313fefefefbfbfbffffff
+000000020202000000ffffffffffff0505050000000000000000000b0b0bffffff000000
+161616000000000000fffffff9f9f9edededffffff000000050505fdfdfdfdfdfdffffff
+f9f9f9fffffff6f6f6fafafaffffffffffffecececfefefefdfdfd0000000b0b0bffffff
+ecececfffffffffffffbfbfbf6f6f6fffffffafafaf8f8f8
+efefeffbfbfbfdfdfdfffffffcfcfc070707f8f8f8ffffffeaeaeafffffff7f7f7ffffff
+edededffffffffffff000000010101010101f6f6f6fffffffafafaf9f9f9fafafaffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff000000ffffff000000f9f9f9
+fbfbfbf7f7f7fefefe000000f7f7f7ffffffffffffefefeffdfdfdfffffffcfcfcffffff
+f4f4f4000000ffffffffffff0000000000000a0a0a000000000000fffffff7f7f7f3f3f3
+0d0d0dfbfbfbf4f4f4000000f9f9f9ffffffffffffffffffffffff0000000d0d0dffffff
+ffffff000000000000090909131313000000fffffffffffffefefefafafafffffffdfdfd
+fdfdfdffffff000000ffffffffffff0000000b0b0b000000eeeeeefffffffffffff9f9f9
+010101060606000000fefefeefefef000000ffffff000000000000000000ffffff000000
+030303000000111111000000fffffffefefe000000000000000000fafafafffffff9f9f9
+f9f9f9fffffffffffff6f6f6f0f0f0fdfdfdffffffffffffffffff000000000000ffffff
+fffffffffffff3f3f3fffffffffffff8f8f8000000fbfbfb
+fffffff0f0f0fffffffffffff2f2f2fffffffffffffefefefffffff7f7f7fafafafdfdfd
+ffffff000000000000040404f9f9f9fffffffefefefffffffffffffffffff3f3f3ffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffdfdfd
+ffffffffffffffffff060606fafafafffffff2f2f2fffffffefefe000000000000ffffff
+ffffff000000fcfcfcf3f3f3ffffff050505000000070707fffffff7f7f7f8f8f8ffffff
+000000ffffffffffff000000fffffffffffffffffff2f2f2fefefe121212000000fcfcfc
+ffffff000000101010000000000000fcfcfcf8f8f8fffffffefefefffffff7f7f7ffffff
+fefefefefefe010101fffffff7f7f70b0b0b020202000000fffffffffffffffffffefefe
+040404000000090909fafafafcfcfcfffffff2f2f2ffffffffffff000000ffffff000000
+fefefe0f0f0feaeaea0b0b0b0000000000000000000505050a0a0a010101f5f5f5ffffff
+fffffff7f7f7f6f6f6fdfdfdfffffffffffffcfcfcfffffff9f9f9fffffffbfbfbf9f9f9
+fffffff4f4f4fffffffffffffafafafbfbfb040404fefefe
+fffffffdfdfdfffffffffffffffffff5f5f50a0a0af7f7f7fffffffffffff4f4f40b0b0b
+000000010101000000040404fefefefefefefefefef5f5f5fffffffffffff4f4f4fafafa
+ffffffffffffffffffffffffffffffffffffffffffffffff000000fffffffffffff8f8f8
+fffffffefefefdfdfd0a0a0a000000fcfcfcfbfbfbfefefeffffffffffff020202fafafa
+fbfbfb000000ffffffffffff000000000000030303020202fffffffefefefcfcfc010101
+000000fafafa010101000000fdfdfdfbfbfbfffffff7f7f7ffffff030303000000ffffff
+f6f6f60e0e0e000000050505030303ffffffedededfffffffcfcfcfffffff7f7f7f9f9f9
+f2f2f2181818ebebebffffffffffff000000050505020202ffffffffffffffffff000000
+000000050505fbfbfbffffffffffffefefeffffffffffffff7f7f70c0c0cf2f2f2070707
+0000000000000e0e0e000000060606000000000000030303ffffffefefeffffffffbfbfb
+fffffff2f2f2fefefefffffffffffff7f7f7070707040404fffffff9f9f9ffffffffffff
+f8f8f8f9f9f9fffffff4f4f4fffffff5f5f5070707ffffff
+fffffffffffff3f3f3fffffffcfcfcf9f9f9191919ffffffffffffffffff000000000000
+0b0b0b000000040404000000060606020202000000fffffffffffff5f5f5ffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff161616000000000000ffffff
+ebebebfffffffdfdfd000000000000ffffffffffffffffffffffffe8e8e8040404ffffff
+ffffff0d0d0d0000000000001b1b1b000000000000fafafaf5f5f5fffffffffffff9f9f9
+ffffffffffff000000000000fffffff1f1f1fffffffffffff2f2f2000000050505000000
+060606000000101010030303000000f4f4f4fffffffffffffffffffbfbfbffffffffffff
+ffffffe6e6e6fffffffbfbfbf4f4f4040404000000000000f6f6f6ffffff000000060606
+0a0a0a000000fffffff6f6f6f9f9f90c0c0cfffffff8f8f8ffffff000000fffffffcfcfc
+101010040404000000ffffff000000060606fffffffcfcfcf0f0f0fffffffffffff2f2f2
+f9f9f9fffffff9f9f9f6f6f6fffffff9f9f9000000fbfbfbfbfbfbffffff000000090909
+000000020202fffffffffffffbfbfbf9f9f9060606f4f4f4
+fdfdfdfefefeffffffeeeeeeffffffffffff000000fffffff3f3f3fafafaf8f8f8ffffff
+ffffffe7e7e7fffffffafafaf0f0f0070707000000f5f5f5ffffffffffffedededffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff000000000000000000f8f8f8
+fffffff8f8f8fdfdfdffffff030303f3f3f3ffffffebebebffffffffffff000000030303
+f0f0f0070707000000060606000000000000ffffffffffffffffffedededfefefe121212
+f6f6f6fafafa070707000000f8f8f8ffffffedededf9f9f9ffffff000000ffffff0f0f0f
+040404f8f8f8040404000000000000fffffffffffff8f8f8fffffff1f1f1fffffffafafa
+f7f7f7fffffff3f3f3000000ffffff0000000101010707070000000000000e0e0e000000
+000000000000fffffff5f5f5fffffffdfdfdf1f1f1fffffffbfbfb040404fffffff3f3f3
+111111000000060606000000030303fffffff1f1f1f9f9f9ffffffebebebffffffffffff
+f7f7f7fdfdfdfffffff6f6f6fffffffffffff7f7f70d0d0d0000000000000c0c0cfcfcfc
+fffffff2f2f2f7f7f7fffffffffffff7f7f7010101ffffff
+fffffff8f8f8fffffff3f3f3fffffff9f9f9121212fbfbfbfffffffffffff8f8f8fafafa
+fafafafffffff6f6f6ffffffffffffffffff000000fffffffffffff4f4f4ffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff000000ffffff080808ffffff
+f7f7f7fffffffffffff5f5f5000000fdfdfdf6f6f6fffffff1f1f1f6f6f60b0b0b000000
+ffffffebebeb000000070707020202000000fffffff3f3f3fffffff7f7f70a0a0a000000
+fafafaffffff000000050505fefefefafafafffffffffffffcfcfc060606fafafaf8f8f8
+000000ffffff000000000000090909080808000000fffffffffffff6f6f6fffffff1f1f1
+fffffffefefeebebeb171717efefefffffff060606000000000000030303000000f9f9f9
+040404070707000000fffffff1f1f1fefefeffffffebebebffffff080808fffffff4f4f4
+000000ffffff000000080808010101f3f3f3fffffffefefefcfcfcffffffefefeff4f4f4
+fffffffefefefffffff1f1f1fcfcfcefefef0e0e0ef1f1f1fffffffffffffffffff9f9f9
+0000001c1c1cf0f0f0fbfbfbfdfdfd000000fffffff0f0f0
+fffffff8f8f8ecececfffffffdfdfdfdfdfdfffffff3f3f3fafafaf5f5f5fffffff3f3f3
+fffffffbfbfbf6f6f6ffffffefefefffffff000000fffffff8f8f8f6f6f6ffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff090909eeeeee000000f6f6f6
+fffffff9f9f9fcfcfcffffff010101fffffff8f8f8f4f4f4ffffffffffff000000080808
+efefef060606090909000000040404000000000000020202000000fdfdfd090909f1f1f1
+ffffffeeeeee070707070707020202ffffff060606efefeffafafa020202f5f5f5ffffff
+0f0f0f000000151515000000000000ffffff0000000b0b0b000000000000000000060606
+0404040f0f0f000000000000fffffff8f8f8090909000000060606ffffff000000161616
+000000030303000000fffffff7f7f7fffffffffffffffffff9f9f9000000fffffffcfcfc
+fffffffafafa000000050505000000fffffffffffff5f5f5f6f6f6fbfbfbf7f7f7ffffff
+ffffffe9e9e9f3f3f3fffffffffffffffffffffffff6f6f6f8f8f8f9f9f9fdfdfdffffff
+fafafafefefefbfbfbfffffffefefe000000ffffffffffff
+f4f4f4fefefeffffffffffffffffffefefeffdfdfd050505fdfdfdf8f8f8ffffffffffff
+f5f5f5fdfdfdfffffff4f4f40e0e0e000000040404020202fffffffcfcfcfbfbfbfbfbfb
+fffffffffffffffffffffffffffffffffffffffffffffffffbfbfb0000000a0a0affffff
+fffffff5f5f5ffffffffffff0000000e0e0effffff0c0c0cf7f7f7f2f2f2000000000000
+ffffffffffff141414000000080808040404070707000000f9f9f9ffffff000000000000
+1212120000000f0f0f000000fafafaffffff030303fffffff7f7f7ffffff020202ffffff
+000000080808000000090909fffffffffffffffffffefefe0000000d0d0dfbfbfbf2f2f2
+ffffff000000040404030303fcfcfcffffff0000000909090000000000000e0e0e000000
+020202000000000000fffffffffffffffffff3f3f3f3f3f3ffffff0c0c0c020202040404
+fefefe000000101010000000050505f6f6f6fcfcfcfffffffffffffffffffffffff2f2f2
+fffffffffffffafafaf6f6f6fbfbfbf9f9f9f0f0f0fffffffffffffffffffffffff6f6f6
+fbfbfbf8f8f8ffffffffffffffffff010101fffffff7f7f7
+ffffffffffffffffffe6e6e6fffffffffffff7f7f7020202fffffff7f7f7f7f7f7fcfcfc
+ffffff000000000000030303020202fbfbfbfffffffdfdfdf5f5f5f1f1f1fffffff3f3f3
+fffffffffffffffffffffffffffffffffffffffffffffffff9f9f9060606000000ffffff
+fefefefffffffefefef3f3f3ffffff090909f3f3f3000000fffffff8f8f80d0d0d000000
+fafafa0303030000000d0d0d000000040404000000000000ffffffffffff000000000000
+000000050505f5f5f5ffffff0b0b0bf0f0f0000000f6f6f6ffffff000000070707000000
+040404000000000000000000f3f3f3fafafaffffff060606000000ffffffffffffffffff
+fffffff6f6f6fefefe000000fffffff7f7f70000000a0a0a070707000000121212000000
+f7f7f70e0e0e000000fefefe090909000000fffffffffffff4f4f4000000000000040404
+080808000000000000000000050505fffffff6f6f6fbfbfbfbfbfbf0f0f0fffffffcfcfc
+f3f3f3fffffffafafafffffffefefef7f7f7ffffffeeeeeefafafafcfcfcfffffff2f2f2
+fffffffffffff4f4f4f9f9f9ffffff000000f0f0f0ffffff
+fafafafffffff1f1f1fffffffffffff7f7f7ffffff000000f5f5f5fffffffefefe000000
+020202f6f6f6fffffff9f9f9000000060606040404000000fffffffffffff0f0f0ffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffbfbfb0a0a0a040404ededed
+fffffffafafafffffffffffffffffff3f3f3fffffffffffff4f4f4ffffff000000000000
+fffffff7f7f70c0c0c000000fffffffcfcfc0d0d0d070707fcfcfcffffff000000ffffff
+fffffff4f4f4fffffffffffffffffff9f9f9fffffffffffff3f3f3ffffff000000040404
+000000030303f6f6f6070707ffffffffffff000000000000030303f0f0f0ffffff000000
+000000ffffff070707030303fefefeffffff0c0c0c000000000000000000000000020202
+080808000000000000070707fcfcfcf2f2f2fffffff7f7f7030303fffffffffffffbfbfb
+fdfdfdffffff000000020202000000fffffffffffffcfcfcfffffffffffff0f0f0ffffff
+fffffffffffffdfdfdfbfbfbffffff000000000000fffffffffffff4f4f4ffffffffffff
+fafafafefefefffffffffffffefefefdfdfdffffffffffff
+f6f6f6fffffff0f0f0fffffffafafafffffff1f1f10d0d0dfffffff7f7f7ffffffffffff
+f8f8f8ffffff000000080808050505f6f6f6fffffffafafa040404fffffff5f5f5ffffff
+fafafafffffffffffffffffffffffffffffffffffffafafafbfbfb0c0c0c000000000000
+fffffffffffffffffffffffffdfdfdfffffffdfdfdffffff000000ffffffffffff000000
+fcfcfcffffffffffff000000fffffffcfcfc0c0c0c000000070707030303000000ffffff
+fffffffffffffffffffbfbfb020202080808f8f8f8f3f3f3fffffff5f5f50c0c0c000000
+0b0b0bf0f0f0ffffff010101ffffff000000070707000000000000fffffffffffffbfbfb
+fffffff9f9f9000000000000f8f8f8ffffff010101000000000000040404ffffff000000
+000000000000fffffffffffff1f1f1fffffff7f7f7fdfdfdfffffff6f6f6f6f6f6ffffff
+fafafafafafa000000040404000000fffffff5f5f5fffffffffffffffffff8f8f8ffffff
+fffffff6f6f6fffffffffffff2f2f2ffffffffffff000000ffffffe1e1e1ffffffffffff
+fcfcfcf3f3f3fffffff1f1f1000000fffffffbfbfbf5f5f5
+ffffffffffffefefeffffffffffffffbfbfbfffffff1f1f1000000fffffffbfbfbf6f6f6
+ffffff000000fffffff9f9f9f8f8f8fcfcfcffffffffffff000000fffffffffffff0f0f0
+fffffff8f8f8f7f7f7fffffffffffff2f2f2fbfbfbffffffffffff000000ffffff0a0a0a
+ffffff000000fdfdfdf4f4f4ffffffffffff000000f7f7f7181818f4f4f4f7f7f7060606
+ffffffffffff000000fbfbfbfffffffafafaefefeffffffff8f8f8fdfdfdfafafaf9f9f9
+f2f2f2fffffffffffffafafa000000000000fffffffffffffffffff8f8f8000000070707
+0000001a1a1a0000000000000000000303030000000c0c0c0000000a0a0a050505000000
+fffffff6f6f60b0b0b0707070d0d0dfcfcfc030303070707000000070707000000060606
+fffffffffffffdfdfdfffffff8f8f8fffffffffffffffffff0f0f0ffffffffffffffffff
+0000000303030e0e0e000000000000fffffffffffffffffff9f9f9f8f8f8f5f5f5ffffff
+fffffffbfbfbfffffff4f4f4fffffffafafa020202fdfdfd0303031d1d1df5f5f5f4f4f4
+fcfcfcffffffedededffffff151515e9e9e9ffffffffffff
+f8f8f8fefefefffffffffffffffffffffffff3f3f3ffffff0d0d0df6f6f6fafafaffffff
+000000ffffffffffffffffffffffffffffff000000000000fffffffffffffdfdfdffffff
+fffffffffffffefefefffffff4f4f40000001f1f1f000000000000000000f6f6f6000000
+000000020202fffffffffffffffffffefefef9f9f9fffffff9f9f9f5f5f5ffffff000000
+040404fefefefffffffffffffafafafffffffffffff9f9f9070707f9f9f9ffffffffffff
+fdfdfdfffffff7f7f7fffffffcfcfc101010000000fcfcfcfffffffbfbfb000000040404
+000000000000000000101010fefefe000000000000000000000000000000f8f8f8ffffff
+fafafaf7f7f7ffffff000000000000000000000000090909020202060606000000fefefe
+f9f9f9fffffffbfbfbf5f5f5ffffffe1e1e1060606f7f7f7fffffff7f7f7ffffffffffff
+0b0b0b000000efefef0d0d0d030303eaeaeafffffffffffffdfdfdfffffffffffff1f1f1
+ffffffffffffececec0404040000000707070000000909090000000000000b0b0bececec
+fefefefffffff9f9f9040404e7e7e7fffffff6f6f6ffffff
+fbfbfbffffffffffffebebebfbfbfbfffffff5f5f5f9f9f9fefefe000000fffffff5f5f5
+000000f9f9f9fffffff9f9f9fbfbfb0000001b1b1b040404eeeeeefefefefffffff1f1f1
+fafafafffffffffffffdfdfdfffffffefefeecececf6f6f60000000101010d0d0d000000
+1a1a1affffffe0e0e0fffffffafafaf3f3f3fffffff7f7f7fffffffffffffbfbfb040404
+0000000a0a0a000000fafafafffffffafafaf5f5f5fcfcfc000000ffffffe2e2e2f9f9f9
+ffffffffffffffffffffffffffffff000000050505fdfdfdfafafaffffff020202010101
+0000000a0a0a040404000000fafafa060606141414000000f6f6f6fffffff8f8f8f2f2f2
+fffffffffffff8f8f8ffffff050505ffffff050505000000070707000000ffffffffffff
+fffffff4f4f4f7f7f7fffffffffffffffffffffffffdfdfdfdfdfdfbfbfbffffffffffff
+0000000a0a0a0505050000000000000e0e0e000000040404000000fffffffffffff6f6f6
+f4f4f4ffffffffffff090909fbfbfbfffffffffffff3f3f3ffffffffffff0303030d0d0d
+fffffff6f6f6ffffff030303fffffffcfcfcfdfdfdffffff
+fffffffcfcfcfcfcfcfffffffdfdfdfbfbfbffffffffffffffffff020202fdfdfdffffff
+ffffff0202020000000b0b0b000000020202000000000000171717000000050505ffffff
+fdfdfdfffffff6f6f6f9f9f9fffffffffffffafafafffffff7f7f7fffffff9f9f9ffffff
+0000000000001f1f1f000000171717000000f4f4f4000000fffffff8f8f8ffffff000000
+000000060606000000ffffffffffff000000ffffffffffff070707efefefffffffffffff
+fdfdfdf4f4f4fffffffbfbfbfffffff2f2f2f4f4f4030303fffffff9f9f9040404000000
+0707070a0a0a000000181818000000000000000000fffffffffffff8f8f8010101000000
+010101fdfdfdf3f3f3f7f7f7000000020202000000000000030303131313edededfefefe
+fffffff1f1f1fffffffffffff8f8f8e6e6e6fffffffffffffafafa000000020202131313
+0202020000000f0f0f000000030303000000000000ffffff0a0a0af9f9f9eeeeeeffffff
+ffffffffffffefefef0e0e0e000000f3f3f3fffffffffffffafafafffffffffffffbfbfb
+ffffffeeeeeeffffff030303f3f3f3f0f0f0ffffffffffff
+fffffffbfbfbfafafafffffffffffff2f2f2fffffff0f0f0f5f5f5fdfdfdffffffe6e6e6
+fffffffffffffffffff2f2f2000000fffffffffffff5f5f5ffffffffffff000000ffffff
+f3f3f3fffffff3f3f3ffffffffffff0000000e0e0e000000020202080808f2f2f2ffffff
+fefefefffffff7f7f7fafafae5e5e50e0e0e000000060606000000f1f1f10a0a0affffff
+000000f7f7f70a0a0aebebebfffffffffffffefefef7f7f7000000fffffff9f9f9f2f2f2
+fffffffffffffffffff7f7f7f6f6f6fdfdfdffffff060606f6f6f6ffffff050505000000
+000000000000f1f1f1000000101010fbfbfb0d0d0d000000060606000000090909fcfcfc
+f5f5f5ffffffffffffffffff0505050000001212120707070000000303030b0b0bffffff
+f7f7f7fffffffffffff5f5f5ffffff0707070000000000000808080000000e0e0e000000
+050505ffffffedededfffffffffffffefefe050505000000000000f7f7f7ffffffffffff
+f7f7f7fffffffffffffafafafffffffdfdfd000000fffffffffffffafafaf6f6f6ffffff
+ffffffffffff090909f8f8f8fffffffffffffbfbfbeeeeee
+fffffffffffff9f9f9f6f6f6fafafafffffffffffffdfdfdfffffffdfdfd0f0f0ff9f9f9
+ffffffebebeb090909070707fffffff8f8f8fffffff2f2f2fbfbfbfbfbfb000000ffffff
+fffffffefefefffffff8f8f8f2f2f21515150000000000000101010101010d0d0d000000
+000000fffffffffffffafafafffffff6f6f6ffffff000000050505060606000000000000
+000000111111000000fffffffcfcfce9e9e9ffffffffffff000000ffffffeeeeeeffffff
+fffffff7f7f7efefeffffffffdfdfdffffffeeeeee000000040404f9f9f90b0b0b000000
+0000000101011515150d0d0deaeaeafffffffbfbfbfdfdfd030303ffffff000000ffffff
+ffffffe6e6e6fffffff9f9f9fafafa0000000202020101010a0a0a050505000000fcfcfc
+fffffff8f8f8f0f0f0ffffff000000000000090909000000030303000000ffffffffffff
+fafafafffffffdfdfd000000000000040404000000000000020202ffffffeaeaeaffffff
+fffffff9f9f9fffffff8f8f8fcfcfcffffffe8e8e8090909050505f6f6f6ffffffffffff
+fffffff6f6f6000000ffffffeeeeeefffffffcfcfcffffff
+f4f4f4fffffffffffffbfbfbfffffffffffff3f3f3fffffffbfbfbffffff000000fbfbfb
+fffffffdfdfdfdfdfdfafafafffffffffffffbfbfbffffff080808000000fffffffdfdfd
+fffffff4f4f4fffffff5f5f5ffffff000000000000030303010101000000020202000000
+070707000000010101030303000000fefefefcfcfcfffffffafafafffffffefefe000000
+050505000000060606000000fffffffffffff6f6f6fafafafffffff4f4f4fffffff3f3f3
+fffffffffffffffffffffffffffffffbfbfbfffffff7f7f7000000090909000000080808
+090909000000000000fffffffffffffffffff8f8f8fffffffffffffefefef5f5f5fbfbfb
+fffffffffffff9f9f9fefefeffffffffffff0000000000000000000000000f0f0ff9f9f9
+f7f7f70101010d0d0d0000000a0a0a000000000000fbfbfbf9f9f9fffffff4f4f4000000
+060606000000000000030303010101060606000000010101ffffffecececfffffff9f9f9
+fafafa000000050505010101000000000000121212000000000000000000000000ffffff
+f2f2f2ffffff070707fcfcfcfdfdfdfffffff6f6f6ffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffdfdfdffffff080808000000
+fffffffffffff4f4f4ffffffffffff010101000000000000fcfcfcfffffffffffffbfbfb
+f6f6f6ffffffffffffedededfffffffcfcfc0000000303030000000000000a0a0af4f4f4
+000000080808f6f6f6050505000000030303000000010101030303fffffffffffffbfbfb
+ffffffffffffffffff000000000000000000000000ffffffffffff000000fefefeffffff
+fffffff9f9f9fffffffffffffffffff9f9f9fcfcfcfffffff0f0f00c0c0c000000080808
+0000000707070000000b0b0bfefefefffffffffffffffffff4f4f4fffffffcfcfcffffff
+f8f8f8fffffff5f5f5ffffffffffffffffff000000010101050505010101000000080808
+000000020202000000f8f8f8fffffff4f4f4fffffffcfcfc080808000000101010000000
+050505000000090909000000000000000000060606fcfcfcfbfbfbfffffffbfbfbffffff
+0a0a0af9f9f9fffffff7f7f7000000fffffffffffffffffffbfbfbfffffffffffff7f7f7
+fefefe030303eeeeeeffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffdfdfdffffffeaeaea0f0f0f
+fffffff1f1f1ffffff050505000000fffffffffffffffffff1f1f1fffffffffffff9f9f9
+0b0b0bfdfdfdffffffffffffeeeeeefffffffffffffffffffdfdfd121212000000ffffff
+000000000000000000010101070707f7f7f70f0f0f000000000000000000090909000000
+000000010101fffffffefefeffffffeeeeeeffffff0000000000000101010808080a0a0a
+000000111111f9f9f9000000f2f2f2ffffffffffffffffff050505ffffff010101000000
+0a0a0a0000000f0f0ffbfbfb000000fffffff9f9f9fcfcfcfffffff4f4f4fbfbfbffffff
+fffffff8f8f80000000d0d0dffffff0000001313130606060000000f0f0ffffffffbfbfb
+ffffffffffffffffff0000000000000303030000000d0d0d000000131313000000070707
+020202f5f5f5000000060606fffffffffffffdfdfdf4f4f4fbfbfbfffffffafafaffffff
+f8f8f8f3f3f30e0e0efffffffffffff8f8f8000000fafafaffffffeeeeeeffffffffffff
+ffffff020202fffffff3f3f3ffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffff5f5f5fffffffffffffdfdfd
+000000fafafaffffffefefeff8f8f8fdfdfdf9f9f9fbfbfbfffffff4f4f4ebebebffffff
+000000edededfffffff6f6f6f7f7f7f6f6f6fffffff8f8f8fefefeffffff030303fafafa
+0707070303030000000000000000000d0d0d0000000505050f0f0f030303000000000000
+1010100d0d0d000000000000090909fdfdfdf5f5f5ffffffffffffffffff000000050505
+0000000000001010100707070d0d0d000000ebebebffffff000000f6f6f60e0e0e0a0a0a
+040404000000090909ffffff000000fffffffffffffffffffffffff2f2f2fffffff7f7f7
+f1f1f10b0b0b0a0a0a000000000000111111f7f7f7fffffff6f6f6fcfcfcf5f5f5ffffff
+0000000909090000000000001717170505050000000000000b0b0b000000030303000000
+000000ffffff010101fffffff0f0f0fffffff0f0f0fffffffffffffffffff9f9f9f9f9f9
+fdfdfdfffffff3f3f3f2f2f20e0e0effffffffffff000000000000f8f8f8fffffff5f5f5
+000000fffffffffffffcfcfcffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff1f1f1fffffff5f5f5
+0d0d0dfafafaffffffffffffffffffffffffffffffedededfffffffffffff9f9f9ffffff
+000000fffffffffffffffffffffffffffffffcfcfcfffffffdfdfdf7f7f7000000ffffff
+0000000505050000000202021111110202020000000000000404040303030000000d0d0d
+000000f5f5f5010101000000060606000000000000111111000000fffffffffffff9f9f9
+ffffffffffff0000000000000101010f0f0f030303000000000000000000000000000000
+0000000f0f0f090909fafafa070707050505ffffff000000f1f1f10a0a0a000000060606
+050505000000000000fffffffffffff7f7f7fffffff9f9f9ffffff0000000000000c0c0c
+0000001212120c0c0c0000000000000000000808080707070404040000000707070f0f0f
+000000ffffff000000fffffffffffffafafafffffff2f2f2fffffff4f4f4ffffff030303
+131313010101000000111111f4f4f4000000000000000000fffffffcfcfcfdfdfdffffff
+020202f3f3f3fffffff9f9f9ffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffecececfffffff7f7f7ffffff
+ffffff000000ecececffffffffffff000000fffffffffffffffffffdfdfd000000000000
+ffffff000000000000000000fafafaedededfbfbfbffffffffffff000000ffffff000000
+0a0a0a0a0a0a000000030303000000fcfcfc131313000000040404f6f6f6000000ffffff
+ffffff0a0a0a0e0e0e0000000000000f0f0f0707070000000d0d0d000000000000000000
+0000000d0d0dfffffffefefefdfdfdf9f9f9ffffff000000111111000000080808070707
+090909000000f1f1f1fbfbfbffffff010101000000121212000000000000000000ffffff
+fdfdfdfffffffefefeffffff0000000303030606060909090000000a0a0a080808000000
+ffffff000000000000040404ffffff000000000000010101ffffffffffff030303f2f2f2
+040404f7f7f70e0e0efcfcfcfbfbfbfffffffefefefffffffffffff5f5f5fffffff8f8f8
+f0f0f0000000fffffff0f0f0060606030303000000040404f2f2f2ffffffffffff040404
+fcfcfcfffffff9f9f9ffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffefefef5f5f5ffffff
+ffffff000000fffffffcfcfcfafafa000000fffffff5f5f5fcfcfc000000090909ffffff
+000000fffffff9f9f9000000fffffffffffffffffffdfdfde4e4e40e0e0effffff000000
+060606040404ffffff050505000000fffffff4f4f4ffffff070707fefefeffffff000000
+ffffff0000000000000707070000000606060000000909090000000e0e0efffffff6f6f6
+080808000000000000020202ffffffffffffedededffffffffffff000000ffffff000000
+0101010c0c0cfafafaffffff000000000000020202020202ffffffffffffe9e9e9fefefe
+ffffff0000000909090000000303030000000000000d0d0d0000000000000000000a0a0a
+ffffff000000101010fffffffefefefefefeffffff0000000000000000000c0c0cffffff
+000000ffffff050505f3f3f3fafafafffffffffffffbfbfbfffffff7f7f7000000ffffff
+ffffffffffff000000fdfdfdfffffffffffff5f5f5fffffffffffffefefeffffff000000
+fffffff4f4f4fcfcfcfdfdfdffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff5f5f5
+f3f3f3ffffff050505fafafaffffff000000000000020202000000131313e8e8e8000000
+010101ffffffffffff020202f1f1f1fffffff7f7f7fffffffffffff2f2f2fcfcfc1b1b1b
+010101fffffff7f7f7020202060606f9f9f9020202080808000000000000020202000000
+ffffff0202020000000000000e0e0e0404040b0b0b0000000000000b0b0b000000000000
+151515000000ffffff010101000000070707080808f6f6f6fcfcfc080808ececec010101
+f6f6f6000000fbfbfbfbfbfb070707fffffffffffffafafaf1f1f1080808090909020202
+0d0d0d0000000707070000000f0f0f0000000000000000000000001010100f0f0f000000
+f2f2f2080808f9f9f9000000ffffffffffff0000000707070b0b0b080808000000ffffff
+f2f2f2fefefeeeeeee141414ffffffe9e9e9fffffffdfdfdf5f5f5ffffffffffff000000
+f8f8f8fffffff7f7f7fdfdfd040404fbfbfbfffffff6f6f6ffffffececec060606ffffff
+f1f1f1fffffffefefeffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffefefef5f5f5ffffffffffff
+ffffffffffff000000fffffffdfdfdfefefefffffffffffffffffff1f1f1ffffff000000
+fffffff9f9f9f4f4f4fffffffefefefffffffffffffefefe000000ffffff000000000000
+000000fafafaffffff020202030303fcfcfcfdfdfdffffff050505030303000000ffffff
+000000000000020202020202fefefef9f9f9f9f9f90303030e0e0e0000000000000c0c0c
+f7f7f7000000060606000000070707000000000000010101060606000000ffffff020202
+ffffff050505ffffffffffff000000020202000000000000101010000000000000ffffff
+0000000000000808080000000000000d0d0d000000fffffff8f8f8000000000000040404
+fffffffafafa0a0a0a000000030303f4f4f40f0f0f000000000000040404f7f7f7000000
+0b0b0bfefefeffffff000000f8f8f8fffffffdfdfd000000070707000000070707000000
+000000fffffffdfdfdffffffffffff050505f9f9f9fffffff5f5f5ffffff000000f4f4f4
+fffffff8f8f8ffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff1f1f1ffffffffffff
+f5f5f5fbfbfbffffff000000f8f8f8fffffff5f5f5ffffff000000fffffffdfdfd020202
+fffffff7f7f7fffffffffffffefefef6f6f6fffffff8f8f8010101f3f3f3070707020202
+000000fafafafcfcfc080808000000ffffffffffffffffff000000000000000000ffffff
+010101000000ffffff0000000d0d0dfffffff7f7f7fffffffffffff7f7f7050505f9f9f9
+0000000f0f0f000000070707050505090909000000000000050505010101ececec0e0e0e
+f7f7f7fffffff3f3f3ffffff000000000000000000060606050505000000030303ffffff
+040404000000141414000000000000030303fffffffcfcfcf0f0f00606060a0a0a000000
+fcfcfcffffff030303000000fffffffffffff0f0f00f0f0f000000090909fbfbfb000000
+fcfcfc0f0f0ff2f2f20a0a0afbfbfbfffffffcfcfcfffffff7f7f7030303020202010101
+ffffff000000fffffff9f9f9f9f9f9ffffffecececfffffff7f7f7070707fafafaf9f9f9
+fffffffffffffffffffafafaffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff0f0f0f8f8f8f9f9f9
+ffffffffffffe9e9e9151515ffffffe8e8e8fefefeffffff060606fdfdfdfafafa030303
+ffffffffffff020202000000fafafafefefefffffffdfdfdffffff000000000000000000
+fffffffefefefdfdfd020202040404fffffff5f5f5efefef0303030a0a0a000000ffffff
+000000070707f2f2f2ffffff000000fefefefffffff7f7f7fdfdfdfcfcfc000000ffffff
+000000fafafa0202020000000000000000000000000000000404040b0b0b020202fcfcfc
+0c0c0cf0f0f0ffffffffffff000000030303131313000000000000010101000000f4f4f4
+1616160000000000000a0a0a030303000000fffffffdfdfdffffff000000000000ffffff
+fcfcfcffffff0505050b0b0b000000f7f7f7ffffff000000101010030303000000ffffff
+fbfbfb000000ffffff000000fdfdfdfffffffffffffefefeffffffffffffffffff000000
+000000000000000000fffffffffffffffffffffffff2f2f20e0e0ef1f1f1ffffffffffff
+fffffffdfdfdf1f1f1ffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffafafafffffffffffff7f7f7
+fffffff6f6f6ffffffe7e7e7060606fffffffffffffafafa0000000000001e1e1eefefef
+f1f1f1f1f1f10000001212120c0c0cfcfcfcffffff000000f0f0f00b0b0b030303000000
+fefefefbfbfbffffff010101030303fcfcfcffffffffffff070707000000ffffff000000
+0000000b0b0bf8f8f8ffffff070707fffffffefefeffffffffffffffffffefefef000000
+020202fefefe121212060606070707ffffffffffff050505040404000000000000ffffff
+000000f8f8f8fefefefbfbfb040404020202000000030303070707000000020202ffffff
+e3e3e30d0d0d060606000000010101000000fcfcfcf0f0f0ffffff000000f6f6f6ffffff
+131313ebebebededed020202131313fefefefffffffffffff9f9f9000000000000ffffff
+060606000000fffffffffffffffffffffffffdfdfdfffffff0f0f0fffffffffffff6f6f6
+ffffff000000000000fffffff1f1f1f8f8f8f3f3f3ffffff000000ffffffefefefe8e8e8
+fefefefcfcfcffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffefefefffffffffffffcfcfc
+fffffffdfdfdfcfcfcfffffff9f9f9000000fffffffffffffffffffdfdfdf9f9f9ffffff
+ffffffffffffffffff000000f7f7f7ffffffe8e8e8121212ffffff0000000303030d0d0d
+060606ffffff000000030303010101fafafaffffffeeeeee000000000000ffffff030303
+111111000000fcfcfcffffff000000000000fffffffafafafcfcfcfcfcfc161616000000
+f5f5f5090909000000010101000000fdfdfdfefefe0000000000000e0e0ef5f5f5ffffff
+000000fffffffffffffffffffffffffafafaffffff000000fafafafdfdfdfefefeffffff
+ffffff030303000000ffffff0000000d0d0dfefefeffffffffffff000000fffffff7f7f7
+000000ffffffffffff000000040404fafafaf6f6f6fbfbfb030303000000fffffff9f9f9
+f2f2f2191919fafafaf4f4f4000000f6f6f6fffffff8f8f8ffffffefefefffffffffffff
+f5f5f5f9f9f9fffffff1f1f1fffffffffffff3f3f3090909ffffffffffffffffffffffff
+fffffff8f8f8ffffffefefefffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff4f4f4f9f9f9ffffff
+fffffffffffff0f0f0f3f3f3ffffff000000000000eaeaeafffffffffffff4f4f4ffffff
+fbfbfbfafafaf9f9f9fefefef3f3f3ffffff030303fafafa0101010000000c0c0c050505
+000000000000161616000000000000fffffffbfbfbffffff050505060606f2f2f2121212
+000000040404050505ffffff000000040404121212f9f9f9fffffffbfbfb030303000000
+ffffff0000000000000a0a0a000000070707ffffff000000ffffff060606fffffff8f8f8
+fffffff9f9f9000000fefefee6e6e6fffffff6f6f6050505fffffff9f9f9000000fafafa
+ffffff040404040404ffffff0f0f0f000000f5f5f5fffffff8f8f8000000ffffffffffff
+000000ffffffe7e7e7131313000000f8f8f8ffffff000000fefefefcfcfcececec020202
+ffffff0000000a0a0afafafa050505fffffff6f6f6fefefefffffffffffffffffffdfdfd
+fffffffdfdfdffffffffffffefefeff3f3f3010101020202fffffffdfdfdeaeaeaffffff
+f6f6f6f6f6f6ffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff8f8f8ffffffffffff
+eeeeeefbfbfbfffffffffffffcfcfcffffff000000ffffffffffffe8e8e8fffffffbfbfb
+fefefef6f6f6ffffffecececfffffffbfbfb000000ffffff000000ffffff000000000000
+0b0b0bffffff000000030303fffffffffffffbfbfbfefefe010101ffffff040404000000
+151515000000fafafae4e4e4ffffffffffff0000000505050000000e0e0e030303080808
+000000020202070707000000030303000000fdfdfd000000131313000000ffffffffffff
+ffffffe9e9e9141414fefefefffffffffffff8f8f8030303000000ffffff0f0f0f0a0a0a
+f9f9f9000000000000f8f8f80000000d0d0d0b0b0be3e3e3ffffff0d0d0dfbfbfbf7f7f7
+ffffff000000ffffff000000070707030303000000ffffffffffffffffffffffffffffff
+f9f9f9ffffff000000ffffff000000f0f0f0080808050505fffffffdfdfdf1f1f1ffffff
+f8f8f8fefefef6f6f6fffffff4f4f4ffffff000000fcfcfceeeeeeffffffffffffffffff
+f6f6f6fffffffdfdfdfefefeffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffffcfcfcffffffffffff
+fffffffcfcfcffffffeeeeeeffffffffffffffffff080808ecececfbfbfbfffffffdfdfd
+f6f6f6ffffffedededffffffffffffffffff000000ffffff040404ffffff070707101010
+fafafaeaeaea0909090000000000000303030000000e0e0e000000f3f3f3131313000000
+000000fffffffffffffffffffffffffcfcfcffffff0000000d0d0d050505000000000000
+000000ffffff0000000303030303030707070000000505050000000a0a0afffffff5f5f5
+f6f6f6000000fbfbfbfffffff0f0f0040404fcfcfcffffff0f0f0ff5f5f5f3f3f3000000
+fdfdfdffffff000000fffffffffffff6f6f6ffffffffffff000000000000f8f8f8ffffff
+f5f5f5000000ffffff000000040404000000101010f0f0f0f0f0f0ffffff020202f5f5f5
+ffffffffffff000000ffffff161616fafafa010101f5f5f5fbfbfbf6f6f6fffffff8f8f8
+fffffffbfbfbf6f6f6ffffffffffff000000fffffffffffffffffff2f2f2fffffff3f3f3
+fcfcfcfffffffffffff9f9f9ffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffdfdfdffffffffffffffffff
+fffffff6f6f6fffffffdfdfdfffffff3f3f3fffffff5f5f50c0c0cffffffffffffffffff
+fffffff2f2f2fffffffffffffcfcfcffffff050505000000010101f6f6f6fffffff3f3f3
+ffffff131313f9f9f9ffffff0101010000000f0f0f000000000000070707000000fdfdfd
+101010ebebeb070707000000000000050505fcfcfc090909000000f7f7f7000000ffffff
+010101f3f3f3ffffff030303040404f7f7f7fffffffcfcfcffffff060606fefefe070707
+fbfbfbffffff040404f9f9f9ffffff000000f5f5f5ffffff000000ffffffffffff000000
+fffffff7f7f7000000000000000000fbfbfb000000030303fdfdfd080808fefefefefefe
+fbfbfb0f0f0f010101000000000000030303000000010101fffffff7f7f7000000fcfcfc
+fffffffefefe000000fffffff3f3f3fffffffbfbfbfffffffffffff6f6f6fbfbfbfdfdfd
+f4f4f4fffffff2f2f2ffffff000000fffffffbfbfbfafafafffffffffffff8f8f8ffffff
+f6f6f6f8f8f8fffffffdfdfdffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff6f6f6fefefefffffff5f5f50d0d0d000000f8f8f8ffffff
+fffffffdfdfdfffffff4f4f4fbfbfbffffffffffff020202020202fffffff9f9f9fdfdfd
+fafafa0404040000000505050000000000000909090000000b0b0b000000000000080808
+fffffffbfbfb000000fffffff6f6f6ffffff000000ffffff000000ffffff040404fafafa
+000000000000fbfbfbffffff020202fefefefafafa0f0f0f000000030303030303000000
+fbfbfb020202000000030303030303000000020202fbfbfb0b0b0bf4f4f4ffffff000000
+000000ffffff000000010101030303000000030303ffffff000000000000121212000000
+000000000000000000000000000000000000000000000000000000040404020202020202
+fafafaffffff000000fefefef8f8f8060606ffffffeeeeeefffffff9f9f9f2f2f2ffffff
+f5f5f5fdfdfdffffff000000090909fffffffffffff9f9f9ffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffbfbfbeeeeeefffffff2f2f2060606151515eaeaea
+f5f5f5fffffff4f4f4fffffffffffff6f6f6060606000000000000000000070707161616
+0000000000001212120000000505050000000000000f0f0f000000010101070707000000
+0000000b0b0b0000000c0c0c010101000000000000000000000000040404000000040404
+0d0d0d0000000f0f0f0000000000000000000707070000000808081212120000000b0b0b
+0d0d0d0000000707070000000000000707070000000d0d0d0000000000000404040b0b0b
+0000000707070000000303030000000a0a0a000000030303000000000000040404000000
+000000000000000000000000000000000000000000000000000000070707000000040404
+0000000d0d0d000000040404000000090909ecececfffffffdfdfdfffffff8f8f8f9f9f9
+ffffffffffff010101010101f1f1f1f2f2f2fefefeffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffff7f7f7fffffff7f7f7fafafaf6f6f6ffffff020202
+fcfcfcfffffffffffffefefef3f3f3ffffff000000fffffffffffff0f0f0f0f0f0ffffff
+f2f2f2ffffffedededfffffffefefefffffff5f5f5f9f9f9fffffffffffffffffffdfdfd
+fffffffffffff1f1f1fafafaf7f7f7fffffff7f7f7fffffffffffffbfbfbffffffffffff
+e6e6e6fffffff1f1f1fbfbfbf8f8f8fffffff4f4f4fffffffbfbfbf5f5f5fcfcfcffffff
+f4f4f4fffffff8f8f8fffffffffffff8f8f8fffffff4f4f4fffffff6f6f6fafafafbfbfb
+fefefeecececfffffffafafafefefefbfbfbffffffe9e9e9fffffffffffffffffffefefe
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff7f7f7fffffff1f1f1
+ffffffffffff000000000000000000000000fffffffffffff3f3f3fcfcfcffffffffffff
+ffffff000000f7f7f7fffffffffffffffffffffffff8f8f8ffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff4f4f4fcfcfcfffffffbfbfbfffffffffffff4f4f4000000
+ffffffebebebf9f9f9f7f7f7fffffffffffffafafa000000010101090909080808000000
+080808ffffffffffff0000000707070000000c0c0cffffff000000020202000000080808
+ffffff000000fffffffbfbfbffffff070707060606000000000000ffffff000000000000
+0000000c0c0c0000000e0e0effffff000000000000000000000000ffffff010101000000
+0404040000000101010000000000000101010000000404040000000d0d0d0d0d0d000000
+0000001a1a1a000000020202090909000000010101101010000000000000000000070707
+0000000000000000000000000000000000000000000000000707070000000000000d0d0d
+0000000606060000001313130404040d0d0dfffffff7f7f7f3f3f3fffffff6f6f6ffffff
+f9f9f90e0e0ef9f9f9f6f6f6fdfdfdefefeffdfdfdffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffebebebf1f1f1fdfdfdffffffffffff
+0c0c0cfffffff0f0f0ffffffffffffddddddfcfcfc0404040000000202020000000a0a0a
+0000000000000808080b0b0b0000000c0c0c0000001111110000000000000b0b0b040404
+0000000404040000001b1b1b000000000000060606020202010101060606000000000000
+040404060606000000090909000000040404070707000000151515000000000000000000
+0000000000000a0a0a0000000000000a0a0a000000000000000000000000000000121212
+000000000000020202020202030303060606000000000000020202000000030303000000
+010101010101010101010101010101010101010101010101000000050505000000000000
+050505000000000000000000000000f5f5f5fffffffffffffffffffffffff5f5f5ffffff
+000000e9e9e9fffffff3f3f3ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffefefefffffffafafafffffffffffffffffff1f1f1ffffff
+f0f0f0010101080808ffffffebebebfffffffffffffcfcfcfcfcfcffffffffffffefefef
+ffffffffffffeaeaeafcfcfcffffffffffffffffffe9e9e9fffffff5f5f5fffffff7f7f7
+fffffffbfbfbffffffefefefffffffffffffe6e6e6fcfcfcf8f8f8f6f6f6ffffffffffff
+fffffffafafaffffffedededfffffffffffff6f6f6ffffffe1e1e1fffffffffffff6f6f6
+fffffffffffff1f1f1fffffffffffff1f1f1ffffffffffffffffffffffffffffffffffff
+f8f8f8f4f4f4fffffff4f4f4f1f1f1fffffffbfbfbfbfbfbfffffffffffffffffff9f9f9
+fdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfffffffffffffffffff6f6f6
+f8f8f8f9f9f9fffffffffffffffffffffffff2f2f2ffffffffffffefefef040404f4f4f4
+fffffff4f4f4ffffffffffffe5e5e5fffffffffffffbfbfbffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffefefeffffffff9f9f9f6f6f6fffffff7f7f7
+fffffffcfcfc000000080808fefefeecececffffffeeeeeefffffff4f4f4fffffff3f3f3
+f8f8f8fffffff8f8f8fffffff6f6f6f9f9f9fffffffffffffffffff5f5f5f9f9f9ffffff
+ffffffffffffffffffffffffefefeffffffff1f1f1fffffffefefeffffffddddddffffff
+fefefefefefef9f9f9fffffffffffffffffff1f1f1fffffffffffffefefeefefefffffff
+f1f1f1fffffffefefefffffffffffffefefefffffff1f1f1fffffff4f4f4fffffff2f2f2
+fffffffffffff0f0f0fffffffffffffcfcfcf3f3f3fffffff1f1f1f3f3f3ffffffffffff
+fffffffffffffffffffffffffffffffffffffffffffffffffffffff2f2f2ffffffffffff
+fffffffefefeefefeffafafaefefeffffffff7f7f7fffffff3f3f3040404fffffffefefe
+fbfbfbfbfbfbf5f5f5fdfdfdffffffe5e5e5fffffffefefeffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffff7f7f7fffffffafafafefefeffffffeeeeeeffffff
+ffffffffffffffffff000000070707fffffff7f7f7fffffffefefefcfcfcffffffffffff
+fffffffffffffffffffffffffffffffcfcfcfffffffdfdfdf5f5f5070707070707ffffff
+fefefefffffff9f9f9fafafafffffff2f2f2fffffffbfbfbfafafaf8f8f8ffffffffffff
+fcfcfcfdfdfdfffffffffffffefefef9f9f9fffffffffffff8f8f8f0f0f0fffffffafafa
+fffffffefefefbfbfbfffffffffffffbfbfbfefefefffffffdfdfdffffffffffffffffff
+fafafafffffffcfcfcfefefefffffff8f8f8fffffffafafafffffffcfcfcfdfdfdfbfbfb
+fefefefefefefefefefefefefefefefefefefefefefefefef5f5f5fffffff6f6f6ffffff
+fffffffefefefbfbfbfffffffffffffafafafffffff5f5f5060606000000fbfbfbffffff
+fffffffffffffffffff3f3f3fffffffffffff5f5f5ffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fcfcfcfffffff1f1f1fffffffbfbfb000000fffffff9f9f9f2f2f2fffffffafafaffffff
+f7f7f7fffffff3f3f3fdfdfdfefefefffffff2f2f2ffffff000000060606000000ffffff
+f6f6f6fdfdfdfffffffffffffdfdfdfbfbfbfafafafffffffcfcfcfffffffbfbfbffffff
+ffffffffffff000000040404000000f8f8f8fffffffffffff4f4f4ffffffedededffffff
+fffffff0f0f0fffffffffffffffffff2f2f2fffffff5f5f5fffffffdfdfdffffffffffff
+efefeffffffffffffff7f7f7fafafafffffffafafafffffffefefefffffff8f8f8ffffff
+fffffff4f4f4ffffff000000000000fffffff4f4f4fffffff6f6f6fffffffbfbfbfafafa
+fffffffffffff4f4f4fffffffffffff2f2f2ffffff070707f0f0f0fffffffffffffcfcfc
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fcfcfcffffffffffffebebebfffffff7f7f7050505ffffffffffffe3e3e3fcfcfcffffff
+fafafafcfcfcfffffffffffff9f9f9ffffffffffffe5e5e5fefefe0e0e0efffffff7f7f7
+fffffffefefef6f6f6ffffffefefeff3f3f3ffffffefefeff5f5f5fafafafffffff3f3f3
+fcfcfcffffff000000030303ffffff0b0b0b060606e7e7e7090909000000010101f1f1f1
+fcfcfcffffff000000040404000000060606fffffff8f8f8fdfdfdf8f8f8020202f5f5f5
+fffffff1f1f1fffffffffffffffffffdfdfdfefefef8f8f8f7f7f7fffffff6f6f6ffffff
+fbfbfbfffffff7f7f7000000000000f7f7f7fffffffbfbfbfffffffffffff9f9f9fefefe
+fffffff6f6f6fffffffbfbfbffffff060606000000ffffffffffffebebebfbfbfbffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fbfbfbfffffff6f6f6f7f7f7fffffffafafaf3f3f3000000000000ffffffffffffffffff
+f4f4f4fffffffefefef0f0f0fffffff4f4f4ffffffffffffffffffeeeeeeffffffffffff
+fafafaf4f4f4fffffffefefefffffffafafa000000ffffffffffffffffffeaeaeaffffff
+f7f7f7f4f4f41e1e1efdfdfdfdfdfd000000000000ffffffffffff000000ffffffffffff
+f7f7f7000000fffffff2f2f2ffffff0a0a0af3f3f3fffffffbfbfbffffff020202ffffff
+f1f1f1fffffff7f7f7fdfdfdfafafafefefefffffffffffffffffff4f4f4fffffffcfcfc
+fffffff2f2f2fffffffffffffffffffffffff2f2f2fffffffdfdfdfffffffffffff8f8f8
+f2f2f2ffffffe8e8e8fafafa000000090909fafafafffffffbfbfbfefefefdfdfdfefefe
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffefefefefefef7f7f7ffffffffffffffffff010101090909f2f2f2ffffff
+fafafaf0f0f0fffffffffffff9f9f9fffffff4f4f4fffffffffffffdfdfdfffffff0f0f0
+fffffffffffffffffffcfcfcefefefffffff000000040404f6f6f6fafafaffffffffffff
+ffffffffffff000000f7f7f7fcfcfc000000040404ffffffffffff0d0d0df1f1f1fafafa
+ffffff050505f6f6f6fffffff6f6f6000000fdfdfdfffffffffffffbfbfb000000030303
+fefefeffffffe6e6e6fffffffdfdfdffffff000000000000fffffffffffff9f9f9ffffff
+f9f9f9fffffffffffff9f9f9f9f9f9fffffffffffff9f9f9f9f9f9fcfcfcf5f5f5ffffff
+fffffffffffffcfcfc1d1d1d010101fffffffffffff8f8f8fdfdfdfffffffffffffbfbfb
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffebebebfffffffafafafcfcfcfdfdfdf4f4f4fefefefafafaffffff080808f5f5f5
+ffffffffffffecececfafafafffffffcfcfcfffffffffffff0f0f0fffffffbfbfbfefefe
+f7f7f7f5f5f5fafafaf2f2f2fffffff5f5f5fbfbfbfffffffffffffffffffffffffdfdfd
+f8f8f80a0a0a000000ffffffffffff040404000000ffffffe4e4e4000000fffffff4f4f4
+f2f2f20b0b0b010101fffffffffffff1f1f1fffffff0f0f0f5f5f5050505ffffff0a0a0a
+f6f6f6f8f8f8fffffff8f8f8fdfdfdffffff000000000000fffffffffffff9f9f9ffffff
+fffffffefefefafafafffffffffffffafafafefefefffffff5f5f5fffffffbfbfbececec
+ffffff0000000a0a0aedededfffffff6f6f6f0f0f0fafafafffffffffffff5f5f5ffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffafafaf1f1f1fffffffdfdfdf2f2f2fffffffffffffffffff5f5f5ffffff000000
+050505f7f7f7fffffffffffffffffffafafafffffffefefefffffffafafaffffffffffff
+fffffff0f0f0fffffffcfcfcfffffff9f9f9fffffffcfcfcf6f6f6fffffffbfbfbfcfcfc
+f2f2f2040404111111000000000000000000050505ffffffffffff090909f3f3f3ffffff
+ffffffeaeaea000000000000050505fffffff8f8f8fbfbfbffffff000000ffffff000000
+000000ffffffefefeff6f6f6fafafafefefefffffffffffffffffff4f4f4fffffffcfcfc
+fdfdfdfcfcfcfffffffdfdfdfdfdfdfffffffcfcfcfdfdfdfffffff6f6f6ffffffffffff
+000000ffffffffffffffffffffffffffffffffffffffffffe6e6e6fffffffffffff6f6f6
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+f6f6f6fffffffbfbfbe5e5e5fffffffffffff5f5f5fffffffffffff7f7f7fffffffdfdfd
+0000000a0a0af5f5f5f7f7f7fffffffcfcfcf5f5f5fffffff1f1f1fffffff7f7f7fafafa
+f8f8f8fffffff2f2f2fffffffdfdfdfffffffefefef6f6f6fffffff4f4f4ffffffffffff
+ffffff000000070707ffffff020202fffffffafafafbfbfbf8f8f8070707fdfdfdfdfdfd
+ffffffffffffffffff0000000000000d0d0dffffffffffffffffff0b0b0bf9f9f9000000
+060606fcfcfcf9f9f9fffffffffffffdfdfdfefefef8f8f8f7f7f7fffffff6f6f6ffffff
+fffffff8f8f8fffffffffffffffffffffffff8f8f8fffffffffffff3f3f3000000010101
+000000fffffffffffff3f3f3ffffffffffffebebebf6f6f6fffffffffffffefefeffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffff2f2f2fffffffffffffefefef7f7f7fffffffefefefcfcfcfffffff3f3f3ffffff
+fffffff8f8f8000000090909fffffffbfbfbfffffffffffffffffffefefefffffffefefe
+fffffffffffffffffffafafafffffffdfdfdf6f6f6fffffffffffff8f8f8fffffff6f6f6
+f8f8f8090909fefefefdfdfdfcfcfcfffffffefefeffffffffffff000000ffffffffffff
+fffffff7f7f7ffffffffffffffffff000000f7f7f7fffffff9f9f9000000000000090909
+000000000000fffffff8f8f8fafafafffffffafafafffffffefefefffffff8f8f8ffffff
+fbfbfbfffffffffffffffffffffffffffffffffffffbfbfb000000030303010101ffffff
+fdfdfdffffffe9e9e9fffffffffffff6f6f6fffffffffffff7f7f7fffffffcfcfcffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffff000000000000fffffffffffff6f6f6fffffff6f6f6ffffff
+fffffffafafaf8f8f8fffffffffffffcfcfcfffffffbfbfbfcfcfcfafafaffffffffffff
+000000000000f8f8f8fffffffcfcfcfffffffcfcfcfffffff1f1f1000000ffffffffffff
+fdfdfd000000fffffffafafaffffff000000f2f2f2ffffff040404000000f5f5f5ffffff
+f9f9f9060606fffffffffffffbfbfbfffffff6f6f6fffffffafafafdfdfdfffffff7f7f7
+fbfbfbf1f1f1fffffffdfdfdfffffffdfdfd0202020000000d0d0df1f1f1fffffffafafa
+fffffff0f0f0fffffff6f6f6ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffdfdfd010101000000f3f3f3f3f3f3ffffffffffff
+fdfdfdfffffffffffffffffff3f3f3f3f3f3fffffff4f4f4ffffffffffffffffff000000
+151515000000ffffffeeeeeef9f9f9f8f8f8fbfbfbf6f6f6111111070707f2f2f2ffffff
+ffffff040404fffffff6f6f6eaeaea0a0a0afffffff8f8f8000000fffffff9f9f9ffffff
+fefefe000000fcfcfcfffffffffffffafafafffffffffffffffffffffffff5f5f5ffffff
+fffffffffffff3f3f3fafafa131313000000000000fffffff1f1f1fffffffbfbfbffffff
+ffffffefefefffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff7f7f7f9f9f9f3f3f3ffffff131313040404000000ffffff
+fbfbfbf6f6f6fffffffcfcfcfffffffffffff8f8f8ffffffeeeeeefffffff4f4f4fcfcfc
+f2f2f2f4f4f4ffffffffffffffffffffffffffffffffffff000000000000fffffff8f8f8
+fbfbfb0000000101010000000d0d0dffffffedededffffff000000fdfdfdfafafaededed
+ffffff101010000000000000f7f7f7fffffff8f8f8fffffff7f7f7f9f9f9ffffffeeeeee
+f2f2f2efefefffffff000000000000fffffffffffff8f8f8fffffff3f3f3ffffffffffff
+fffffffffffffefefef8f8f8ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffff9f9f9fffffffbfbfbecececffffff040404010101
+fffffffffffffafafafffffff9f9f9f8f8f8fffffff2f2f2fffffffffffffffffff7f7f7
+fffffffffffff6f6f6ecececfffffff6f6f6fefefefffffffffffffffffffffffffefefe
+fffffffffffffffffffbfbfbf9f9f9f7f7f7fffffff0f0f0151515f1f1f1ffffffffffff
+e3e3e3f7f7f7f9f9f9fffffffffffffffffff5f5f5f9f9f9fffffffefefefefefeffffff
+0b0b0b070707020202fffffffffffffffffff7f7f7fffffff9f9f9f5f5f5fffffffbfbfb
+ebebebfffffffffffffbfbfbffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffcfcfcf7f7f7fffffff9f9f9ffffffecececffffffffffff
+050505000000000000fffffff3f3f3f8f8f8fffffff8f8f8fdfdfdfdfdfdfffffff1f1f1
+fffffffcfcfcfafafafffffffffffffcfcfcfffffffafafaedededfffffff3f3f3ffffff
+f4f4f4f9f9f9fffffffffffffffffffbfbfbfbfbfbfffffff7f7f7fefefefffffffafafa
+fffffff2f2f2ffffffebebebefefeffffffffffffffffffffdfdfd0f0f0f000000040404
+f6f6f6fffffffafafafffffffcfcfcfdfdfdfffffffffffffffffffffffffbfbfbfdfdfd
+fffffffcfcfcfcfcfcffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffefefefffffff3f3f3ffffffe9e9e9fcfcfc
+f3f3f3fbfbfb0a0a0a0000000e0e0e030303eeeeeefffffffffffffbfbfbfcfcfcffffff
+f9f9f9efefeffffffff4f4f4ffffffffffffebebebfffffffffffffcfcfcffffffffffff
+fffffffffffff4f4f4f4f4f4fffffffffffff9f9f9fffffffffffffcfcfcf8f8f8fbfbfb
+ffffffffffffeeeeeefffffffffffffffffff1f1f10505050000000a0a0af0f0f0fdfdfd
+fffffffffffffffffffbfbfbf9f9f9fffffff1f1f1fffffff0f0f0fffffff2f2f2ffffff
+fffffffafafafbfbfbffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff3f3f3f4f4f4fbfbfbffffffffffffffffffffffffffffff
+fefefeffffffefefeffafafaf7f7f7fdfdfd000000010101000000020202070707ffffff
+fffffffffffff8f8f8fffffff6f6f6f3f3f3fffffffffffff3f3f3fffffffbfbfbf8f8f8
+fafafafffffff5f5f5fffffffafafae9e9e9fdfdfdfffffffffffffffffffcfcfcffffff
+fcfcfc0000000e0e0e000000000000000000fffffff8f8f8fafafafffffffffffffefefe
+fffffffffffff2f2f2fefefefffffffffffffffffff0f0f0fdfdfdfffffffffffffafafa
+f6f6f6f9f9f9ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffffffffffffffffefefefffffffefefeedededfffffffdfdfd
+ffffffeeeeeefffffff9f9f9fffffffffffffefefefefefefffffffafafa010101000000
+0000000a0a0a000000000000050505fffffff9f9f9fafafaf8f8f8fffffff4f4f4ffffff
+ffffffefefeffffffffefefefdfdfdffffffffffff0000000000000d0d0d000000000000
+050505000000fffffffffffffffffffffffff3f3f3ffffffffffffefefeffefefeffffff
+fffffffafafafcfcfcffffffffffffe6e6e6fffffffbfbfbfffffff3f3f3ffffffffffff
+fbfbfbfffffffffffff4f4f4ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff0f0f00c0c0c0000000303030000000d0d0d000000070707
+000000000000000000000000000000000000000000000000ffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffe8e8e8fffffffffffff9f9f9fffffffffffffcfcfc
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+fffffffffffffffffffffffff2f2f2fffffffcfcfcf7f7f7fcfcfcf6f6f6fdfdfdffffff
+fdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdfdffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffeeeeeefffffffffffff6f6f6f7f7f7ffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+ffffffffffffffffffffffffffffffffffffffffffffffff
+
+showpage
+
+% stop using temporary dictionary
+end
+
+% restore original state
+origstate restore
+
+%%Trailer
/branches/new_sharkdoc/common/sssup.ps
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/makefile
===================================================================
--- branches/new_sharkdoc/makefile (nonexistent)
+++ branches/new_sharkdoc/makefile (revision 1676)
@@ -0,0 +1,33 @@
+# hmmm... da fare meglio mettendo le dipendenze come si deve per non
+# rifare il mondo ogni volta...
+
+SHARK_QG = shark-qg
+MANUALS = vol1 vol2 vol3 vol4 vol5 vol6
+OLD_CONTENT = vol-oldcontent
+
+
+help:
+ @echo Available commands:
+ @echo
+ @echo make clean
+ @echo
+ @echo make shark-qg
+ @echo make manuals
+ @echo make old-content
+ @echo
+ @echo make all
+
+clean:
+ for x in $(SHARK_QG) $(MANUALS) $(OLD_CONTENT); do make -C $${x} clean; done;
+ rm -fr *.pdf *.tgz
+
+shark-qg:
+ for x in $(SHARK_QG); do make -C $${x}; done;
+
+manuals:
+ for x in $(MANUALS); do make -C $${x}; done;
+
+old-content:
+ for x in $(OLD_CONTENT); do make -C $${x}; done;
+
+all: shark-qg manuals old-content
/branches/new_sharkdoc/makefile
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/shark-qg/shark-pxe.txt
===================================================================
--- branches/new_sharkdoc/shark-qg/shark-pxe.txt (nonexistent)
+++ branches/new_sharkdoc/shark-qg/shark-pxe.txt (revision 1676)
@@ -0,0 +1,80 @@
+Network Shark application execution through PXE
+
+Download the GRUB source (I used version 0.97) and run a command like this:
+
+./configure -enable-diskless --enable-preset-menu="menu.lst" --enable-3c90x --disable-ffs --disable-minix --disable-reiserfs --disable-xfs --disable-ufs2 --disable-vstafs
+
+The -enable-diskless option asks to build the PXE compliant GRUB image pxegrub (you will find it in (GRUB_DIR)/stage2).
+
+The --enable-3c90x option enables the support for specific 3Com card. You may need to change this option to support your network card.
+
+The --enable-preset-menu="menu.lst" option says to the building procedure to embed the following menu.lst file:
+
+-----------------------------------------------------
+The menu.lst file used while building GRUB
+-----------------------------------------------------
+# default - boot the first entry.
+default 0
+
+# after 0 sec boot default.
+timeout 0
+
+fallback 0
+
+title Shark
+
+ifconfig --address=192.168.0.201 --mask=255.255.255.0 --server=192.168.0.130
+tftpserver 192.168.0.130
+rootnoverify (nd)
+configfile (nd)/remote-menu.lst
+-----------------------------------------------------
+
+Do change the network information, like IP addresse and server address, to comply with your network.
+
+Then execute "make" and copy the pxegrub image from (GRUB_DIR)/stage2 to your TFTP server directory (for example /tftpboot).
+
+The suggested GRUB configuration can be improved by disabling other filesystems support (i.e., ext2) or, in case of need, to support more than one network card. The latter point is quite delicate, since many GRUB users experienced some problems when including too much network card drivers in a single image.
+
+The embedded menu.lst configuration file points to the remote-menu.lst:
+
+-----------------------------------------------------
+The remote-menu.lst file
+-----------------------------------------------------
+default 0
+timeout 0
+
+title Remote Shark
+kernel (nd)/shark
+boot
+-----------------------------------------------------
+
+The remote-menu.lst file says to GRUB to load the "shark" executable application.
+ATTENTION: Shark kernel and applications must be built with the VM86 option turned on in shark.cfg.
+
+The following lines are an example of the DHCP server configuration file needed to tell to the PXE boot process where to get the PXE image. Of course, again, you may need to adapt network parameters to your needs.
+
+-----------------------------------------------------
+The dhcpd.conf file (using dhcp3)
+-----------------------------------------------------
+option domain-name "mydomain.net";
+option subnet-mask 255.255.255.0;
+default-lease-time 600;
+max-lease-time 7200;
+server-name "server-name";
+
+subnet 192.168.0.0 netmask 255.255.255.0 {
+ range 192.168.0.200 192.168.0.205;
+ option routers 192.168.0.255;
+}
+
+host shark-client1 {
+ # MAC address of the machine where the Shark application will run
+ hardware ethernet 00:0A:5E:3C:97:14;
+ # IP address assigned to that machine
+ fixed-address 192.168.0.201;
+ # PXE image to be served from the TFTP server
+ filename "pxegrub";
+ # TFTP server address
+ next-server 192.168.0.130;
+}
+-----------------------------------------------------
/branches/new_sharkdoc/shark-qg/shark-pxe.txt
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/shark-qg/history
===================================================================
--- branches/new_sharkdoc/shark-qg/history (nonexistent)
+++ branches/new_sharkdoc/shark-qg/history (revision 1676)
@@ -0,0 +1,3 @@
+Version 1.01 - 02 March 2006
+
+Added section about the Unix commands under DOS.
/branches/new_sharkdoc/shark-qg/history
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/shark-qg/shark-qg.tex
===================================================================
--- branches/new_sharkdoc/shark-qg/shark-qg.tex (nonexistent)
+++ branches/new_sharkdoc/shark-qg/shark-qg.tex (revision 1676)
@@ -0,0 +1,1155 @@
+\documentclass[a4paper,10pt]{report}
+
+%\usepackage{html}
+
+\title{The S.Ha.R.K. Quick Guide}
+\author{Tullio Facchinetti\\
+\textit{tullio.facchinetti at unipv.it}\\ \\
+Version 1.11}
+
+\begin{document}
+\maketitle
+
+\tableofcontents
+
+% \begin{abstract}
+% \end{abstract}
+
+%------------------------------------------------------------
+\chapter{Introduction}
+\label{ch:introduction}
+%------------------------------------------------------------
+
+This document has been written for helping the beginner to start
+using the S.Ha.R.K. (\textbf{S}oft \textbf{HA}rd \textbf{R}eal-time
+\textbf{K}ernel) kernel. The S.Ha.R.K. kernel source code is
+available at
+
+\begin{center}
+\underline{http://shark.sssup.it}
+\end{center}
+
+The S.Ha.R.K. Quick Guide is intended to be as an ongoing document,
+since new topics will be added if needed.
+
+%------------------------------------------------------------
+\section{What S.Ha.R.K. is}
+\label{sec:what-is}
+%------------------------------------------------------------
+
+S.Ha.R.K. is a set of libraries that are statically linked into a
+multiboot image, that is the application. Then, the application is
+run through a DOS memory extender (X.EXE) or directly launched at
+boot time using the GRUB.
+
+S.Ha.R.K. makes available to the application all the primitives to
+create, activate and run real-time tasks using state of the art
+scheduling algorithms (EDF, RM, etc.). It also allows to share data
+among the tasks by chosing between several resource reservation
+algorithms like Priority Ceiling, Priority Inheritance, SRP
+\cite{But97}.
+S.Ha.R.K. supports drivers for a huge amount of hardware, like video
+and network cards, frame-grabbers, multi-purpose cards and custom
+boards.
+
+Shark is a compiling kernel with memory protection, not a kernel like
+Linux. You will not find any main() routine into the kernel tree
+because the tree only contains the set of libraries required to build
+the application. The main() function is called by the kernel, and is
+contained into the application files as specified by the C language
+standard.
+
+%------------------------------------------------------------
+\chapter{Getting started}
+\label{ch:getting-started}
+%------------------------------------------------------------
+
+This Section covers the S.Ha.R.K. installation and system building
+from the sources available on the website. As will be introduced in
+Section \ref{sec:platforms}, S.Ha.R.K. can be used under Linux,
+Windows$^{TM}$ or xDOS (preferably the free version of DOS, FreeDOS).
+
+%------------------------------------------------------------
+\section{Supported platforms}
+\label{sec:platforms}
+%------------------------------------------------------------
+
+S.Ha.R.K. application, as well as the Shark kernel, modules and
+drivers, can be developed under three main platforms: DOS (either
+MS-DOS$^{TM}$ or FreeDOS\footnote{In the rest of the document, we
+will only refer to FreeDOS while addressing the xDOS platform. Most
+of the topics hold for other DOS systems; specific indications for
+other platforms will be given if necessary.}), Windows$^{TM}$ or
+Linux. Table \ref{t:platforms-comparison} shows some characteristics
+of using Shark under the three systems.
+
+\begin{table}[ht]
+\centering
+\begin{tabular}{|l|c|c|c|}
+\hline
+ & DOS & Linux &
+Windows \\ \hline
+Graphical interface & no & \textbf{yes} &
+\textbf{yes} \\
+Good editors & it depends & \textbf{yes} &
+\textbf{yes}
+\\
+Compilation speed & slow & \textbf{fast} &
+\textbf{fast} \\
+Native compiler & no & \textbf{yes} & no
+ \\
+Programming/debug tools & no & \textbf{yes} & no
+ \\
+Dealing with long filenames & TSRs & \textbf{native} &
+\textbf{native} \\
+Native execution & \textbf{yes} & no & no
+ \\ \hline
+\end{tabular}
+\caption{Quick comparison among the different supported platforms.}
+\label{t:platforms-comparison}
+\end{table}
+
+A quick consideration about the item "Good editors" for DOS. Someone
+may consider RHIDE, the DOS editor distributed with S.Ha.R.K. a good
+editor: I don't. But I also hate EDIT. Usually, I use an old editor
+called AURORA. More information at
+
+\begin{center}
+\underline{http://www-personal.umich.edu/~knassen/aurora.html}
+\end{center}
+
+Linux and Windows$^{TM}$ are quite similar, in terms of programming
+facilities. The main advantage on using FreeDOS platforms is that it
+does not require to reboot the machine to execute the application,
+while when developing under Linux or Windows$^{TM}$ it does.
+
+Cygwin or other Linux console for Windows$^{TM}$ are not currently
+and directly supported. However, the support to such platforms is not
+mandatory in the current version, since a Windows$^{TM}$ user can
+easily build the system and develop application directly from the
+Windows$^{TM}$ platform.
+
+%------------------------------------------------------------
+\section{Installation}
+\label{sec:platform-install}
+%------------------------------------------------------------
+
+The installation changes a little bit from platform to platform.
+
+%------------------------------------------------------------
+\subsection{Linux}
+\label{sec:install-linux}
+%------------------------------------------------------------
+
+\begin{enumerate}
+\item \label{linux-step1} download \texttt{shark-1.5.tar.bz2} from the S.Ha.R.K.
+web site (\underline{http://shark.sssup.it})
+\item \label{linux-step2} type \texttt{tar xvjf shark-1.5.tar.bz2}
+\item \label{linux-step3} type \texttt{cd shark}
+\item \label{linux-step4} edit the S.Ha.R.K. configuration file,
+\texttt{shark.cfg}
+\item \label{linux-step5} type \texttt{make all}
+\item \label{linux-step6} type \texttt{cd demos}
+\item \label{linux-step7} type \texttt{make}
+\end{enumerate}
+
+Some tips:
+
+\begin{itemize}
+\item Step \ref{linux-step4} is needed to setup the compiler options and
+optimize the kernel for speed and precision.
+\item Step \ref{linux-step5} builds the S.Ha.R.K. kernel, libraries, modules and
+device drivers.
+\item Finally, step \ref{linux-step7} builds the demo programs.
+\end{itemize}
+
+%------------------------------------------------------------
+\subsection{DOS}
+\label{sec:install-DOS}
+%------------------------------------------------------------
+
+The installation for the xDOS platform follows:
+
+\begin{enumerate}
+\item \label{DOS-step1} download \texttt{unzip32.exe}, \texttt{mindj333.zip}
+and
+\texttt{shark15.zip} from the S.Ha.R.K. web site.
+\item \label{DOS-step2} type \texttt{unzip32 -o mindj333.zip -d c:}
+\item \label{DOS-step3} type \texttt{cd c:$\backslash$djgpp}
+\item \label{DOS-step4} type \texttt{install.bat}
+\item \label{DOS-step5} type \texttt{setvar.bat}
+\item \label{DOS-step6} type \texttt{unzip32 -o shark15.zip -d c:}
+\item \label{DOS-step7} type \texttt{cd c:$\backslash$shark}
+\item \label{DOS-step8} edit \texttt{shark.cfg}
+\item \label{DOS-step9} type \texttt{make}
+\item \label{DOS-step10} type \texttt{cd demos}
+\item \label{DOS-step11} type \texttt{make}
+\item \label{DOS-step12} type \texttt{cd $<$demo dir$>$}
+\item \label{DOS-step13} type \texttt{x $<$demo name$>$}
+\end{enumerate}
+
+Some tips:
+
+\begin{itemize}
+\item If you already have \texttt{PkZip}, at step \ref{DOS-step2} you may
+also type \texttt{pkunzip -d -o mindj333.zip c:$\backslash$}
+\item If you change the DJGPP directory name or position,
+\texttt{install.bat} and \texttt{setvar.bat} need also to be changed.
+\item The \texttt{setvar.bat} script automatically set the environement
+variables for DJGPP; you must run \texttt{install.bat} and
+\texttt{setvar.bat} every time you reboot and start a compile
+session.
+\item After step \ref{DOS-step5}, DJGPP is installed and ready to compile
+shark.
+\item If you already have PkZip, at step \ref{DOS-step6} you may also type
+\texttt{pkunzip -d -o shark15.zip c:$\backslash$}
+\item Step \ref{DOS-step8} is needed to setup the compiler options and
+optimize the kernel for speed and precision.
+\item Step \ref{DOS-step9} builds the S.Ha.R.K. kernel, libraries, modules
+and device drivers.
+\item Finally, step \ref{DOS-step11} builds the demo programs.
+\end{itemize}
+
+In DOS real mode we suggest, even though it is not mandatory, to load
+the smartdrive utility (\texttt{smartdrv 16000 /x}) to speedup the
+disk access during all the previous steps. The \texttt{smartdrv}
+utility is available for MS-DOS$^{TM}$. For the FreeDOS environemnt
+you can use the lbacache instead.
+
+\textbf{IMPORTANT:} You need DOSLFN.ZIP
+(\underline{http://shark.sssup.it/distrib/doslfn.zip}), a TSR to use
+long file names under DOS real mode. You have to run the doslfn
+command before starting to work with S.Ha.R.K. every time the machine
+is re-booted. You don't need it only if you are inside a DOS
+emulation window (see Windows Millennium/NT/2000/XP paragraph).
+
+In real DOS environement, you can compile and run a demos without
+reboot, directly running the demo programs through the \texttt{X.EXE}
+extender from the FreeDOS command line.
+
+%------------------------------------------------------------
+\subsection{Windows Millennium/NT/2000/XP}
+\label{sec:install-win}
+%------------------------------------------------------------
+
+\begin{enumerate}
+\item download unzip32.exe,mindj333.zip and shark15.zip from the S.Ha.R.K. web
+site;
+\item go in a DOS emulation window (DOS prompt);
+\item follow the previous procedure for normal DOS environment.
+\end{enumerate}
+
+\textbf{Reminder:} YOU CAN NOT EXECUTE A S.Ha.R.K. APPLICATION
+THROUGH THE X.EXE EXTENDER WITHIN A DOS EMULATION WINDOW. So, to test
+a compiled demo programs you need to reboot with the FreeDOS
+bootdisk or something similar.
+
+%------------------------------------------------------------
+\section{How to partition the hard-disk for using with S.Ha.R.K.}
+\label{sec:hd-installation}
+%------------------------------------------------------------
+
+Even though it is often not needed and it may be unconfortable to
+setup an already partitioned machine, it may be very useful to setup
+a machine to host the S.Ha.R.K. kernel in school and university
+laboratories for teaching purposes.
+
+This section is dedicated to the setup of an hard-disk for dedicating
+a partition to the installation of S.Ha.R.K. It will explain how to
+partition and format an hard-disk in order to install a multi-boot
+environment allowing to choose between three operating systems:
+FreeDOS and S.Ha.R.K., Linux and Windows$^{TM}$. The five basic steps
+to setup the installation are:
+
+\begin{enumerate}
+\item partition the hard disk;
+\item install Windows$^{TM}$;
+\item install FreeDOS;
+\item install Linux;
+\item setup the boot loader.
+\end{enumerate}
+
+The tools needed to perform the installation are:
+
+\begin{itemize}
+\item Linux fdisk utility;
+\item a copy of Linux installation CD;
+\item a copy of Windows$^{TM}$ installation CD;
+\item some FreeDOS utilities;
+\item a copy of S.Ha.R.K.
+\end{itemize}
+
+To accomplish all the operation related to the hard-disk partition, I
+suggest to use a Linux LiveCD distribution. My favourite one is
+Knoppix, by Mark Knopper, downloadable from
+
+\begin{center}
+\underline{http://www.knoppix.org}.
+\end{center}
+
+Linux LiveCD distribution allow to use all the powerful Linux tools
+without the need of installing anything on the hard-disk.
+
+Boot the PC from the CD drive after inserting the Knoppix LiveCD into
+the drive and open a shell. You must be the root user to have the
+permissions for the next steps, so type
+
+\begin{center}
+\texttt{su}
+\end{center}
+
+with an empty password at the console prompt. Then launch the Linux
+\texttt{fdisk}, typing
+
+\begin{center}
+\texttt{fdisk /dev/hdXXX}
+\end{center}
+
+where XXX identifies your hard-drive. Typically, the command
+
+\begin{center}
+\texttt{fdisk /dev/hda}
+\end{center}
+
+will work fine. To use the \texttt{fdisk} commands do refer to the
+program help: you will need the commands to delete and create
+partition as well as to change the partition ID and write the
+partition table on the disk.
+
+I suggest to partition your HD like something as described in Table
+\ref{t:hd-partitioning}.
+
+\begin{table}[ht]
+\centering
+\begin{tabular}{|c|c|c|c|}
+\hline
+ & Partition number & Dedicated to & Type
+\\ \hline
+ & 1st & FreeDOS & FAT32
+\\
+primary partitions & 2nd & Windows & FAT32/NTFS
+\\
+ & 3rd & Linux &
+extX/Reiser/... \\ \hline
+ & 4th & Data 1 & any
+\\
+extended partition & ... & ... & ...
+\\
+ & last but one & Data n & any
+\\
+ & last & Linux swap & (if needed)
+\\
+\hline
+\end{tabular}
+\caption{Example of hard-disk partitioning.}
+\label{t:hd-partitioning}
+\end{table}
+
+\textbf{IMPORTANT:} The FreeDOS partition must be the FIRST partition
+on your disk or you should experience some problems while booting
+FreeDOS.
+
+Since \texttt{fdisk} creates all the partitions as Linux partitions,
+you must toggle the partition type of the 2nd partition to make it a
+FAT32 (LBA) or NTFS.
+
+\textbf{SUGGESTION:} Do leave all the other partition as Linux type,
+so that Windows$^{TM}$ will put all the booting stuff into the only
+partition that it can see at installation time.
+
+Now, reboot and install Windows$^{TM}$ into the only partition that
+is available for it. I only tested the 2000 and XP versions of
+Windows. If you want to install previous Windows$^{TM}$ versions (98
+or 95) I'm not sure that they will be able to boot if they are not
+installed into the first partition. However if you want to use them,
+you can skip the installation of FreeDOS, since you can use the
+MS-DOS shell to run Shark programs.
+
+After the installation of Windows$^{TM}$, boot Knoppix again and use
+\texttt{fdisk} to change the partition type of the 1st partition:
+toggle it as FAT32 (LBA) - suggested - or FAT16 if you want to test
+the filesystem capabilities of Shark.
+
+Do format the 1st partition using the Windows formatting program.
+
+Install FreeDOS. You can download all the packages from
+
+\begin{center}
+\underline{http://www.freedos.org}.
+\end{center}
+
+I suggest to download the packages and to copy them manually into the
+partition, avoiding the Installation CD or floppy. You can also use a
+S.Ha.R.K. boot CD to copy the whole FreeDOS tree onto the disk.
+
+Make a FreeDOS boot floppy using the \texttt{sys} command, executing
+a command like
+
+\begin{center}
+\texttt{sys a:}
+\end{center}
+
+Copy also the \texttt{sys.com} FreeDOS program on the floppy.
+
+Reboot the machine leaving the floppy into the drive and launch the
+command
+
+\begin{center}
+\texttt{sys x: x:$\backslash$fdosboot.img} % check the backslash
+\end{center}
+
+\textbf{ATTENTION:} "x:" refers to the drive letter of the partion in
+which FreeDOS has been installed, as seen by FreeDOS after the boot
+from floppy (check which is the right drive letter by listing the
+content of the drives with "dir x:").
+
+What you did is to created an image of the boot sector which is able
+to boot FreeDOS, but instead of overwriting the Master Boot Record
+(MBR), you writed it onto the disk.
+
+Now insert the Linux intallation disk, reboot the PC and install
+Linux. After the installation, the GRUB boot manager should be
+installed in your MBR (I did not tested other boot managers, like
+LILO).
+
+Look for the configuration file of the GRUB, \texttt{grub.conf}, that
+is
+often placed into the \texttt{/boot/grub} directory. The lines to
+boot Linux are usually added automatically by the installer. The
+lines to boot Windows$^{TM}$ look like the following
+
+\begin{verbatim}
+title Win2000
+rootnoverify (hd0,1)
+chainloader +1
+\end{verbatim}
+
+Then, add the lines to boot FreeDOS:
+
+\begin{verbatim}
+title FreeDOS - Shark
+rootnoverify (hd0,0)
+makeactive
+chainloader /fdosboot.img
+boot
+\end{verbatim}
+
+Now you are ready to install the S.Ha.R.K. distribution following the
+instructions of Section \ref{sec:platform-install}.
+
+%------------------------------------------------------------
+\section{Kernel and applications}
+\label{sec:kernel-apps}
+%------------------------------------------------------------
+
+S.Ha.R.K. currently supports the PC platform (Intel$^{TM}$ or
+AMD$^{TM}$ processors, etc.). Using the S.Ha.R.K. kernel is easy. Few
+tools are required to build the kernel, to develop new applications
+and to run existing or new applications.
+
+%------------------------------------------------------------
+\subsection{Building kernel and applications}
+\label{sec:build-kernel}
+%------------------------------------------------------------
+
+S.Ha.R.K. is written in C, so it requires a C compiler to build the
+system from the source code. Currently, S.Ha.R.K. supports the
+\texttt{GCC version 3.3}, which is the standard compiler and is
+already present in most of the Linux distributions.
+
+\textbf{ATTENTION:} the \texttt{GCC version 3.4} does not properly
+work while building the system or compiling user programs. You can
+check your GCC version by typing
+
+\begin{center}
+\texttt{gcc -v}
+\end{center}
+
+into a Linux console.
+
+Windows$^{TM}$ or FreeDOS come without their own C compiler. There
+exist a version of the GCC which runs under FreeDOS, and
+Windows$^{TM}$ too, called DJGPP and available at
+
+\begin{center}
+\underline{http://www.delorie.com/djgpp}.
+\end{center}
+
+However, the DJGPP version downloadable from the DJ Delorie website
+it is not suitable to be used with S.Ha.R.K. since it produces the
+COFF\footnote{See
+\underline{http://www.theparticle.com/cs/bc/os/elfpecoff.html}
+for some information on executable file formats.} executable file
+format only. S.Ha.R.K. needs a compiler which has to be able to
+produce the ELF file format. This is why the DJGPP has been rebuilt
+in order to produce the ELF format.
+
+\textbf{ATTENTION:} you must download the correct DJGPP version from
+the S.Ha.R.K. website.
+
+%------------------------------------------------------------
+\subsection{Executing applications}
+\label{sec:execute-app}
+%------------------------------------------------------------
+
+There are two options to run a new application or one of the demos
+distributed with S.Ha.R.K.:
+
+\begin{itemize}
+\item using the X.EXE DOS memory extender;
+\item loading the application from the GRUB boot manager.
+\end{itemize}
+
+Using X.EXE, which is available on the S.Ha.R.K. website, requires an
+xDOS platform. Supported platforms are FreeDOS and MS-DOS$^{TM}$. In
+the latter case, however, an application can be run using X.EXE only
+from a Windows$^{TM}$ 95, Windows$^{TM}$ 98 and Windows$^{TM}$ 95SE
+DOS console.
+
+\textbf{ATTENTION:} Windows$^{TM}$ Millennium/ NT/2000/ XP consoles
+can not be used to run S.Ha.R.K. applications.
+
+Using the GRUB is more complicated and, since it is particularly
+useful
+for the remote execution of S.Ha.R.K. programs, this topic will be
+covered in a dedicated section.
+
+%------------------------------------------------------------
+\subsection{Getting a DOS environment for executing S.Ha.R.K.
+applications}
+\label{sec:environment}
+%------------------------------------------------------------
+
+To execute a S.Ha.R.K. application a DOS environment is required, and
+several options are available to get it:
+
+\begin{itemize}
+
+\item
+an hard-disk can be partitioned and formatted for multi-boot, and a
+partition can be reserved to FreeDOS. This may be a tricky way, and
+it is suggested only if the users has a good knowledge of the
+involved operations. It is particularly useful to setup the
+workstations in school and university laboratories.
+
+\item
+re-booting a machine every time an execution of a S.Ha.R.K.
+application is needed with the S.Ha.R.K. boot CD or the boor floppy
+available on the S.Ha.R.K. website.
+
+The second option needs some more indications. When the machine
+restarts, a FreeDOS environment is made available. This means that it
+is possible to launch the X.EXE extender to run a S.Ha.R.K.
+application. The application itself should be put on the floppy or,
+anyway, it MUST be put on a partition with a filesystem reachable by
+the FreeDOS kernel. At the best of my knowledge, FreeDOS currently
+supports FAT16 and FAT32 filesystems only. So that, an application
+which is stored that resides on a NTFS (Windows$^{TM}$), ext2, ext3,
+ReiserFS or other Linux filesystems can not be executed using the
+boot from floppy or CD.
+
+\end{itemize}
+
+%------------------------------------------------------------
+\chapter{Using S.Ha.R.K.}
+\label{ch:using}
+%------------------------------------------------------------
+
+%------------------------------------------------------------
+\section{Your first S.Ha.R.K. application}
+\label{sec:first-app}
+%------------------------------------------------------------
+
+A typical S.Ha.R.K. application is composed by 3 main components: the
+\texttt{program} source file, the initialization source file
+(\texttt{initfile}) and the \texttt{makefile}.
+
+%------------------------------------------------------------
+\subsection{The makefile}
+\label{sec:makefile}
+%------------------------------------------------------------
+
+The makefile is the script used by the \texttt{make} command to build
+the application. Typically, the makefile is named "makefile", and you
+can build the application by simply launching the command
+\texttt{make} from the command line. However, the makefile may be
+named differently in order, for example, to maintain different make
+settings into the same directory. With a makefile named "myapp.mak",
+the application can be built typing the command \texttt{make -f
+myapp.mak}.
+
+\textbf{IMPORTANT:} To build an application, you can not launch the
+compiler directly without using the makefile, since the makefile sets
+several variables and calls several sub-routines before invoking the
+compiler.
+
+\begin{figure}
+\noindent
+\newcounter{alines}
+\begin{list}{\arabic{alines}}{\usecounter{alines}}
+\addtolength{\parskip}{-8pt}
+\hrule
+
+\item ifndef BASE \label{l1:ifndef}
+\item BASE=../.. \label{l1:def-base}
+\item endif \label{l1:endif}
+\item include \$(BASE)/config/config.mk \label{l1:inc-config}
+\item PROGS = myapp \label{l1:prog-name}
+\item include \$(BASE)/config/example.mk \label{l1:inc-example}
+\item myapp: \label{l1:build-cmd}
+\item \ \ \ \ make -f \$(SUBMAKE) APP=myapp INIT=
+OTHEROBJS="initfile.o source2.o source3.o" OTHERINCL=
+SHARKOPT="\_\_LINUXC26\_\_ \_\_PCI\_\_ \_\_INPUT\_\_ \_\_FB\_\_"
+\label{l1:make-instr}
+
+\end{list}
+\hrule
+\caption{Example of makefile.}
+\label{f:ex-makefile}
+\end{figure}
+
+The makefile contains some directives to specify the application
+name, source file names and libraries needed for building the
+application. Figure \ref{f:ex-makefile} shows an example of makefile
+for building an application called \texttt{myapp}, thus contained
+into the source file \texttt{myapp.c}. The application code is also
+contained into two source files: \texttt{source1.c},
+\texttt{source2.c}. For each of those files, the compiler produces an
+\texttt{object file}, with the ".o" extension. The object files
+required for making the application must be specified with the
+OTHEROBJS directive into the instruction at line \ref{l1:make-instr}.
+Notice that, since also the initfile contains the application source
+code (Section \ref{sec:initfile}), you must include the related
+object file name into the OTHEROBJS directive.
+
+To customize the makefile in order to build your own application, you
+must supply the program name at lines \ref{l1:prog-name} and
+\ref{l1:make-instr}, and the same name should be used for the
+instruction at line \ref{l1:build-cmd}.
+
+At line \ref{l1:def-base}, you specify the path where the S.Ha.R.K.
+kernel has been installed. Althought you can specify an absolute path
+like \texttt{/home/username/shark} for Linux or \texttt{c:$\backslash$shark},
+typically a relative path is used. In Figure \ref{f:ex-makefile}, the
+instruction at line \ref{l1:def-base} says that the base S.Ha.R.K.
+directory is located two levels before the application directory. For
+example, if S.Ha.R.K. has been installed into
+\begin{center}
+\texttt{/home/toolleeo/shark},
+\end{center}
+the application is located into
+\begin{center}
+\texttt{/home/toolleeo/shark/projects/apps}.
+\end{center}
+
+The BASE directory in the example is relative to the current
+application directory. This works fine if the application directory
+is under the S.Ha.R.K. derictory tree. If the application stays
+outside the system tree, you can use an absolute indication of the
+S.Ha.R.K. base directory, such as \texttt{/home/toolleeo/shark} instead of
+\texttt{../..}.
+
+Finally, the instruction at line \ref{l1:make-instr} specifies also
+the libraries that must be linked together the object code to build
+the whole application. In the example, the application uses the Linux
+2.6 compatibility layer, which is always required when the drivers
+are used, the PCI driver, the Input driver (to manage the input
+devices like keyboard, mouse, etc.) and the Frame Buffer driver for
+the graphical display. The list of all the available libraries can be
+found into the \texttt{\$(BASE)/lib} directory, where
+\texttt{\$(BASE)} is the S.Ha.R.K. installation directory.
+
+\textbf{ATTENTION:} when modifying the makefile, be sure to use a
+text editor which saves the TAB character and avoids editors (often
+you can configure this option into the editor preferences) which
+substitute TAB characters with spaces. This is important because
+instruction \ref{l1:make-instr} MUST be indented with a TAB
+character. Otherwise, the \texttt{make} command will not be able to
+interpret the makefile correctly.
+
+%------------------------------------------------------------
+\subsection{The initfile}
+\label{sec:initfile}
+%------------------------------------------------------------
+
+The initfile is a normal source file which contains the instruction
+for the program initialization. Initfiles include the system
+headers, initialize modules regarding the scheduling policies for
+tasks and shared resources, the graphical mode if needed, the
+keyboard and all the required devices.
+
+When the application is launched, before starting the multitasking
+mode the program must initialize the devices, the resources and the
+schedulers which will be used by the application. For doing so, the
+kernel calls the \texttt{\_\_kernel\_register\_levels\_\_} function, that
+usually registers the following modules (see the S.Ha.R.K. Kernel
+architecture Manual for more details):
+
+\begin{itemize}
+\item scheduling modules: a scheduling module implements a particular scheduling
+algorithm, for example EDF, RM, Round Robin, etc.;
+\item resource Modules: a resource module implements a shared resource access
+protocol (for example the semaphores, the mutexes, etc.);
+\item other devices, such for example the file system, and other devices that
+has to be initialized before entering the multitasking mode.
+\end{itemize}
+
+%------------------------------------------------------------
+\subsection{The program}
+\label{sec:program}
+%------------------------------------------------------------
+
+The program file is the source file containing the \texttt{main}
+function
+
+\begin{center}
+\texttt{int main(int argc, char **argv)}
+\end{center}
+
+The main function is automatically called by the kernel when the application is
+launched through the X memory extender or the GRUB. The main functions contains
+the declarations for - or calls the routine to initialize - the user tasks, the
+keyboard handler and all the components required by the application.
+
+%------------------------------------------------------------
+\section{Tips and tricks}
+\label{sec:tips}
+%-----------------------------------------------------------
+
+%------------------------------------------------------------
+\subsection{The BASE directory}
+\label{sec:base-dir}
+%------------------------------------------------------------
+
+S.Ha.R.K. uses the BASE variable to identify the directory where the
+system directory tree starts. For example, a typical installation
+under Linux may be under \texttt{/home/username/shark}; under FreeDOS the
+path would be ``c:$\backslash$shark''.
+
+Unfortunately, the OSLib component of S.Ha.R.K., which is developed
+separately from S.Ha.R.K., also requires to set a variable named BASE
+when building. Recalling the previous examples, the BASE values for
+the OSLib will be \texttt{/home/username/shark/oslib} and
+\texttt{c:$\backslash$shark$\backslash$oslib}.
+
+A problem during the kernel compilation arises if the BASE variable
+is set into the OS environment\footnote{At the FreeDOS command line,
+type ``\texttt{set}'' to get the content of the environment.}.
+
+\textbf{IMPORTANT}: when compiling S.Ha.R.K., be sure that BASE is
+not set environment variable to get no problem\footnote{At the
+FreeDOS command line, type ``\texttt{set BASE=}'' to remove an
+already set BASE variable.}.
+
+During the application development, thus when S.Ha.R.K. is already
+built and you do not need to rebuild the kernel, you may set BASE to
+point to the S.Ha.R.K. base directory. In this sistuation, you can
+move the application source code around your filesystem without
+changing the BASE definition into the makefile. See Section
+\ref{sec:makefile} for an overview on the S.Ha.R.K. makefiles.
+However, you should avoid this practice; you should prefer to set
+correctly the BASE directory into the makefile for each project you
+are working at.
+
+%------------------------------------------------------------
+\subsection{Text output}
+\label{sec:text-output}
+%------------------------------------------------------------
+
+There are few things to know for using the S.Ha.R.K.'s functions to
+display text. Four functions should be used for a safe text output
+management:
+
+\begin{itemize}
+
+\item
+\texttt{sprintf()} to write a formatted string into a generic text
+buffer (e.g., an array of chars);
+
+\item
+\texttt{cprintf()} for the regular text output while the application is in
+text mode;
+
+\item
+\texttt{grx\_text()} for the text output when the application is in
+graphical mode (to be used together with \texttt{sprintf()}, which generates
+the string to be displayed);
+
+\item
+\texttt{printk()} for displaying strings in text mode into the kernel
+and modules for debug purposes.
+
+\end{itemize}
+
+%------------------------------------------------------------
+\subsection{I/O to the filesystems}
+\label{sec:filesystem}
+%------------------------------------------------------------
+
+S.Ha.R.K. currently supports only FAT16 filesystems on IDE drivers.
+This means that, while the kernel is running, only FAT16 filesystems
+could be accessed from the application.
+
+However, typically, read/write operations to the filesystem can be
+done at the beginning or at the end of the application, to load
+initial parameters or data and to save the results (which could be
+contained in a memory buffer filled during the application
+execution). To do so, do use the functions listed into
+\texttt{include/ll/i386/x-dos.h}, and allow the user to read and
+write binary and text files.
+
+The difference between the full support of FAT16 filesystems and the
+functions of the \texttt{x-dos} library is that, while the former is
+a true driver which accesses the hard-disk hardware, the latter are
+hooks to DOS INT 21h functions. Since DOS INT 21h are not reentrant
+(basically, they can not be interrupted by the kernel), they can not
+be used while real-time tasks are running.
+% For more informations, see demos/dosfs/README.
+% Tool: wait till demos are ok
+%
+
+%------------------------------------------------------------
+\subsection{DJGPP and DOS utils}
+\label{sec:dos-utils}
+%------------------------------------------------------------
+
+The DJGPP, the compiler used by S.Ha.R.K. under DOS, does not include
+any replacement for some Unix commands required to build S.Ha.R.K.,
+like \texttt{cp}, \texttt{rm}, \texttt{mv}, etc. Those comands can be
+found easily in the Internet, but it is safer to use the ones
+included into the S.Ha.R.K. package.
+
+Someone may already have its own set of command replacements. This
+may produce several problems, since different implementations manages
+differently the special command options. This is why S.Ha.R.K. is
+guaranteed to correctly build with the tested commands only (the
+Linux versions are all right).
+
+Short anecdote\footnote{I add this anecdote since it may help in
+solving similar problems.}. The first version of the S.Ha.R.K.
+bootable CD included the correct commands got from the S.Ha.R.K.
+distribution package. It also included another version that is put
+into the ``$\backslash$fdos$\backslash$bin'' directory. Both the
+versions of the commands were reacheable through the PATH environment
+variable. However, for a mistake, the FreeDOS path was inserted into
+the PATH variable before the correct S.Ha.R.K. path, making S.Ha.R.K.
+using the wrong commands. Results: the makefiles were invoking the
+wrong command versions, producing several problems while building
+kernel and applications.
+
+%------------------------------------------------------------
+\section{From version 1.4 to 1.5}
+\label{sec:from14to15}
+%------------------------------------------------------------
+
+From the user point of view, few things are changed from the
+S.Ha.R.K. 1.4 version to the current 1.5 version. The changes that
+make an application developed for version 1.4 incompatible with the
+1.5 version are only two:
+
+\begin{enumerate}
+
+\item
+to make the new version compatible with the POSIX standard, functions
+\texttt{sys\_end()} and \texttt{sys\_abort()} have been replaced by
+the \texttt{exit(.)} function, which accepts an integer exit code
+parameter.
+
+\item
+the S.Ha.R.K. directory tree has been slightly changed.
+
+\end{enumerate}
+
+The main effect of the changes to the tree are that an application
+initfile now requires slightly different instructions to include the
+needed modules. A comparison of the instructions required for the two
+S.Ha.R.K. versions is depicted in Table \ref{t:initfile}.
+
+\begin{table}[ht]
+\centering
+\begin{tabular}{|l|l|}
+\hline
+Version 1.4 & Version 1.5
+\\
+\hline
+\#include "kernel/kern.h" & \#include "kernel/kern.h"
+\\
+\#include "modules/intdrive.h" & \#include
+"intdrive/intdrive/intdrive.h" \\
+\#include "modules/edf.h" & \#include "edf/edf/edf.h"
+\\
+\#include "modules/cbs.h" & \#include "cbs/cbs/cbs.h"
+\\
+\#include "modules/rr.h" & \#include "rr/rr/rr.h"
+\\
+\#include "modules/dummy.h" & \#include "dummy/dummy/dummy.h"
+\\
+\#include "modules/sem.h" & \#include "sem/sem/sem.h"
+\\
+\#include "modules/hartport.h" & \#include
+"hartport/hartport/hartport.h" \\
+\#include "modules/cabs.h" & \#include "cabs/cabs/cabs.h"
+\\
+\#include "modules/pi.h" & \#include "pi/pi/pi.h"
+\\
+\hline
+\end{tabular}
+\caption{The differences between inifiles in S.Ha.R.K. 1.4 and 1.5.}
+\label{t:initfile}
+\end{table}
+
+%------------------------------------------------------------
+\section{Remote execution of S.Ha.R.K. applications}
+\label{sec:remote-execution}
+%------------------------------------------------------------
+
+S.Ha.R.K. supports the Multiboot\footnote{See
+\underline{http://www.gnu.org/software/grub/manual/multiboot/} for
+more information.} standard. This means that it is possible to launch
+remotely a S.Ha.R.K. application from, for example, the
+GRUB\footnote{See \underline{http://www.gnu.org/software/grub/} for
+more information.} boot loader.
+
+Since this Section will describe how to boot a S.Ha.R.K. application
+using the GRUB, let's say something more about it, and boot loaders
+in general.
+
+In very simple words, boot loaders are programs that, taking the
+control of the machine after the system start-up, launch the
+operative system kernels. Boot loaders are particularly useful
+because they let you choose between different operative systems to
+start. Section \ref{sec:hd-installation} illustrated how to partition
+an hard-disk
+to install more than one OS. This Section will describe how to load a
+kernel (in our case, a S.Ha.R.K. application) from the network and
+run it on a remote machine.
+
+An example will explain the installation procedure and how to use
+this mechanism.
+
+%------------------------------------------------------------
+\subsection{General setup}
+\label{sec:remote-setup}
+%------------------------------------------------------------
+
+Suppose that there are two machines: computer A, where you develop
+your S.Ha.R.K. applications using the Linux platform, and computer B,
+where you want to execute the application.
+
+Computer A needs:
+
+\begin{itemize}
+\item an Ethernet connection with B;
+\item Linux;
+\item an installed and properly configured version of S.Ha.R.K.;
+\item a TFTP server.
+\end{itemize}
+
+Computer B needs:
+
+\begin{itemize}
+\item an Ethernet connection with A;
+\item an installation of the GRUB with network support.
+\end{itemize}
+
+%------------------------------------------------------------
+\subsection{Computer A setup}
+\label{sec:A-setup}
+%------------------------------------------------------------
+
+There are two important things to setup on machine A. First of all,
+the S.Ha.R.K. kernel must be compiled with the option BIOS set to
+VM86 (Virtual Memory for x86) into the shark.cfg configuration file.
+This ensures that the application will be compiled with the support
+for the multiboot.
+
+\textbf{ATTENTION}: as stated in the configuration file, the VM86
+mode is not compatible with some VGA cards (like Matrox).
+
+A TFTP server must be installed on computer A, to let B download the
+application. TFTP means Trivial File Transfer Protocol; it is a
+simplified version of FTP which permits only basic operations like
+download and upload (no directory management, etc.). Moreover, it
+works over the UDP protocol, while FTP works over TCP. Almost all
+Linux distribution have a TFTP server. I will not discuss how to
+install and run it. The only important thing to know is that,
+typically, the server lets a remote machine to download a program
+from a specific directory (e.g., /tftpboot/). The compiled S.Ha.R.K.
+program will be put into that directory.
+
+%------------------------------------------------------------
+\subsection{Computer B setup}
+\label{sec:B-setup}
+%------------------------------------------------------------
+
+First of all, let's build the GRUB for supporting the network.
+Currently, the GRUB 2 is under development. I only tested the remote
+execution with S.Ha.R.K. using the so called the GRUB Legacy, which
+is still available.
+
+Download the GRUB Legacy from
+
+\begin{center}
+\underline{ftp://alpha.gnu.org/gnu/grub/}
+\end{center}
+
+Since I only tested the behavior of the \texttt{grub-0.97.tar.gz}
+package, I suggest to use this version.
+
+After unpacking the sources on a Linux machine with
+
+\begin{center}
+\texttt{tar -xvzf grub-0.97.tar.gz}
+\end{center}
+
+you will get the \texttt{grub-0.97} directory. Do get into it using
+
+\begin{center}
+\texttt{cd grub-0.97}
+\end{center}
+
+and configure the GRUB with a command like
+
+\begin{center}
+\texttt{./configure --enable-via-rhine --disable-ffs --disable-minix
+--disable-reiserfs --disable-xfs --disable-ufs2 --disable-vstafs}
+\end{center}
+
+This instruction simply configures the GRUB to support a VIA network
+board (Rhine model) and turned off the support for many filesystems,
+like FFS, Minix, XFS and others.
+
+Of course, if you have a different network board, you need to enable
+the correct one. You can find a list of the supported network boards
+under the directory \texttt{grub-0.97/netboot}, into the
+\texttt{README.netboot} file. The GRUB developers sugget to not
+enable too many network cards all together for stability
+problems\footnote{This may be the reason because it is not safe to
+build a copy of the GRUB with the native support of all the available
+network cards.}. For the same reason, all the unused filesystems have
+been disabled. The above configuration assume that the GRUB files
+stay into a directory called \texttt{/boot/grub}, which is into an
+ext2/ext3 filesystem. If your \texttt{/boot/grub} directory on a
+filesystem of different type, you must enable the support for that
+specific filesystem.
+
+After the GRUB configuration has been correctly performed, type
+
+\begin{center}
+\texttt{make}
+\end{center}
+
+to launch the build of the GRUB.
+
+After the compilation, you will find two files, \texttt{stage1} and
+\texttt{stage2}, into two separate directories with the same name.
+You must copy the two files into the \texttt{/boot/grub} directory of
+computer B. Before copying the files, do make a backup copy of the
+existing \texttt{stage1} and \texttt{stage2}. This step assumes that
+the GRUB is already installed on computer B, which is typically done
+when you install Linux on a PC: we only want to enhance the GRUB to
+support the network boot.
+
+Then, add the following lines to the \texttt{menu.lst} script file
+into the \texttt{/boot/grub} directory:
+
+\begin{verbatim}
+ifconfig --address=192.168.0.2 --mask=255.255.255.0
+tftpserver 192.168.0.1
+rootnoverify (nd)
+kernel /shark
+boot
+\end{verbatim}
+
+Where 192.168.0.2 is the IP address assigned to computer B and
+192.168.0.1 is the IP address of computer A. Change those values to
+accomplish with the need of your local network\footnote{For example,
+avoiding duplicated IP addresses.}.
+
+Finally, reboot the machine and, at the GRUB prompt, type
+\texttt{c} to get the commad line of the GRUB, and type the
+command
+
+\begin{center}
+\texttt{install (hd0,2)/boot/grub/stage1 (hd0)
+(hd0,2)/boot/grub/stage2 0x8000 (hd0,2)/boot/grub/menu.lst}
+\end{center}
+
+This instruction install the GRUB into the Master Boot Record of your
+hard-disk. Typing \texttt{(hd0,2)} you specify that the
+\texttt{/boot/grub/} directory stays into the 3rd partition of your
+first hard-disk. You must change this value if the directory is into
+another partition or another disk\footnote{While \texttt{hd1}
+identifies the 2nd disk, \texttt{hd2} the 3rd, etc., \texttt{(hd0,0)}
+is the 1st partition of the 1st disk, \texttt{(hd0,1)} is the 2nd
+partition of the 1st disk and so on. This is a convention of the
+GRUB.}.
+
+%------------------------------------------------------------
+\subsection{Executing S.Ha.R.K. application}
+\label{sec:execution}
+%------------------------------------------------------------
+
+After the setup of the GRUB and the TFTP server, you are able to run
+a S.Ha.R.K. application by compiling the application and copying it
+into the TFTP base directory (e.g., \texttt{/tftpboot}) and calling
+it \texttt{shark}. This is required because, after the configuration
+of \texttt{menu.lst} described in Section \ref{sec:B-setup}, the GRUB
+will look for a Multiboot kernel named \texttt{shark}.
+
+Every time you reboot computer B, it will automatically look for the
+\texttt{shark} multiboot image to run it. To speed up the GRUB
+operations, you should set the remote S.Ha.R.K. application execution
+as the default option and, optionally, do set a low number of seconds
+for the GRUB initial waiting time.
+
+There are some drawbacks of the previous installation. First, the
+S.Ha.R.K. application name must be \texttt{shark}; you may change
+that name, however the point is that you must change the
+\texttt{menu.lst} to use different names. Second, the S.Ha.R.K.
+application can not use the filesystem to read and write data, so do
+not put any I/O command to file into an application remotely
+executed. Finally, the S.Ha.R.K. application can not accept command
+line parameters.
+
+%------------------------------------------------------------
+\subsection{Accepting command line parameters}
+\label{sec:command-line-parameters}
+%------------------------------------------------------------
+
+To make a remotely executed S.Ha.R.K. application to accept command
+line parameters you can exploit a feature of the GRUB which allows to
+remotely load a configuration file from the TFTP server.
+
+To obtain this result, put the following instruction into the
+\texttt{menu.lst} file on computer B:
+
+\begin{verbatim}
+ifconfig --address=192.168.0.2 --mask=255.255.255.0
+tftpserver 192.168.0.1
+rootnoverify (nd)
+configfile /menu-remote.lst
+\end{verbatim}
+
+The last instruction tells to the GRUB to download the
+\texttt{menu-remote.lst} configuration file from the TFTP server.
+
+Put a file named \texttt{menu-remote.lst} into the TFTP base
+directory of computer A (\texttt{/tftpboot/}). Put the following
+instructions unto the \texttt{menu-remote.lst}:
+
+\begin{verbatim}
+kernel /shark-app param1 param2 param3
+boot
+\end{verbatim}
+
+In this way, by editing the \texttt{menu-remote.lst} on the machine
+where you are developing your S.Ha.R.K. applications, you are able to
+change the name of the S.Ha.R.K. application that will be looked for
+by the GRUB. Moreover, you can use as many command line parameters as
+needed when the S.Ha.R.K. application starts.
+
+\bibliographystyle{alpha}
+\bibliography{../common/biblio}
+
+\end{document}
/branches/new_sharkdoc/shark-qg/shark-qg.tex
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property
Index: branches/new_sharkdoc/shark-qg/makefile
===================================================================
--- branches/new_sharkdoc/shark-qg/makefile (nonexistent)
+++ branches/new_sharkdoc/shark-qg/makefile (revision 1676)
@@ -0,0 +1,4 @@
+MAIN = shark-qg
+MAIN_NAME = shark-qg
+
+include ../common/manual.mk
/branches/new_sharkdoc/shark-qg/makefile
Property changes:
Added: svn:executable
## -0,0 +1 ##
+*
\ No newline at end of property