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