Temps rel sous LINUX

Pierre Ficheux (pierre.ficheux@openwide.fr)

Patrice Kadionik (kadionik@enseirb.fr)
Mai 2003
Rsum
Cet article a pour but de raliser un tour d'horizon des solutions temps rel dans
l'environnement LINUX. Aprs une dfinition du concept de systme temps rel, les auteurs
s'attacheront dcrire les solutions logicielles disponibles ainsi que quelques exemples de rsultats
obtenus.
Dfinition d'un systme temps rel
Temps partag et temps rel
La gestion du temps est l'un des problmes majeurs des systmes d'exploitation. La
raison est simple : les systme d'exploitation modernes sont tous multitache or ils utilisent du
matriel bas sur des processeurs qui ne le sont pas, ce qui oblige le systme partager le temps du
processeur entre les diffrentes tches. Cette notion de partage implique une gestion du passage
d'une tche l'autre qui est effectue par un ensemble d'algorithmes appel oraonnanceur
(scheauler en anglais).
Un systme d'exploitation classique comme UNIX, LINUX ou Windows utilise la
notion de temps partage par opposition au temps reel Dans ce type de systme, le but de
l'ordonnanceur est de donner l'utilisateur une impression de confort tout en s'assurant que toutes
les tches demandes sont finalement excutes. Ce type d'approche entrane une grande complexit
dans la structure mme de l'ordonnanceur qui doit tenir compte de notions comme la rgulation de
la charge du systme ou la date depuis laquelle une tche donne est en cours d'excution. De ce
fait, on peut noter plusieurs limitations par rapport la gestion du temps.
Tout d'abord, la notion de priorit entre les tches est peu prise en compte, car l'ordonnanceur a pour
but premier le partage quitable du temps entre les diffrentes tches du systme (on parle de
quantum de temps ou tick). Notez que sur les diffrentes versions d'UNIX dont LINUX, la
commande nice permet de modifier la priorit de la tche au lancement.
Ensuite, les diffrentes tches doivent accder des ressources dites partagees ce qui
entrane des incertitudes temporelles. Si une des tches effectue une criture sur le disque dur, celui-
ce n'est plus disponible aux autres tches un instant donn et le dlai de disponibilit du
priphrique n'est donc pas prvisible.
En outre, la gestion des entres/sorties peut gnrer des temps morts car une tche peut
tre bloque en attente d'accs un lment d'entre/sortie. La gestion des interruptions reues par
une tche n'est pas optimise. Le temps de latence - soit le temps coul entre la rception de
l'interruption et son traitement - n'est pas garanti par le systme.
Enfin, l'utilisation du mcanisme de memoire virtuelle peut entraner des fluctuations
importante s dans les temps d'excution des tches.
Notion de temps rel
Le cas des systmes temps rel est diffrent. Il existe un grande nombre de dfinition
d'un systme dit temps reel mais une dfinition simple d'un tel systme pourra tre la suivante :
n systme temps reel est une association logicielmateriel o le logiciel permet entre
autre une gestion aaequate aes ressources materielles en vue ae remplir certaines taches ou
1/37
fonctions aans aes limites temporelles bien precises
Un autre dfinition pourrait tre :
"n systme est ait temps reel lorsque linformation aprs acquisition et traitement
reste encore pertinente"
Ce qui signifie que dans le cas d'une information arrivant de faon rgulire (sous
forme d'une interruption priodique du systme), les temps d'acquisition et de traitement doivent
rester infrieurs la priode de rafrachissement de cette information.
Il est vident que la structure de ce systme dpendra de ces fameuses contraintes. On
pourra diviser les systmes en deux catgories :
1. Les systmes dits contraintes souples ou molles (soft real time). Ces systmes
acceptent des variations dans le traitement des donnes de l'ordre de la demi-seconde
(ou 500 ms) ou la seconde. On peut citer l'exemple des systmes multimdia : si
quelques images ne sont pas affiches, cela ne met pas en pril le fonctionnement
correct de l'ensemble du systme. Ces systmes se rapprochent fortement des
systmes d'exploitation classiques temps partag. Ils garantissent un temps moyen
d'excution pour chaque tche. On a ici une rpartition pJDOLWDLUH du temps CPU
entre processus.
2. Les systmes dits contraintes aures (hara real time) pour lesquels une gestion
stricte du temps est ncessaire pour conserver l'intgrit du service rendu. On citera
comme exemples les contrles de processus industriels sensibles comme la
rgulation des centrales nuclaires ou les systmes embarqus utiliss dans
l'aronautique. Ces systmes garantissent un temps maximum d'excution pour
chaque tche. On a ici une rpartition WRWDOLWDLUHdu temps CPU entre tches.
Les systmes contraintes dures doivent rpondre trois critres fondamentaux :
1. Le dterminisme logique : les mmes entres appliques au systme doivent produire
les mmes effets.
2. Le dterminisme temporel : un tche donne doit obligatoirement tre excute dans
les dlais impartis, on parle d'echeance.
3. La fiabilite : le systme doit tre disponible. Cette contrainte est trs forte dans le cas
d'un systme embarqu car les interventions d'un oprateur sont trs difficiles voire
mme impossibles. Cette contrainte est indpendante de la notion de temps rel mais
la fiabilit du systme sera d'autant plus mise l'preuve dans le cas de contraintes
dures.
Un systme temps rel n'est pas forcment plus rapiae qu'un systme temps partag.
Il devra par contre satisfaire des contraintes temporelles strictes, prvues l'avance et imposes
par le processus extrieur contrler. Une confusion classique est de mlanger temps rel et rapidit
de calcul du systme donc puissance du processeur (microprocesseur, micro-contrleur, DSP). On
entend souvent :
Etre temps reel cest avoir beaucoup ae puissance . aes MIPS voire aes MFLOPS
2/37
Ce nest pas toujours vrai. En fait, tre temps rel dans l'exemple donn prcdemment,
c'est tre capable d'acquitter l'interruption priodique (moyennant un temps de latence
d'acquittement d'interruption impos par le matriel), traiter l'information et le signaler au niveau
utilisateur (rveil d'une tche ou libration d'un smaphore) dans un temps infrieur au temps entre
deux interruptions priodiques conscutives. On est donc li la contrainte de dlai entre deux
interruptions gnres par le processus extrieur contrler.
Si cette dure est de l'ordre de la seconde (pour le contrle d'une raction chimique par exemple), il
ne sert rien davoir un systme base de Pentium IV ! Un simple processeur 8 bits du type micro-
contrleur Motorola 68HC11, Microchip PIC, Scenix, AVR... ou mme un processeur 4 bits fera
amplement l'affaire, ce qui permettra de minimiser les cots sur des forts volumes de production.
Si ce temps est maintenant de quelques dizaines de microsecondes (pour le traitement
des donnes issues de l'observation d'une raction nuclaire par exemple), il convient de choisir un
processeur nettement plus performant comme un processeur 32 bits Intel x86, StrongARM ou
Motorola ColdFire.
L'exemple donn est malheureusement idyllique (quoique frquent dans le domaine
des tlcommunications et rseaux) puisque notre monde interagit plutt avec un systme
lectronique de faon apriodique.
Il convient donc avant de concevoir ledit systme de connatre la dure minimale entre
deux interruptions, ce qui est assez difficile estimer voire mme impossible. C'est pour cela que
lon a tendance concevoir dans ce cas des systmes performants (en terme de puissance de calcul
CPU et de rapidit de traitement dune interruption) et souvent sur-dimensionns pour respecter des
contraintes temps rel mal cernes priori. Ceci induit en cas de sur-dimensionnement un sur-cot
non ngligeable.
En rsum, on peut dire qu'un systme temps rel doit tre prvisible (preaictible en
anglais) les contraintes temporelles pouvant s'chelonner entre quelques micro-secondes (s) et
quelques secondes
La figure suivante permet d'illustrer la notion de temps rel sur le cas particulier de l'excution d'une
tche priodique. Idalement, une tche priodique doit tre excute toutes les m secondes (son
temps d'excution reste infrieur m). Dans le cas d'un systme non temps rel, un temps de latence
apparat avant l'excution effective de la tche priodique. il varie fortement au cours du temps
(charge du systme...). Dans le cas d'un systme temps rel, ce temps de latence doit tre born et
garanti infrieur une valeur fixe et connue l'avance. Si ce n'est pas le cas, il y a un dfaut de
fonctionnement pouvant causer le crash du systme. Les diteurs de systmes temps rel donnent
gnralement cette valeur qui est fixe (si le systme est bien conu) quelle que soit la charge du
systme ou du nombre de tches en fonction du processeur utilis.
3/37
Figure 1 Tache perioaique et temps reel
Une petite exprience
L'exprience dcrite sur la figure ci-dessous met en vidence la diffrence entre un
systme classique et un systme temps rel. Elle est extraite d'un mmoire sur le temps rel ralis
par William Blachier l'ENSIMAG en 2000.
Figure 2 Test comparatif temps reeltemps partage
Le but de l'exprience est de gnrer un signal priodique sortant du port parallle du
PC. Le temps qui spare deux missions du signal sera mesur l'aide d'un compteur. Le but est de
visualiser l'volution de ce dlai en fonction de la charge du systme. La frquence initiale du signal
4/37
est de 25 Hz (Hertz) ce qui donne une demi-priode T/2 de 20 ms.
Sur un systme classique, cette demi-priode varie de 17 23 ms, ce qui donne une variation de
frquence entre 22 Hz et 29 Hz. La figure ci-dessous donne la reprsentation graphique de la mesure
sur un systme non charg puis pleine charge :
Figure 3. Reprsentation sur un systme classique
Sur un systme temps rel, la demi-priode varie entre 19,990 ms et 20,015 ms, ce qui
donne une variation de frquence de 24,98 Hz 25,01 Hz. La variation est donc beaucoup plus
faible. La figure donne la reprsentation graphique de la mesure :
Figure 4. Reprsentation sur un systme temps rel
Lorsque la charge est maximale, le systme temps rel assure donc une variation de +/-
0,2 Hz alors que la variation est de +/- 4 Hz dans le cas d'un systme classique.
Ce phnomne peut tre reproduit l'aide du programme square.c crit en langage C.
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <asm/io.h>
#define LPT 0x378
int ioperm();
5/37
int main(int argc, char **argv)
{
setuid(0);
if (ioperm(LPT, 1, 1) < 0) {
perror("ioperm()");
exit(-1);
}
while(1) {
outb(0x01, LPT);
usleep(50000);
outb(0x00, LPT);
usleep(50000);
}
return(0);
}
Le signal gnr sur la broche 2 (bit D0) du port parallle est thoriquement un signal priodique
carr de demi-priode T/2 de 50 ms. On observe l'oscilloscope le signal suivant sur un systme
non charg (AMD Athlon 1500+).
Figure 5 Generation aun signal carre sous Linux non charge
On remarque que l'on n'a pas une priode de 100 ms mais de 119,6 ms d au temps supplmentaire
d'excution des appels systme. Ds que l'on stresse le systme (criture rptitive sur disque d'un
fichier de 50 Mo), on observe le signal suivant :
6/37
Figure 6 Generation aun signal carre sous Linux charge
On observe maintenant une gigue (/itter) sur le signal gnr. La gigue maximale sur la dure de
l'exprience est de 17,6 ms. La forme du signal varie maintenant au cours du temps, n'est pas de
forme carre mais rectangulaire. LINUX n'est donc plus capable de gnrer correctement ce signal.
Il faut noter aussi que le front montant sur la figure prcdente apparat sans gigue car il a servi
comme front de synchronisation de l'oscilloscope. La gigue observe est donc voir comme la
contribution de la gigue sur front montant et sur front descendant. Si l'on diminue la valeur de la
demi-priode, la gigue devient aussi importante que cette dernire et dans ce cas, Linux ne gnre
plus aucun signal !
Cette exprience met donc en vidence l'importance des systmes temps rel pour
certaines applications critiques.
Premption et commutation de contexte
Le noyau (kernel) est le composant principal d'un systme d'exploitation multitche
moderne. Dans un tel systme, chaque tche (ou processus) est dcompose en threaas (processus
leger ou tache legre) qui sont des lments de programmes coopratifs capables d'excuter chacun
une portion de code dans un mme espace d'adressage. Chaque thread est caractris par un
contexte local contenant la priorite du thread, ses variables locales et l'tat de ses registres. Le
passage d'un thread un autre est appel changement de contexte (context switch) Ce changement
de contexte sera plus rapide sur un thread que sur un processus car les threads d'un processus
voluent dans le mme espace d'adressage ce qui permet le partage des donnes entre les threads
d'un mme processus Dans certains cas, un processus ne sera compos que d'un seul thread et le
7/37
changement de contexte s'effectuera sur le processus lui-mme.
Dans le cas d'un systme temps rel, le noyau est dit preemptif c'est dire qu'un thread
peut tre interrompu par l'ordonnanceur en fonction du niveau de priorit et ce afin de permettre
l'excution d'un thread de plus haut niveau de priorit prt tre excut. Ceci permet d'affecter les
plus hauts niveaux de priorit des tches dites critiques par rapport l'environnement rel contrl
par le systme. La vrification des contextes commuter est ralise de manire rgulire par
l'ordonnanceur en fonction de l'horloge logicielle interne du systme, ou tick timer systme.
Dans le cas d'un noyau non premptif - comme le noyau LINUX - un thread sera
interrompu uniquement dans le cas d'un appel au noyau ou d'une une interruption externe. La notion
de priorit tant peu utilise, c'est le noyau qui dcide ou non de commuter le thread actif en
fonction d'un algorithme complexe.
Les extensions POSlX
La complexit des systmes et l'interoprabilit omniprsente ncessitent une
standardisation de plus en plus grande tant au niveau des protocoles utiliss que du code source des
applications. Mme si elle n'est pas obligatoire, l'utilisation de systmes conformes POSIX est de
plus en plus frquente.
POSIX est l'acronyme de Portable Operating System Interface ou interface portable
pour les systmes d'exploitation. Cette norme a t dveloppe par l'IEEE (Institute of Electrical
ana Electronic Engineering) et standardise par l'ANSI (American National Stanaaras Institute) et
l'ISO (International Stanaaras Organisation).
Le but de POSIX est d'obtenir la portabilit des logiciels au niveau de leur code source.
Le terme de portabilite est un anglicisme driv de portability terme lui-mme rserv au jargon
informatique. Un programme qui est destin un systme d'exploitation qui respecte POSIX doit
pouvoir tre adapt moindre frais sous n'importe quel autre systme POSIX. En thorie, le portage
d'une application d'un systme POSIX vers un autre doit se rsumer une compilation des sources
du programme.
POSIX a initialement t mis en place pour les systmes de type UNIX mais d'autres
systmes d'exploitation comme hinaows NT sont aujourd'hui conformes POSIX. Le standard
POSIX est divis en plusieurs sous-standards dont les principaux sont les suivants :
+ IEEE 1003.1-1990 : POSIX Partie 1 : Interface de programmation (API) systme.
Dfinition d'interfaces de programmation standards pour les systmes de type UNIX,
connu galement sous l'appellation ISO 9945-1. Ce standard contient la dfinition de
ces fonctions (binaings) en langage C.
+ IEEE 1003.2-1992 : Interface applicative pour le shell et applications annexes.
Dfinit les fonctionnalits du shell et commandes annexes pour les systmes de type
UNIX.
+ IEEE 1003.1b-1993 : Interface de programmation (API) temps rel. Ajout du support
de programmation temps rel au standard prcdent. On parle galement de
POSIX.4.
+ IEEE 1003.1c-1995 : Interface de programmation (API) pour le multithreading.
Pour le sujet qui nous intresse, la plupart des systmes d'exploitation temps rel sont
conformes partiellement ou totalement au standard POSIX. C'est le cas en particulier des systmes
temps rel LynxOS (http ://www.lynuxworks.com) et QNX (http ://www.qnx.com). Quant LINUX, sa conformit
par rapport POSIX 1003.1b (temps rel) est partielle dans sa version standard et il ncessite
l'application de modification (ou patch) sur les sources du noyau.
8/37
Tour d'horizon des principaux systmes temps rel
Le but de cette section est deffectuer un rapide tour dhorizon des principaux systmes
d'exploitation utiliss dans les environnement embarqus. Ce tour d'horizon n'inclut pas les
systmes base de LINUX qui seront bien entendu dcrits en dtails plus loin dans l'article. Il
convient avant tout de prciser les diffrences entre noyau, excutif et systme d'exploitation temps
rel :
+ Un noyau temps rel est le minimum logiciel pour pouvoir faire du temps rel : ordonnanceur,
gestion de tches, communications inter-tches, autant dire un systme plutt limit mais
performant.
+ Un excutif temps rel possde un noyau temps rel complt de modules/bibliothques pour
faciliter la conception de l'application temps rel : gestion mmoire, gestion des E/S, gestion de
timers, gestion d'accs rseau, gestion de fichiers. Lors de la gnration de l'excutif, on choisit
la carte les bibliothques en fonction des besoins de l'application temps rel. Pour le
dveloppement, on a besoin d'une machine hte (host) et de son environnement de
dveloppement crois (compilateur C crois, utilitaires, debugger) ainsi que du systme cible
(target) dans lequel on va tlcharger (par liaison srie ou par le rseau) l'application temps rel
avec l'excutif.
+ Un systme d'exploitation temps rel est le cas particulier o l'on a confusion entre le systme
hte et le systme cible qui ne font plus qu'un. On a donc ici un environnement de
dveloppement natif.
VxWorks et pSOS
VxWorks est aujourd'hui l'excutif temps rel le plus utilis dans l'industrie. Il est
dvelopp par la socit hina River (http ://www.windriver.com) qui a galement rachet rcemment les
droits du noyau temps rel pSOS, un peu ancien mais galement largement utilis. VxWorks est
fiable, faible empreinte mmoire, totalement configurable et port sur un nombre important de
processeurs (PowerPC, 68K, CPU32, ColdFire, MCORE, 80x86, Pentium, i960, ARM,
StrongARM, MIPS, SH, SPARC, NECV8xx, M32 R/D, RAD6000, ST 20, TriCore). Un point fort
de VxWorks a t le support rseau (sockets, commandes r..., NFS, RPC...) disponible ds 1989 au
dveloppeur bien avant tous ses concurrents. VxWorks est galement conforme POSIX 1003.1b.
QNX
Dvelopp par la socit canadienne QNX Software (http ://www.qnx.com), QNX est un
systme temps rel de type UNIX. Il est conforme POSIX, permet de dvelopper directement sur
la plateforme cible et intgre l'environnement graphique Photon, proche de X hinaow System.
C/OS (micro-C OS) et C/OS ll
C/OS, dvelopp par le Canadien Jean J. Labrosse, est un excutif temps rel destin
des environnements de trs petite taille construits autour de micro-contrleurs. Il est maintenant
disponible sur un grand nombre de processeurs et peut intgrer des protocoles standards comme
TCP/IP (C/IP) pour assurer une connectivit IP sur une liaison srie par PPP. Il est utilisable
gratuitement pour l'enseignement (voir http ://www.ucos-ii.com).
Windows CE
Annonc avec fracas par Microsoft comme le systme d'exploitation embarqu qui tue
Windows CE et ses cousins comme Embedded Windows NT n'ont pour l'instant pas dtrn les
systmes embarqus traditionnels Victime d'une rputation de fiabilit approximative, Windows
9/37
CE est pour l'instant cantonn l'quipement de nombreux assistants personnels ou PDA.
LynxOS
LynxOS est dvelopp par la socit LynuxWorks (http ://www.lynuxworks.com) qui a
rcemment modifi son nom de part son virage vers LINUX avec le dveloppement de Blue Cat Ce
systme temps rel est conforme la norme POSIX.
Nucleus
Nucleus est dvelopp par la socit Accelerated Technology Inc
(http ://www.acceleratedtechnology.com). Il est livr avec les sources et il n'y pas de royalties payer pour la
redistribution.
eCOS
Acronyme pour Embeaaable Configurable Operating System, eCOS fut initialement
dvelopp par la socit Cygnus figure emblmatique et prcurseur de l'open source professionnel,
aujourd'hui rattache la socit Red Hat Software. Ce systme est adapt aux solutions trs faible
empreinte mmoire et profondment enfouies. Son environnement de dveloppement est bas sur
LINUX et la chane de compilation GNU avec conformit au standard POSIX.
Les contraintes des systmes propritaires
La majorit des systmes propritaires dcrits la section prcdente souffrent
cependant de quelques dfauts forts contraignants.
Les systmes sont souvent raliss par des socits de taille moyenne qui ont du mal
suivre l'volution technologique : le matriel volue trs vite - la dure de vie d'un processeur de la
famille x86 est par exemple de l'ordre de 12 24 mois - les standards logiciels font de mme et de
plus en plus d'quipements ncessitent l'intgration de composants que l'on doit importer du monde
des systmes informatiques classiques ou du multimdia.
De ce fait, les cots de licence et les droits de redistribution des systmes (ou royalties)
sont parfois trs levs car l'diteur travaille sur un segment de march trs spcialis, une niche
dans laquelle les produits commercialiss le sont pour leur fonction finale et non pour la valeur du
logiciel lui-mme. Contrairement au monde de la bureautique o la pression commerciale peut
inciter l'utilisateur faire voluer son logiciel frquemment - et donc payer un complment de
licence - le logiciel embarqu est considr comme un mal ncessaire souvent destin durer
plusieurs annes, en conservant une compatibilit avec du matriel et des processeurs obsoltes.
Le cot de dveloppement d'applications autour de systmes propritaires est souvent
plus lev car les outils de dveloppement sont mal connus de la majorit des dveloppeurs
disponibles sur le march du travail car non tudis l'universit. Il est donc ncessaire de recruter
du personnel trs spcialis donc rare. Les formations autour de ces outils sont galement onreuses
car trs spcialises ce qui oblige l'diteur pratiquer des cots levs pour compenser le manque
d'effet de masse.
Tout cela implique un ensemble de spcificits contraignantes pour la gestion globale
des outils informatiques de l'entreprise.
Les avantages de l'open source
Les trois points suivants de la dfinition du logiciel open source sont fondamentaux
dans le cas du logiciel embarqu et temps rel :
10/37
1. La redistribution sans royalties. Ce point rgle le problme conomique des droits de
redistribution ou royalties, trs contraignant dans le cas d'un systme distribu
grande chelle.
2. La disponibilit du code source. Ce point est encore plus fondamental car il est la
base de la conception d'un logiciel de qualit et surtout maintenable dans le temps.
3. La possibilit de raliser un dveloppement driv de ce code source. L encore,
l'open source permet de raliser des conomies substancielles en intgrant des
composants existants dans une solution industrielle.
LlNUX comme systme temps rel
Forts des arguments concernant l'open source, il est normal d'tre tent par l'utilisation
de LINUX comme systme temps rel. Outre les avantages inhrents l'open source, la fiabilit
lgendaire de LINUX en fait un candidat idal. Malheureusement, LINUX n'est pas nativement un
systme temps rel. Le noyau LINUX fut en effet conu dans le but d'en faire un systme gnraliste
donc bas sur la notion de temps partag et non de temps rel.
La communaut LINUX tant trs active, plusieurs solutions techniques sont
cependant disponibles dans le but d'amliorer le comportement du noyau afin qu'il soit compatible
avec les contraintes d'un systme temps rel comme dcrit au dbut de l'article. Concrtement, les
solutions techniques disponibles sont divises en deux familles :
1. Les patchs dits premptifs permettant d'amliorer le comportement du noyau
LINUX en rduisant les temps de latence de ce dernier. Ces modifications ne
transforment pas LINUX en noyau temps rel dur mais permettent d'obtenir des
rsultats satisfaisants dans le cas de contraintes temps rel molles . Cette
technologie est disponible auprs de diffrents projets open source et elle est
galement supporte commercialement par divers diteurs spcialiss dont le plus
connu est l'amricain MontaVista (http://www.mvista.com). La notion de noyau
premptif est intgre dans le noyau de dveloppement 2.5.
2. Le noyau temps rel auxiliaire. Les promoteurs de cette technologie considrent que
le noyau LINUX ne sera jamais vritablement temps rel et ajoute donc ce noyau
un vritable ordonnanceur temps rel priorits fixes. Ce noyau auxiliaire traite
directement les tches temps rel et dlgue les autres tches au noyau LINUX,
considr comme la tche de fond de plus faible priorit. Cette technique permet de
mettre en place des systmes temps rel durs . Cette technologie utilise par
RTLinux et son cousin europen RTAI. RTLinux est support commercialement par
FSMLabs (http://www.fsmlabs.com) qui a des relations chaotiques avec la
communaut open source cause du brevet logiciel qui couvre l'utilisation de ce
noyau auxiliaire. Pour cette raison, le projet RTAI - qui n'est pas associ une entit
commerciale - tend utiliser une technique similaire mais ne tombant pas sous le
coup du brevet.
Les patchs premptifs
Ce paragraphe prsente les deux principaux patchs permettant d'amliorer les
performances du noyau LINUX 2.4 au niveau du temps de latence pour la prise en compte d'une
interruption. Le document dcrit la mthode d'application des patchs puis commente les rsultats
obtenus avec des outils de mesures spcialiss.
11/37
Les diffrentes solutions disponibles
Cette tude se limitera aux patchs les plus utiliss dans l'environnement LINUX :
+ Le patch Prempt Kernel maintenu par Robert M. Love et disponible sur
http://www.tech9.net/rml/linux. Le principe du patch est d'ajouter systmatiquement des
occasions d'appel l'ordonnanceur et donc de minimiser le temps entre la rception d'un
vnement et l'appel la fonction schedule() (ordonnanceur LINUX).
+ Le patch Low latency maintenu par Andrew Morton et disponible sur
http://www.zip.com.au/~akpm/linux/schedlat.html. Le principe est un peu diffrent car au
lieu d'opter pour une stratgie "systmatique", les dveloppeurs du patch ont prfr
effectuer une analyse du noyau afin d'ajouter des "points de premption" subtilement placs
dans les sources du noyau afin de "casser" des boucles d'attente trop longues.
Il faut noter que l'tude s'applique uniquement au noyau 2.4.20 (dernire version stable
disponible ce jour). Des versions similaires du patch Prempt Kernel sont intgres au noyau de
dveloppement 2.5. Une fusion des deux patchs est peut tre envisageable dans le futur noyau 2.6
(information sans garantie mais voque dans certains interviews de Robert M. Love). De mme,
l'diteur MontaVista Software diffuse une version de noyau 2.4 incluant un patch premptif trs
similaire celui de Robert M. Love (qui travaille d'ailleurs chez MontaVista !).
Procdure d'application du patch
La procdure est similaire pour les deux patchs :
1. Extraire les sources du noyau LINUX dans le rpertoire /usr/src. Dans notre cas cela
donne un rpertoire /usr/src/linux-2.4.20 que l'on peut suffixer par le type de
patch. On peut ensuite positionner le lien linux-2.4 sur cette arborescence.
# cd /usr/src
# mv linux-2.4.20 linux-2.4.20_kpreempt
# rm -f linux-2.4; ln -s linux-2.4.20_kpreempt linux-2.4
2. Rcuprer le patch correspondant la version du noyau, puis appliquer le patch :
# cd /usr/src/linux-2.4
# patch -p1 < un_repertoire_de_stockage/patchfile
3. Configurer le noyau LINUX en activant les options habituelles du noyau non patch ainsi
que les options spcifiques du patch. Avant d'appliquer le patch il est ,03(5$7,) de
vrifier le bon fonctionnement du noyau non patch sur votre matriel.
Il faut ensuite configurer puis compiler le noyau avec la procdure habituelle :
# make xconfig
# make dep; make clean; make bzImage; make modules
Configuration du noyau patch Preempt Kernel
Il est conseill d'utiliser le paramtre EXTRAVERSION dfini au dbut du Makefile
du noyau, soit dans ce cas :
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 20
EXTRAVERSION = -kpreempt
12/37
ce qui permet de suffixer larborescence des modules suivant le type de noyau (ici
kpreempt) et donc de faire cohabiter plusieurs versions du noyau 2.4.20 patch sur le mme
systme.
Ensuite il convient de vrifier l'option de noyau premptif (CONFIG_PREEMPT) en
utilisant make xconfig et en validant l'option dans la rubrique Processor type ana features
comme indiqu sur la figure ci-dessous.
Figure 7 Jaliaation ae CONFIGPREEMPT
Il est galement ncessaire de valider le support RTC (Real Time Clock) car certains
outils de mesure de latence utilisent le device /dev/rtc.
Figure 8 Jaliaation au support RTC
Enfin il est ncessaire de valider l'utilisation du DMA (Direct Memory Access) sur le
bus PCI cot noyau ce qui normalement fait par dfaut. L'utilisation du DMA permet d'amliorer
fortement les performances puisque le processeur n'est plus sollicit.
Figure 9 Jaliaation au support DMA
Une fois le noyau compil, on peut l'installer par :
# cp arch/i386/boot/bzImage /boot/bzImage-2.4.20_kpreempt
# make modules_install
puis ajouter une entre supplmentaire dans le fichier /etc/lilo.conf (ou
/etc/grub.conf suivant le chargeur utilis). Dans le cas de LILO cela donne :
image=/boot/bzImage-2.4.20_kpreempt
label=linux20_kp
read-only
root=/dev/hda1
Il faut ensuite valider cette nouvelle entre en tapant :
# lilo
Configuration du noyau patch Low Latency
La configuration est trs similaire sauf que l'on utilisera le suffixe lowlat. La validation de
l'option CONFIG_LOLAT est galement dans la rubrique Processor type ana features.
13/37
Figure 10 Jaliaation ae CONFIGLOLAT
La deuxime option permet de dbrayer dynamiquement l'option en manipulant le
systme de fichier virtuel /proc, nous ne l'utiliserons pas pour l'instant.
Outils de mesure utiliss
Pour effectuer les mesure, nous utilisons principalement l'outil Latency_graph-0.2 disponible sur
http://www.linuxdj.com/latency-graph. Nous avons lgrement modifi le programme de test
testlatency.c afin d'utiliser des sorties graphiques PNG (la libgd ne supporte plus le GIF pour
des questions de licence) et de pouvoir spcifier le nom du fichier de sortie. Le principe de l'outil de
mesure est de dmarrer deux timers (30ms et 60 ms) et de mesurer la drive de ceux-ci par rapport
la priode attendue. Les mesures intressantes sont obtenues en stressant le systme, le plus souvent
par des accs disque rptitifs. Dans notre cas, nous avons utilis un petit script nomm
stress.sh bas sur la commande dd.
#!/bin/sh
while [ 1 ]
do
echo "Creating file..."
dd if=/dev/zero of=foo bs=1M count=50
sync
echo "Removing file..."
rm -f foo
sync
done
Ce script cre puis efface de manire rptitive des fichiers de 50 Mo. Une fois le
script lanc depuis une console, on pourra excuter le test en tapant dans une autre console :
testlatency -f 2.4.20_stock_stress.png
qui produit une courbe de rsultats au format PNG.
Nous utiliserons galement ponctuellement le programme realfeel2 inclus dans le
package amlat disponible sur le site du patch Low latency. Ce programme produit un historique des
temps de latence sur un nombre de points donn. On l'utilisera comme suit :
realfeel2 --samples 100000 2.4.20_stock_stress.hist
Mesures effectues
Le systme utilis est bas sur un AMD Duron 900 MHz, quip de 128 Mo de RAM,
d'un disque IDE rcent (mais bas de gamme !) et de la distribution Red Hat 7.3. Bien entendu, le
rsultat absolu de la mesure est trs dpendant de l'architecture matrielle du systme. Le but est ici
d'observer une tendance dans les rsultats.
Avant d'effectuer les tests, il convient de vrifier grce la commande hdparm si les
14/37
accs disque utilisent le DMA que nous avons valid cot noyau.

# hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 3648/255/63, sectors = 58615258, start = 0
busstate = 1 (on)
Nous pouvons positionner le DMA ainsi que deux autres paramtres d'optimisation
(cependant moins importants) avec la ligne de commande suivante:

# hdparm -d 1 -c 1 -u 1 /dev/hda
/dev/hda:
setting 32-bit I/O support flag to 1
setting unmaskirq to 1 (on)
setting using_dma to 1 (on)
I/O support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
Les options utilises sont dcrites ci-dessous dans un extrait du man haparm:
+ -d
Disable/enable the "using_dma" flag for this drive.
+ -u
Get/set interrupt-unmask flag for the drive. A setting of 1 permits the driver to unmask other
interrupts during processing of a disk interrupt, which greatly improves Linux's
responsiveness and eliminates "serial port overrun" errors.
+ -c
Query/enable (E)IDE 32-bit I/O support. A numeric parameter can be used to enable/disable
32-bit I/O support
Noyau 2.4.20 standard
Nous effectuons tout d'abord une mesure sur un noyau 2.4.20 standard. Si le systme n'est pas
stress, nous obtenons logiquement le rsultat suivant.
15/37
Figure 11 Mesure sur un systme stanaara non charge
Par contre lorsque le systme est stress par le script stresssh on observe des irrgularits sur les
courbes (36 et 66 ms).
16/37
Figure 12 Mesure sur un systme stanaara stresse
Pour se convaincre de l'utilit du DMA, la courbe ci-dessous prsente le rsultat de la mesure
lorsque le DMA n'est pas valid par hdparm. Le rsultat se passe de commentaires !
17/37
Figure 13 Mesure sur un systme stanaara stresse sans DMA
Noyau 2.4.20 avec patch Preempt KerneI
Avec le patch preempt-kernel, nous obtenons la courbe suivante :
18/37
Figure 14 Mesure avec patch Preempt Kernel stresse
Le rsultat est trs bon malgr un petit "glitch" au milieu de la courbe. Si nous
utilisons le programme realfeel2 sur le mme systme, nous obtenons le fichier d'historique
suivant sur 100000 itrations :
0.0 99828
0.1 118
0.2 5
0.3 2
0.5 3
0.6 2
0.7 1
1.1 1
2.4 1
2.5 5
2.6 5
2.7 2
2.8 4
2.9 2
3.4 1
4.0 1
6.3 1
9.5 1
11.4 1
11.9 1
12.0 1
12.1 1
12.2 1
19/37
12.3 1
12.5 1
12.7 1
12.9 1
13.3 1
13.4 2
13.6 1
13.7 1
14.3 1
15.1 1
15.2 1
Soit une latence maximale de 15 ms mais avec trs peu de points suprieurs 1 ms.
Noyau 2.4.20 avec patch Low Latency
Avec ce patch appliqu, nous obtenons la courbe suivante :
Figure 15 Mesure avec patch Low Latency stresse
Le rsultat est parfait. Si nous utilisons le programme realfeel2 sur le mme
systme, nous obtenons le fichier d'historique suivant sur 100000 itrations :
20/37
0.0 99858
0.1 134
0.2 5
0.3 3
Soit une latence maximale de seulement 0.3 ms !
Test du programme square sur les noyaux patchs
Nous avons galement effectu une mesure l'oscilloscope lors de l'utilisation du
programme square dcrit prcdemment. Dans le cas du noyau 2.4.20 modifi par le patch
Preempt Kernel et subissant la mme charge que pour les autres mesures, nous obtenons la courbe
suivante, indiquant une latence maximale lgrement suprieure 200 s.
Figure 16 Execution ae square avec le patch Preempt Kernel
Dans le cas du patch Low Latency, nous obtenons un meilleur rsultat avec une latence
maximale d'environ 80 s.
21/37
Figure 17 Execution ae square avec le patch Low Latency
Conclusion
Le patch Low Latency semble tre plus efficace que Preempt Kernel, ce qui est
galement le rsultat obtenu par d'autres tudes cites dans la partie bibliographique. Ceci tant dit,
des tudes plus approfondies sur des cas rels permettront galement de valider la stabilit des
noyaux modifis s'ils sont soumis de fortes sollicitations pendant un grand intervalle de temps. Il
conviendra plus tard de tester la version intgre au noyau 2.6 lorsque celui-ci sera disponible soit
probablement pas avant la fin de l'anne 2003.
Le systme RTLinux
Principe
Les patch tests prcdemment permettent d'amliorer les temps de latence sur la
noyau mais le concept se rapproche plus d'une amlioration de la qualit de service que du temps
rel dur. Forts de cette conclusion des dveloppeurs on choisi une stratgie totalement diffrente.
Puisque le noyau LINUX n'est dfinitivement pas un noyau temps rel, la meilleure solution est de
la faire cohabiter avec un noyau auxiliaire bas sur un vrai ordonnanceur temps rel priorits fixes.
Les tches temps rel sont grs par ce noyau et le traitement des autres tche est dlgu au noyau
LINUX, lui-mme considr comme une tche de plus faible priorit (ou iale task) par le noyau
temps rel. Le schma ci-dessous dcrit l'architecture du systme double noyau. Les interruptions
matrielles sont captes par le noyau temps rel. Si l'interruption ne correspond pas une tche
temps rel, elle est traite par le noyau LINUX.
22/37
Figure 18 Systme aouble noyau
Historique, RTLinux et la GPL
Historiquement, le premier projet utilisant ce principe est RTLinux, projet initialement
open source issu des travaux de Victor Yodaiken et Michael Barabanov l'universit du nouveau
Mexique aux Etats Unis. RTLinux a depuis fait couler beaucoup d'encre dans la communaut open
source car Yodaiken et Barabanov ont depuis cr la socit FSMLabs (http://www.fsmlabs.com)
charge d'assurer le dveloppement et le support commercial de RTLinux qui est un produit
rsolument orient industrie. Le produit est dsormais diffus en version commerciale
(RTLinux/Pro) dont les sources ne sont pas publis (sauf aux clients) mais aussi sous GPL
(appele aussi RTLinux/Free) mais il est clair que FSMLabs ne fait quasiment plus voluer la
version GPL. De plus, l'espace rserv aux composants GPL sur le serveur FSMLabs se rduit de
plus en plus au point de ne plus trouver la documentation en ligne pour la dernire version (3.2) de
RTLinux/Free.
Le dcalage entre la version commerciale et la version GPL n'est pas la seule raison
de la grogne autour de RTLinux. Les fondateurs ont par contre dpos un brevet logiciel aux Etats
-Unis concernant l'utilisation du noyau auxiliaire avec le noyau LINUX, ce qui n'est pas vraiment
bien vu par la communaut, d'autant que le produit actuel a reu le support de nombreux
contributeurs l'poque o RTLinux tait uniquement un projet open source. La licence de
RTLinux/Free affranchit cependant l'utilisateur des contraintes du brevet mais les projets
doivent bien sr tre diffuss sous GPL. Le fait est que FSMLabs est quelque peu en porte faux
avec la GPL car de part la structure de RTLinux, les tches temps rel sont dveloppes dans
l'espace du noyau LINUX, royaume de la GPL. La diffusion de modules en binaire est tolre dans
le cas de pilotes de priphriques car ceux-ci sont assez peu intimes avec les structures du noyau
LINUX. Dans le cas d'un noyau temps rel auxiliaire, les conditions sont toutes autres et le cas
RTLinux n'a pas fini de faire couler de l'encre virtuelle sur le net.
23/37
Structure et installation
Le fait est que RTLinux est cependant un bon produit, assez largement utilis pour des
produits sensibles dans le domaine des tlcommunications ou des applications militaires. Le
systme est concis et bien document. L'interface de programmation est assez simple et permet de
dvelopper des tches temps rel concises. Nous insistons sur le fait que seules les tches temps rel
sont gres par le noyau auxiliaire, les autres tches sont gres par le noyau LINUX. Du fait que les
tches temps rel se situent dans l'espace noyau, RTLinux propose des systmes de communication
de type FIFO ou mmoire partage entre les tches temps rel et l'espace utilisateur dans lequel
s'excutent habituellement les applications.
La distribution RTLinux/Free est constitue de deux lments :
1. Un patch appliquer au noyau LINUX. Ceci implique donc que la distribution est lie une
version donne du noyau LINUX sur laquelle ce patch s'applique correctement . La version 3.2
de RTLinux/Free fournit des patchs pour les noyau 2.4.0, 2.4.4, 2.4.17, 2.4.18 et 2.4.19. Il est
cependant possible d'adapter le patch une autre version si l'on est un peu entran :)
2. Un ensemble de modules LINUX constituant le noyau temps rel auxiliaire.
La procdure d'installation est dcrite dans le fichier doc/Installation.txt de
l'archive de documentation en ligne rtldoc-3.1.tar.gz, qui n'est malheureusement plus
disponible pour la distribution 3.2. Les utilisateurs de cette dernire version (qui est trs proche de
la version 3.1) devront se contenter du rpertoire doc de l'archive des sources contenant des
fichier HOWTO associs aux distributions Red Hat 7.x et SuSE 8.0. Le principe de l'installation est
cependant assez simple :
1. La premire tape est l'extraction de l'archive des sources de RTLinux/Free dans le rpertoire
/usr/src afin de conduire la cration du rpertoire /usr/src/rtlinux
2. Dans ce rpertoire, on doit installer une version de noyau supporte par RTLinux (voir le
rpertoire patches de la distribution). Il est bien entendu FONDAMENTAL d'utiliser pour cela
une arborescence de source officielle (provenant de ftp.kernel.org ou l'un de ses miroirs) et NON
PAS une arborescence fournie par un diteur de distribution (sinon le patch ne s'appliquera pas
correctement).
3. Aprs application du patch adquat, il faut ensuite paramtrer le noyau en fonction de la
configuration matrielle, exactement comme on le ferait pour un noyau standard en utilisant une
commande de type make xconfig. Il est d'ailleurs possible de rcuprer le fichier .config
d'un noyau 2.4 fonctionnel car le patch RTLinux/Free ajoute uniquement le paramtre
CONFIG_RTLINUX qui est valid par dfaut pour les architectures x86 et PowerPC. Notez
qu'il est important de NE PAS valider le support APM (Aavancea Power Management) qui
perturbe le fonctionnement de RTLinux.
Lorsque le noyau est compil et install en ajoutant une nouvelle entre au chargeur LILO ou
GRUB, il faut valider son bon fonctionnement en effectuant un redmarrage sur ce nouveau
noyau.
4. La prochaine tape est la gnration des modules spcifiques RTLinux/Free, qui sont
conformes l'API des modules du noyau LINUX. Cette action est effectue par une squence
trs proche de celle utilise pour le noyau LINUX, soit :
# make xconfig
# make dep
# make
# make devices
# make install
24/37
Dans un premier temps, il est conseill d'utiliser les options par dfaut au niveau du make
xconfig.
5. On peut ensuite charger dynamiquement les modules en utilisant la commande rtlinux, soit :
# rtlinux start
Scheme: (-) not loaded, (+) loaded
(+) mbuff
(-) psc
(+) rtl_fifo
(+) rtl
(+) rtl_posixio
(+) rtl_sched
(+) rtl_time
Notez que l'on peut passer en paramtre le nom d'un module RTLinux temps rel excuter soit
par exemple :
# rtlinux start my_rt_module
Les programmes RTLinux tant des modules, le dmarrage d'un programme correspond au
chargement du module par la commande insmod, l'arrt du programme correspond au
dchargement en utilisant la commande rmmod ou bien rtlinux stop. Le chargement
des modules peut tre vrifi par la commande :
# rtlinux status
Scheme: (-) not loaded, (+) loaded
(+) mbuff
(-) psc
(+) rtl_fifo
(+) rtl
(+) rtl_posixio
(+) rtl_sched
(+) rtl_time
La distribution RTLinux/Free inclut quelques programmes d'exemple dont un classique
Hello horla dans le rpertoire /usr/src/rtlinux/examples.
Prsentation des bases de l'APl RTLinux au travers d'un exemple
L'API de programmation RTLinux est relativement simple utiliser car elle comporte
un relativement petit nombre de fonctions. Le point le plus important, au risque de se rpter, est la
ncessiter de programmer les modules temps rel dans l'espace du noyau et non dans l'espace
utilisateur. Cette contrainte est non ngligeable car elle a de fortes implications sur la facilit de
programmation (programmer dans l'espace du noyau ncessite une grande rigueur), les outils de
debug disponibles (assez peu en fait dans l'espace du noyau) mais aussi la conformit par rapport
la GPL.
Pour notre exemple appel rtsquare, nous allons reprendre le programme de gnration
de signal carr dcrit au dbut de l'article. Cet exemple avait mis en vidence la forte influence de la
charge du systme sur la mesure du rsultat effectue grce un oscilloscope.
Un programme RTLinux est conforme l'API des modules du noyau LINUX. Il inclut
donc en premier lieu une fonction init_module, appele lors du chargement du module et une
fonction cleanup_module appele lors du dchargement.
int init_module(void)
{
pthread_attr_t attr;
25/37
struct sched_param sched_param;
/* Priorit 1 */
pthread_attr_init (&attr);
sched_param.sched_priority = 1;
pthread_attr_setschedparam (&attr, &sched_param);
/* Cration du thread applicatif */
pthread_create (&thread, &attr, bit_toggle, (void *)0);
return 0;
}
La fonction init_module effectue ici les actions suivantes:
1. Positionnement du niveau de priorit de la tche, qui est ici fix 1.
2. Cration du threaa applicatif qui dans notre cas va piloter le port parallle du PC. Nous
remarquons que la cration du thread utilise la fonction pthread_create, conforme l'API
POSIX.
void cleanup_module(void)
{
pthread_delete_np (thread);
}
La fonction cleanup_module se limite la destruction du thread applicatif. Le
code du thread est dcrit ci-dessous, prcd par les dfinitions gnrales du programme.
#include <rtl_time.h>
#include <rtl_sched.h>
#include <asm/io.h>
/* Adresse du port parallle */
#define LPT 0x378
/* Priode de sollicitation de 50 ms */
int period=50000000;
/* Valeur envoye sur le port parallle */
int nibl=0x01;
/* Identifiant du thread applicatif */
pthread_t thread;
/* Corps du thread applicatif */
void * bit_toggle(void *t)
{
/* On programme un rveil de la tche toute les 50 ms */
pthread_make_periodic_np(thread, gethrtime(), period);
while (1){
/* Ecriture de la valeur sur le port // */
outb(nibl,LPT);
/* Calcul de la valeur suivante (ngation) */
nibl = ~nibl;
/* Attente du rveil */
pthread_wait_np();
26/37
}
}
La compilation du programme seffectue grce un fichier Makefile adapt
l'environnement RTLinux/Free. Dans ce fichier, nous considrons que notre exemple est install
avec les autres exemples RTLinux/Free dans un sous-rpertoire de
/usr/src/rtlinux/examples.
all: rtsquare.o
include ../../rtl.mk
rtsquare: rtsquare.c
$(CC) ${INCLUDE} -Wall -O2 -o rtsquare.c
clean:
rm -f *.o
Lorsque le fichier rtsquare.o est gnr, nous pouvons tester l'application en
utilisant la commande rtlinux start rtsquare.
Si nous testons cet exemple dans les conditions de charge du systme LINUX standard
du dbut de l'article, nous obtenons le rsultat ci-dessous l'oscilloscope. La mesure du /itter donne
la valeur de 25.6 s compars aux 17.6 ms du noyau LINUX standard, ce qui correspond environ
un rapport 1000.
Figure 19 Resultat au test rtsquare sous RTLinux
27/37
Les FlFO de communication
De part la structure de RTLinux (tches temps rel dans l'espace noyau et tches
classiques dans l'espace utilisateur), il est ncessaire de mettre en place un systme de
communication entre les deux lments de l'application. Le plus souvent, cette communication est
effectue grce des FIFO /dev/rtfX (X variant de 0 63) cres lors de l'installation par la
commande make devices. Cot modules noyau, la FIFO est manipule l'aide de fonctions
spciales comme rtf_create et associe une fonction de traitement (ou hanaler) appele lors
de la rception d'un caractre sur la FIFO.
Dans l'espace utilisateur, la FIFO est vue comme un fichier gnralis classique
(device) et peut donc tre exploite comme telle ce qui facilite grandement la mise au point des
programmes. Le petit module ci-dessous permet d'utiliser la FIFO /dev/rtf0 dans l'espace
noyau. Cot utilisateur, on crit sur la FIFO par une simple commande echo redirige sur le device.
#include <rtl.h>
#include <time.h>
#include <pthread.h>
#include <rtl_fifo.h>
pthread_t thread;
char c;
int my_fifo_handler (unsigned int fifo)
{
int err;
char c;
/* Lecture des caractres reus */
while ((err = rtf_get (0, &c, 1)) == 1) {
rtl_printf("my_fifo_handler: got %x\n", c);
pthread_wakeup_np (thread);
}
if (err != 0)
return -EINVAL;
else
return 0;
}
void * start_routine(void *arg)
{
struct sched_param p;
p . sched_priority = 1;
pthread_setschedparam (pthread_self(), SCHED_FIFO, &p);
/* Attente infinie */
while (1)
pthread_wait_np ();
return 0;
}
int init_module(void) {
int f;
/* Cration de la FIFO et de la fonction de traitement */
f = rtf_create (0, 100);
rtf_create_handler(0, &my_fifo_handler);

return pthread_create (&thread, NULL, start_routine, 0);
}
void cleanup_module(void) {
28/37
/* Dtruit la FIFO */
rtf_destroy(0);
pthread_delete_np (thread);
}
Le systme RTAl
Historique
Le projet RTAI (pour Real Time Application Interface) a pour origine le dpartement
d'ingnierie arospatiale (DIAPM) de l'Ecole polytechnique de Milan (Politecnico di Milano). Pour
des besoins internes, Paolo Montegazza du DIAPM entreprit de dvelopper un produit inspir de
RTLinux mais intgrant quelques amliorations et corrections concernant en particulier les modes
temps rel et la gestion des nombres flottants. Contrairement RTLinux, RTAI ne fut pas
dvelopp dans le but de crer un produit commercial mais surtout afin d'viter des cots de
licences sur des RTOS propritaires comme QNX, alors utilis au DIAPM.
Du fait de cette optique de dveloppement interne, l'architecture actuelle de la
distribution RTAI apparat comme plus complexe tant au niveau de la dfinition de l'API (syntaxe et
nombre d'appels) et de la position par rapport aux licences (GPL et LGPL). Il est clair aussi que
RTAI est rapidement apparu aux yeux des responsables du projet RTLinux (Yodaken et Barabanov)
comme un redoutable concurrent, sachant que RTLinux avait lui une vocation commerciale. Suite
la mise en place du brevet logiciel sur RTLinux, la position de RTAI est devenu quelque peu
inconfortable et jusqu' la refonte rcente de RTAI autour du micro-noyau ADEOS (pour remplacer
la couche initiale RTHAL), le brevet logiciel FSMlabs apparaissait comme une pe de
Damocles au dessus de RTAI.
Similitudes et diffrences avec RTLinux : LXRT
La structure de RTAI est proche de celle de RTLinux. De mme, les fonctionnalits du
type FIFO de communication ou mmoire partage sont galement disponibles avec RTAI.
Cependant, les dveloppeurs de RTAI ont rcemment fait un effort particulier sur une
extension appele LXRT (LinuX Real Time) permettant de dvelopper des tches temps rel dans
l'espace utilisateur et non plus dans l'espace noyau. Ce dernier point est extrmement intressant
tant au niveau de la licence (il n'y a plus d'embarras avec la GPL contrairement au cas de RTLinux)
que de la facilit de dveloppement car nous savons que dvelopper dans l'espace noyau est
relativement plus complexe.
Au niveau des performances, nous verrons dans les exemples que les rsultats par
rapport au mme programme dvelopp dans l'espace noyau sont trs honorables et ce bien que
LXRT soit encore en cours d'volution.
Structure et installation
La structure de RTAI tant proche de celle de RTLinux (noyau LINUX modifi co-
existant avec un ordonnanceur temps rel) la procdure d'installation est proche de cette de
RTLinux. Dans ce document, nous utiliserons la dernire version diffuse ce jour sur
http://www.rtai.org soit la 24.1.11. Lorsque l'archive est extraite (en gnral sur
/usr/src/rtai-24.1.11), la procdure d'installation est dcrite dans le fichier
README.INSTALL.
La principale diffrence est la contrainte concernant le compilateur gcc utiliser. Le
fichier GCC-WARNINGS indique que le compilateur conseill est le 2.95.3. Le compilateur 2.96
29/37
fourni avec la Red Hat 7.x nest pas utilisable. Les compilateurs gcc 3.x sont susceptibles de
marcher mais le rsultat n'est pas garanti. Si l'on a un compilateur non support, le mieux est donc
d'installer la version 2.95.3 sur un rpertoire alternatif. Dans notre cas (Red Hat 7.3) nous avons
install ce compilateur compil partir des sources GNU sur l'arborescence /usr/local.
1. Comme pour RTLinux, la premire tape consiste construire un noyau intgrant le patch RTAI
adapt. Le rpertoire patches de la distribution 24.1.11 contient des fichiers de patch pour le
dernier noyau LINUX stable ce jour, soit le 2.4.20. C'est ce moment l qu'il faut choisir entre
l'ancienne technologie RTHAL et la nouvelle technologie ADEOS. Notez que le choix n'a pas
d'influence sur l'API utilisable dans les applications RTAI, qui restent compatibles au niveau du
code source. Pour nos essais, nous avons utilis la nouvelle technologie ADEOS.
2. Avant de recompiler le noyau modifi, il convient de valider l'option adquate en fonction de la
technologie choisie dans le menu General Setup dans le cas de ADEOS ou Processor type ana
features pour RTHAL. Le patch effectue automatiquement la modification du champ
EXTRAVERSION du fichier Makefile du noyau LINUX. Ce champ ne DOIT PAS tre
modifi ensuite sous peine d'chec de la suite de l'installation.
3. Aprs compilation et installation du noyau, il convient de redmarrer le systme avec ce noyau
afin de vrifier son bon fonctionnement.
4. La compilation des modules RTAI passe par la configuration via la commande :
# make menuconfig
au niveau du rpertoire des sources.
5. Aprs validation des options par dfaut, on poursuit la compilation par les commandes :
# make dep; make; make install; make dev
Le systme est alors prt l'excution des exemples dans le rpertoire examples ou du
programme de mesure de latence dans le rpertoire latency_calibration.
Adaptation de l'exemple prcdent l'APl de RTAl
Dans le paragraphe concernant RTLinux, nous avons prsent le petit programme
rtsquare qui gnre un signal carr priodique sur le port parallle du PC. L'API de RTAI tant
quelque peu diffrente de celle de RTLinux, le programme demande quelques modifications. Les
lignes suivantes prsentent la version RTAI du programme rtsquare. La principale diffrence est
la moindre compatibilit avec la syntaxe POSIX, de ce fait, l'API RTAI apparat comme plus
spcifique que celle de RTLinux. Une API POSIX existe dans RTAI au niveau des tches noyau
mais celle-ci est incomplte et les efforts de dveloppement se portent aujourd'hui plus vers LXRT
que vers l'API noyau.
#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/io.h>
#include <rtai.h>
#include <rtai_sched.h>
#define RT_PRIORITY 0
#define RT_STACK_SIZE 1000
#define LPT 0x378
#define PERIOD 50000000 /* 50 ms = 50 x 1000000 ns */
int nibl=0x01;
static RT_TASK task;
30/37
static void bit_toggle(int t)
{
while (1){
outb(nibl,LPT);
nibl = ~nibl;
/* Attente du rveil */
rt_task_wait_period();
}
}
int init_module(void)
{
RTIME now, tick_period;
/* A commenter */
rt_set_oneshot_mode();
/* Cration de la tche */
if (rt_task_init(&task, bit_toggle, 0, RT_STACK_SIZE, RT_PRIORITY, 0, 0) < 0)
rt_printk ("init_module: rt_task_init error\n");
/* Dmarrage du timer en calculant tout d'abord la valeur de la priode en
codage interne RTAI (RTIME)
*/
tick_period = start_rt_timer(nano2count(PERIOD));
now = rt_get_time();

/* La tche devient priodique sur la valeur donne */
if (rt_task_make_periodic(&task, now, tick_period) < 0)
rt_printk("task_make_periodic error\n");
return 0;
}
void
cleanup_module(void)
{
stop_rt_timer();
rt_task_delete(&task);
}
Au niveau du fichier Makefile, la syntaxe est similaire celle de RTLinux :
CC=gcc
RTAISRC=/usr/src/rtai-24.1.11
KERNELSRC = /lib/modules/$(shell uname -r)/build
CFLAGS=-I$(RTAISRC)/include -I. -D__KERNEL__ -I$(KERNELSRC)/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-
frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE
all: rtsquare_rtai.o
clean:
rm -f *.o *~
Le chargement du module s'effectue grce au script rt_modprobe disponible dans
dans le rpertoire scripts de la distribution RTAI, soit :
# rt_modprobe rtsquare_rtai.o
Pour arrter la tche temps rel, il suffit de dcharger le module grce la
commande rmmod ou bien l'aide du script rt_rmmod. Le rsultat de la mesure de latence
31/37
effectue grce l'oscilloscope est donn sur la figure suivante. La valeur maximale de latence se
situe aux environ de 25 s ce qui est quivalent au rsultat obtenu avec RTLinux.
Figure 20 Resultat au test rtsquare sous RTAI (moae noyau)
Adaptation de l'exemple LXRT
Un document d'introduction la programmation sous LXRT est disponible sur
http://people.mech.kuleuven.ac.be/~psoetens/portingtolxrt.html. Le principe de LXRT est de
conserver les appels de l'API RTAI noyau tout en effectuant bien sr quelques adaptations vu que
nous avons maintenant affaire un programme en mode utilisateur et non plus un module noyau. Le
code source de la version LXRT du programme rtsquare est dcrit ci-dessous. La structure du
programme est trs comprhensible. Un point important est l'utilisation de la fonction
rt_make_hard_real_time permettant de placer la tche sous le contrle de l'ordonnanceur
temps rel.
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <sched.h>
#include <sys/mman.h>
#include <math.h>
#include <signal.h>
#include <sys/io.h>
#define KEEP_STATIC_INLINE
#include <rtai_lxrt_user.h>
#include <rtai_lxrt.h>
32/37
#define LPT 0x378
#define PERIOD 50000000 /* 50 ms = 50 x 1000000 ns */
int nibl=0x01;
static RT_TASK *task;
static void got_sigint ()
{
rt_make_soft_real_time();
rt_task_delete (task);
exit (0);
}
main (int ac, char **av)
{
RTIME now, tick_period;
unsigned long task_name;
/* Signal dinterruption du programme */
signal (SIGINT, got_sigint);
rt_set_oneshot_mode();
task_name = nam2num("RTSQUARE_LXRT");
mlockall(MCL_CURRENT | MCL_FUTURE);
if (!(task = rt_task_init(task_name, 1, 0, 0))) {
rt_printk ("init_module: rt_task_init error\n");
exit (1);
}

tick_period = start_rt_timer(nano2count(PERIOD));
printf ("tick_period = %ld\n",(long)tick_period);
now = rt_get_time();
if (rt_task_make_periodic(task, now, tick_period)) {
printf("task_make_periodic error\n");
exit (1);
}
/* L'appel ioperm est ncessaire puisque nous sommmes en
mode utilisateur */
rt_allow_nonroot_hrt();
if (ioperm (LPT, 1, 1) < 0) {
perror("ioperm()");
exit (1);
}
/* Passage en mode temps rel */
rt_make_hard_real_time();
while (1){
outb(nibl,LPT);
nibl = ~nibl;
rt_task_wait_period();
}
}
Le fichier Makefile utilis est dcrit ci-dessous :
CC=gcc
LIBLXRT=../../lxrt/lib/liblxrt.a
CFLAGS= -g -I /usr/src/rtai-24.1.11/include -I. -I/usr/src/linux-2.4/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
33/37
-fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686
all: rtsquare_lxrt.o
$(CC) -o rtsquare_lxrt rtsquare_lxrt.o $(LIBLXRT)
clean:
rm -f *.o *~
L'excution du programme ncessite le chargement des modules principaux de RTAI
ainsi que du module LXRT. Le lancement du programme peut donc tre effectu par un script
similaire celui dcrit ci-dessous :
#!/bin/sh
insmod rtai
insmod rtai_sched
insmod rtai_lxrt_old
./rtsquare_lxrt
Vu que le programme est excut dans l'espace utilisateur, il pourra tre interrompu par
un signal classique, comme un SIGINT obtenu par la combinaison de touches Ctrl-C. Le rsultat de
la mesure l'oscilloscope donne le rsultat suivant. Le temps de latence maximal constat est de 55
s ce qui est moins bon qu'en mode noyau mais trs acceptable pour un bon nombre d'applications.
Figure 21 Resultat au test rtsquarelxrt sous LXRT (moae utilisateur)
Cas particulier des microcontrleurs (Clinux)
La distribution Clinux a dj fait le cadre d'une prsentation dtaille dans Linux
Magazine de fvrier 2002. Clinux est aujourd'hui l'une des distributions les plus utilises comme
Linux embarqu.
34/37
Clinux (prononcer you see Linux ) est l'acronyme de Micro Controller Linux
Le projet Clinux lanc en janvier 1998 est un portage de Linux version 2.0.x originellement sur
des processeurs ne possdant d'unit de gestion mmoire MMU (Memory Management nit).
Cest en fait la base un portage de Linux sur microcontrleur Motorola 68328 et drivs que l'on
trouvait par exemple dans les ordinateurs de poche (Hanahela) PalmPilot.
Outre la famille Motorola 683xx, il existe maintenant des portages Clinux pour processeurs
Motorola ColdFire, i960 d'Intel, ARM7TDMI et depuis peu NIOS d'Altera.
Clinux bas sur le noyau Linux 2.4.x est maintenant oprationnel.
Cartes cibles pour Clinux
PIateforme origineIIe : Ie kit Csimm
Les responsables du projet Clinux ont propos originellement une plateforme
matrielle des fins de tests : le kit Csimm. Ce kit comprend un module qui se prsente sous la
forme d'une barrette SIMM 30 broches. Le module Csimm se compose de :
+ Un microcontrleur DragonBall EZ (68EZ328) bas sur un cur Motorola 68000 16 MHz. Il
intgre un contrleur de DRAM, un port srie (interface RS.232), une interface SPI, un
contrleur LCD (rsolution QVGA), une sortie Timer et une sortie PWM.
+ Jusqu 18 E/S parallles.
+ Une horloge Temps Rel calendrier.
+ De la mmoire dynamique DRAM de 8 Mo.
+ De la mmoire FLASH de 2 Mo.
+ Une interface Ethernet IEEE 802.3 10BaseT.
Le module Csimm est commercialis par Arcturus Networks Inc sous forme dun kit
de dveloppement comprenant le module Csimm, un carte dassemblage / dveloppement (kit
Cgardener), le CD de dveloppement, lalimentation au prix de 495 USD
(https://shop.arcturusnetworks.com/ucsimm.dragonball.ez.shtml). A des fins d'enseignement, il
existe le kit Cacademix correspondant au kit prcdent avec un manuel de TP utilis par des
universits amricaines et vendu 295 USD (https://shop.arcturusnetworks.com/ucacademix.shtml).
Figure 22. Moaule Csimm
PIateformes drives
La socit Arcturus Networks Inc propose aussi d'autres kits plus performants. On
peut citer :
35/37
+ Le kit Cdimm base d'un microcontrleur DragonBall VZ (68VZ328) 33 MHz
(https://shop.arcturusnetworks.com/ucdimm.dragonball.vz.shtml).
+ Le kit Cdimm base d'un microcontrleur ColdFire 5272
(https://shop.arcturusnetworks.com/coldfire5272.shtml).
+ Le kit ARM7TDMI base du processeur ATMEL AT91 ARM7TDMI
(https://shop.arcturusnetworks.com/arm7tdmi.development.kit.shtml).
Autres pIateformes
Clinux peut aussi tre mis en oeuvre sur des cartes (d'valuation) base de processeur ColdFire.
On peut citer les cartes suivantes :
+ Les cartes Arnewsh SBC5206 et SBC5307.
+ Les cartes Motorola MCF5206eLITE, MCF5206C3, MCF5307C3, MCF5407C3 (1000 euros
environ), MCF5272C3, MCF5282C3.
+ Les cartes Lineo eLIA 5307, NETtel et SecureEdge.
+ La carte Netburner CFV2-40.
Extension temps rel pour Clinux
L'extension temps rel de Clinux ne fait malheureusement pas partie intgrante du
projet pour des raisons videntes de maintenance : prise en compte de la version du noyau LINUX
avec la prise en compte de la version de l'extension temps rel (RTAI, RTLinux) avec la prise en
compte de la version du portage de Clinux pour un processeur cible particulier !
Quelques portages existent pour des versions de Clinux et processeurs cibles bien prcis :
1. Un portage de RTLinux sous Clinux existe avec les restrictions suivantes : noyau 2.0.38 et
processeur Motorola DragonBall. Le patch pourra tre rcupr l'adresse suivante :
https://courseware.vt.edu/users/binoy/4984/project1.html.
2. Un portage de RTAI sous Clinux existe aussi dans le cas particulier suivant : processeur
Motorola Coldfire 5272. Le portage a t intgr dans la distribution officielle RTAI 24.1.11
dans la branche arch/m68knommu de la distribution RTAI. La procdure de compilation est
dcrite dans le fichier READMEm68knommu. L'extension temps rel RTAI doit tre mise en
oeuvre sur une carte Motorola MCF5272C3. Des informations supplmentaires donnes par B.
Kuhn responsable du portage sont disponibles l'adresse
http://www.uclinux.org/~bkuhn/Platforms/Coldfire/tarifa/20020227/README.
Des mesures de temps de latence dans ce cas trs particulier ne sont pas disponibles car
le kit Csimm des auteurs est tomb en panne pendant les tests :( Les rsultats sont priori
similaires ceux trouvs avec RTAI sur PC.
Conclusions et perspectives
Les exemples prsents dans cet article indiquent clairement que LINUX occupe une
place de plus en plus importante dans le monde des systmes d'exploitation temps rel.
LINUX n'est pas fondamentalement un systme d'exploitation temps rel car trop
gnraliste. Par application de diffrents patchs (low latency preempt kernel), il est possible d'avoir
un systme LINUX temps rel mou. Il est possible d'avoir un systme LINUX temps dur en utilisant
36/37
les extensions temps rel RTLinux et RTAI. Le choix final se fera en fonction des contraintes
temporelles imposes par le processus contrler depuis LINUX en prenant aussi en compte la
complexit de mise en oeuvre dans chaque cas (configuration du noyau, criture de l'application
temps rel).
Nous nous sommes attachs la description des technologies les plus utilises (et galement
disponibles en open source) mais d'autres systmes plus ou moins propritaires s'appuient galement
sur LINUX pour offrir des fonctionnalits temps rel. Nous pouvons citer par exemple le systme
Jaluna 2, rcemment prsent par l'ex-quipe de Chorus Systmes et qui prsente une architecture
extrieurement similaire celle de RTLinux ou RTAI (noyau LINUX associ un noyau auxiliaire
temps rel).
Du cot de RTAI, nous pensons que l'volution vers ADEOS et LXRT permettra
rapidement (d'ici quelques mois) de faciliter la migration d'un environnement propritaire vers un
systme entirement open source sans rencontrer les soucis techniques et lgaux du dveloppement
industriel dans l'espace du noyau LINUX.
Remerciements
Philippe Gerum (rpm@xenomai.org) contributeur majeur des nouvelles versions de
RTAI intgrant la technologie ADEOS. Architecte nettoyeur de la future distribution RTAI :)
Bibliographie
+ Site web de Patrice Kadionik sur
http://www.enseirb.fr/~kadionik
+ Ouvrage Linux Embarque par Pierre Ficheux aux ditions Eyrolles
+ Low-Latency 24x with ALSA HOhTO par Paul Winkler sur
http://www.djcj.org/LAU/guide/Low_latency-Mini-HOWTO.php3
+ Linux scheauler latency par Clark Williams sur
http://www.linuxdevices.com/articles/AT8906594941.html
+ Realfeel Test of the Preemptible Kernel Patch par Andrew Webber sur
http://www.linuxjournal.com/article.php?sid=6405
+ Can Linux be a real-time operating system ? par Kevin Morgan sur
http://www.linuxdevices.com/articles/AT5152980814.html
+ Real-Time ana Embeaaea Guiae par H. Bruyninckx.
http://people.mech.kuleuven.ac.be/~bruyninc/rthowto
+ Site de FSMlabs/RTLinux.
http://www.fsmlabs.com
+ Site du projet RTAI.
http://www.rtai.org
+ Site du projet ADEOS.
http://www.nongnu.org/adeos
+ Le temps rel par William Blachier sur
http://www-ensimag.imag.fr/cours/Systeme/docs.etudiants.html
37/37