%----------------------------------------------------------------------------
\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.