Subversion Repositories shark

%----------------------------------------------------------------------------

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