Des solutions variées répondant à  différents types de besoins

matérielle, et sur le domaine d’application.

Une première solution consiste à  ajouter un second noyau à  Linux. C’est le cas
de RTLinux et de RTAI. Ce second noyau peut être considéré comme un second système
d’exploitation, distinct de Linux, extrêmement prioritaire, qui gère les tâches
les plus urgentes. Dans cette architecture, Linux n’est pas du tout temps réel
: il ne gère que les tâches classiques non urgentes. D’après Julien Gaulmin et
Nicolas Ferre, ingénieurs chez Alcôve,  » c’est sans doute la solution la plus
exploitée et la plus répandue car elle est peu dépendante de modifications dans
le noyau Linux. Elle est utilisée pour le contrôle commande industriel, le domaine
aérospatial, la mesure scientifique, elle permet d’avoir un noyau Linux presque
inchangé et d’optimiser les sections vraiment temps réel du code. « 

Pour garantir que les process temps réel s’exécutent avant tous les autres process,
il faut modifier le comportement standard de Linux. La gestion des priorités par
le système est un facteur crucial du comportement temps réel. Une solution appelée
système de priorités fixes permet d’obtenir cet effet : on la trouve, en particulier
dans les solutions TimeSys et MontaVista. La possibilité de suspendre les interruptions
peut provoquer le non respect des process temps réel. Il faut donc les gérer de
manière très fine, ce que fait par exemple, RTLinux : le système effectue une
émulation de l’activation et de la suspension des interruptions et contrôle de
manière très rigoureuse le fonctionnement du noyau. Mais il faut bien réaliser
que ce système de double noyau introduit deux API et que les parties temps réel
de l’application ne sont pas compatibles avec le monde Linux. Cette barrière devrait
s’estomper progressivement avec les améliorations spectaculaires de performance
des processeurs qui, un jour peut-être, fourniront à  Linux lui-même des temps
de réponse de l’ordre de la microseconde.

Une autre solution consiste à  améliorer l’ordonnanceur de Linux de manière à  ce
qu’une tâche temps réel préempte tout autre process. La solution la plus radicale
consiste à  modifier le noyau Linux de manière à  rendre préemptible tout process
non critique : c’est ce qui vient d’être fait dans la dernière version de la solution
MontaVista. Mais cela peut provoquer des effets secondaires délicats. En outre,
la compatibilité avec les solutions standard Linux est perdue.

Les contraintes temporelles des applications embarquées peuvent être très
variées. Les applications les plus exigeantes demandent des temps de réponse qui
descendent jusqu’à  quelques microsecondes

Les contraintes temporelles des applications embarquées peuvent être très variées.
Les applications les plus exigeantes demandent des temps de réponse qui descendent
jusqu’à  quelques microsecondes : c’est le temps réel critique ou  » dur « . Quand
il s’agit de millisecondes, on parle plutôt de temps réel  » mou « . D’après Alcôve,
 » L’implémentation d’un comportement temps réel  » dur  » avec le noyau Linux n’est
possible qu’au prix de sévères modifications du code du noyau. Cependant, des
projets ont vu le jour pour améliorer les performances temps réel  » mou  » de Linux
notamment dans le domaine du son.  » Dans le cas des systèmes à  double noyau, le
noyau temps réel peut fournir des performances compatibles avec les contraintes
du temps réel  » dur  » par un certain nombre d’astuces comme la solution choisie
par RTLinux pour la gestion des interruptions.

Une autre solution consiste à  adresser les deux secteurs avec des produits différents.
C’est ce que fait LynuxWorks, anciennement Lynx Real-Time Systems, qui a changé
de nom pour bien montrer son engagement dans Linux. Outre son exécutif temps réel
propriétaire LynxOS, l’éditeur distribue une distribution spécifique de Linux
appelée BlueCat, dédiée aux applications temps réel  » molles « . Pour sa part,
LynxOS, qui devient compatible au niveau binaire avec Linux, convient mieux à 
des systèmes temps réel  » durs  » ; ses interfaces programmatiques, déjà  compatibles
Posix, deviennent également compatibles avec Linux.