Subversion Repositories shark

Rev

Details | Last modification | View Log | RSS feed

Rev Author Line No. Line
1676 tullio 1
%----------------------------------------------------------------------------
2
\chapter{Introduction}
3
%----------------------------------------------------------------------------
4
 
5
Device drivers are a critical part of Real-Time Systems. Trying to fit an IRQ
6
and a timer handler, coming from a device, inside a task context, it is a
7
priority for OS like S.Ha.R.K. If we design these drivers considering possible
8
preemptions, exectution times and other Real-Time contraints, a schedulability
9
test can guarantie our system. Buf if we must reuse a source code from
10
third-party drivers makers, without having no knowledge about the driver timing
11
behaviour, with possible non-preemptable critical section, it is very difficult
12
to impose contraints for a schedulability analisys.
13
 
14
The S.Ha.R.K. drivers are mainly ported from Linux 2.6. We projected and tested
15
a Linux 2.6 Emulation Layer. This Layer gives an indipendent environement, where
16
it is possible to compile the original drivers without conflicts with S.Ha.R.K.
17
and OSlib. An interface glue-code allows to access the drivers API.
18
 
19
\vspace{10mm}
20
 
21
\includegraphics[scale=0.3]{images/driver1.eps}
22
 
23
\vspace{10mm}
24
 
25
The Emulation Layer needs a specific kernel module to run. This module has two
26
important objectives:
27
 
28
\begin{itemize}
29
\item To create an high priority execution context for the drivers IRQ and timer
30
handlers.
31
\item To maintain the drivers behaviour inside specific Real-Time constraints,
32
avoiding that a possible malfuncition or resource abuse cause a system failure.
33
\end{itemize}
34
 
35
Both of these points are guaranteed through the INTDRIVE module. A description of
36
the IntDrive technology is also available in \cite{Fac05}.
37
 
38
As described inside the module documentation, IntDrive is an high priority
39
module specifically designed to handle the drivers requests. Usign the
40
hierarchial capabilities of S.Ha.R.K., the IntDrive module is indepented from
41
the main system scheduler, so EDF, RM and all the other modules can be used to
42
schedule the application tasks.
43
 
44
To load the Emulation Layer, IntDrive must be present inside the system.
45
 
46
\begin{verbatim}
47
#define INTDRIVE_Q 1000
48
#define INTDRIVE_U 0.1*MAX_BANDWIDTH
49
#define INTDRIVE_FLAG 0
50
 
51
TIME __kernel_register_levels__(void *arg) {
52
    LEVEL EDF_level;
53
 
54
    INTDRIVE_register_level(INTDRIVE_Q, INTDRIVE_Q, INTDRIVE_U, INTDRIVE_FLAG);
55
    EDF_level = EDF_register_level(EDF_ENABLE_ALL);
56
}
57
\end{verbatim}
58
 
59
After the IntDrive registration, the initialization procedure can begin.
60
 
61
\section{Driver Initialization}
62
 
63
The initialization of a drivers should be done inside the \texttt{initfile,}
64
before entering inside the real-time application. During initialization the
65
devices can lock the system for an unpredictable amount of time so any used
66
device should be ready before the real-time tasks are scheduled.
67
 
68
S.Ha.R.K. standard \texttt{initfile} suggests a possible implementation:
69
 
70
\begin{verbatim}
71
TASK __init__(void *arg) {
72
    struct multiboot_info *mb = (struct multiboot_info *)arg;
73
    set_shutdown_task();
74
    device_drivers_init();
75
    sys_atrunlevel(call_shutdown_task, NULL, RUNLEVEL_SHUTDOWN);
76
    __call_main__(mb);
77
 
78
    return NULL;
79
}
80
 
81
int device_drivers_init() {
82
    KEYB_PARMS kparms = BASE_KEYB;
83
 
84
    LINUXC26_register_module(TRUE);
85
    PCI26_init();
86
    INPUT26_init();
87
    KEYB26_init(&kparms);
88
 
89
    return 0;
90
}
91
\end{verbatim}
92
 
93
The \textbf{device\_drivers\_init()} calls all the initialization functions.
94
LINUXC26 is the Linux Emulation Layer and it must be loaded as first. The
95
initialization order follows the driver dependence tree of Figure
96
\ref{fg:deptree}. If this order is not respected, the initialization procedure
97
fails.
98
 
99
\vspace{10mm}
100
 
101
\begin{figure} \includegraphics[scale=0.3]{images/driver2.eps}
102
\caption{Drivers dependeces tree}
103
\label{fg:deptree}
104
\end{figure}
105
 
106
\vspace{10mm}
107
 
108
%----------------------------------------------------------------------------
109
\section{Driver Shutdown}
110
%----------------------------------------------------------------------------
111
 
112
Another critical point is the shutdown sequence. When \texttt{} a \texttt{exit()}
113
is called the system should close the device drivers as soon as possible.
114
Unfortunately the driver shutdown must be executed when the kernel is still in
115
multitasking mode.
116
 
117
\begin{verbatim}
118
int device_drivers_close() {
119
   KEYB26_close();
120
   INPUT26_close();
121
 
122
   return 0;
123
}
124
\end{verbatim}
125
 
126
The RUNLEVELS of S.Ha.R.K. gives the possibility to implement a safe and
127
trasparent procedure to shutdown the system without compromise the drivers
128
stability. As the initiliazation, the shutdown sequence must follow the
129
dependence order.
130
 
131
\begin{figure}
132
\includegraphics[scale=0.5]{images/driver3.eps}
133
\caption{Shutdown sequence}
134
 
135
\label{fg:shutdown}
136
\end{figure}
137
 
138
The flow chart of Figure \ref{fg:shutdown} shows the steps to reach a safe exit.
139
Anyway if the system is overloaded during the exit procedure, the shutdown task
140
cannot be scheduled. A possible solution is to give high priority to the
141
shutdown task, or to design an application that doesn't reach the CPU
142
saturation. If the shutdown task doesn't execute a timeout (default 3 seconds)
143
force the system exit.