Premiers pas avec Xenomai

Comment alors faire cohabiter ces deux OS sur le même matériel ? Pour l'accès au CPU et à la mémoire, il n'y a pas de problème car Linux est une tâche. Mais si une interruption (timer, carte…) arrive, qui va la traiter ?

La solution consiste à intercaler une couche entre le matériel et les systèmes d'exploitation. Cette couche de virtualisation (ou hyperviseur, ou encore couche d'abstraction matérielle) s'appelle ADEOS.

ADEOS est un nanokernel(20) qui va capturer les évènements pour ensuite les dispatcher vers Xenomai ou Linux, mais pas dans n'importe quel ordre ! Le but étant tout de même d'avoir un OS temps réel, il est impératif que Xenomai soit le premier à les traiter. Si elles ne sont pas pour lui, elles sont alors « passées » à Linux.

Le lecteur attentif que vous êtes aura remarqué le changement de terminologie entre le début et la fin du paragraphe : on est passé d'interruptions à évènements. Cette généralisation sera expliquée par la suite.

Très concrètement, ADEOS(21) se présente sous la forme d'un patch du noyau Linux. Son arborescence de développement est distincte de Xenomai, ses évolutions sont assurées par Philippe Gerum.

En théorie, la virtualisation peut faire cohabiter en toute indépendance plusieurs OS sur le même matériel. Or, que veut-on ? Réponse : faire du temps réel avec Linux afin de profiter de tout l'environnement non temps réel. Intuitivement, on sent bien qu'il faut faire un lien entre les deux. Oui, mais comment ? Par les ressources utilisées !

Pour l'instant, chacun est tranquillement chez soi : les tâches Xenomai dans leur scheduler, idem pour les tâches Linux. Imaginons, un instant qu'une impétueuse tâche Xenomai cherche à obtenir la date. La ressource « date » appartient au noyau Linux et on ne peut pas aller la chercher directement depuis Xenomai, il se peut en effet qu'elle soit en cours de mise à jour et donc invalide ! Il faut par conséquent passer par un appel système Linux. Un peu idiot me direz-vous, puisqu'on va retomber sur le problème de performance de Linux pour du temps réel. Remettons la polémique à plus tard et attardons-nous plutôt sur le fonctionnel.

Comment traiter les appels système Linux depuis les tâches Xenomai ? Les appels système regroupent les accès à des ressources partagées (terminal, couche réseau…) dont la concurrence d'accès est gérée par Linux. Or, Linux ne connaît pas les tâches Xenomai !!!

La solution consiste à déplacer les tâches d'un scheduler à l'autre en fonction des ressources utilisées. Une tâche créée via l'API Xenomai pourra s'exécuter sous Linux, ce mécanisme totalement transparent est appelé shadow threading.

Une tâche schedulée par Xenomai est dite en primary mode.
Une tâche Xenomai schedulée par Linux est dite en secondary mode (22).
Une tâche Linux schedulée par Xenomai est dite... ha !ha ! c'était un piège, ça n'existe pas.
Le passage d'un mode à l'autre est fonction des ressources accédées et donc des appels système Xenomai ou Linux.

Les termes primary mode et secondary mode sont hérités de la terminologie ADEOS qui appelle les OS reposant sur lui des domaines (domains). Comme nous l'avons vu un peu plus haut, ces domaines ont une priorité dans la réception des évènements. Dans notre cas, Xenomai les réceptionne en premier (primary domain) et Linux en second (secondary domain).

Une fois que la tâche Xenomai a fait son appel système Linux et qu'elle se trouve en secondary mode, elle y reste tant qu'elle ne fait pas d'appel système Xenomai.

Linux devient une tâche de Xenomai. Mais quelle priorité lui affecter ? A priori, la plus faible possible (tâche idle pour Xenomai).

Comment alors considérer la priorité des tâches Xenomai passées dans le scheduler Linux ? Faible comme Linux ou bien constante ?

Dans Xenomai, la deuxième implémentation a été retenue (23).

La priorité d'une tâche Xenomai est constante, quel que soit le scheduler dans lequel elle se trouve.

Cette implémentation n'est possible qu'à une condition : que la priorité de la tâche Linux dans l'ordonnanceur Xenomai évolue dynamiquement, sinon on se retrouverait dans un cas d'inversion de priorité.

Les schémas du paragraphe suivant permettent de mieux visualiser cette politique d'ordonnancement.

Nous voici face à un nouveau problème : une fois dans l'ordonnanceur Linux, la tâche Xenomai est maintenant une tâche comme les autres et on revient au point de départ, à savoir, comment faire du temps réel avec Linux ?

Or, qu'avions-nous écrit plus haut ? Que les dérives temporelles étaient introduites par :

• les interruptions (handlersLinux) : nous avons maintenant ADEOS pour les masquer (Interrupt Shield) ;
• la préemption par des tâches de plus forte priorité : il suffit de s'exécuter dans la classe SCHED_FIFO(24) ;
• l'absence de préemption à l'intérieur du noyau : les options natives (« low latency desktop ») la résolvent partiellement.

Une tâche en secondary mode est du temps réel mou et son temps d'exécution est borné (Interrupt Shield).
Pour les tâches à contrainte temps réel dur, il faut absolument rester en primary mode (25).
Les tâches Xenomai ont 99 niveaux de priorité possibles, exactement comme la classe SCHED_FIFO/RR. Ceci est normal puisque les priorités ne changent pas d'un scheduler à l'autre, la correspondance est donc immédiate (26).

Les exemples ci-dessous détaillent les différents cas de figure.

Soient Ln les tâches schedulées par Linux et Xn celles par Xenomai. Chaque tâche a une priorité, notée PrioLx ou PrioX, selon l'ordonnanceur de départ. Cette distinction est de pure forme car toutes les priorités évoluent dans le même espace.

Les priorités Xenomai sont constantes à travers les schedulers :

Le noyau Linux est une tâche de fond dont la priorité évolue dynamiquement en fonction de la tâche Xenomai de plus haute priorité éligible en mode secondaire.

Comme vous pouvez le constater (et peut-être vous en étonner), il y a deux tâches élues dans le schéma précédent. On est pourtant bien sur un exemple simple, monoprocesseur. En fait, chaque tâche élue est considérée en fonction de son ordonnanceur et non pas du processeur.

Parmi un ensemble de tâches Xenomai éligibles, c'est toujours celle de plus haute priorité qui sera exécutée, quel que soit son mode !!!

Ci-dessus, X1 est la tâche courante bien qu'il existe d'autres tâches Xenomai en primary mode.

Les tâches Xenomai en mode secondaire sont en concurrence avec les autres tâches Linux de la classe SCHED_FIFO/RR.

Dans l'exemple suivant, le système possède une tâche L1 sans rapport avec Xenomai. Cette tâche a une priorité de 80.

L'exécution de Xenomai a basculé la tâche élue X1 en secondary mode, la concurrence d'accès au CPU va donc se jouer dans l'ordonnanceur Linux. Or, L1 va préempter tout le monde !

Si vous êtes dubitatif sur ce changement de priorité dynamique de la tâche Linux, voici un contre-exemple qui devrait vous convaincre. Si la tâche Linux gardait sa priorité -1, on serait alors dans un cas d'inversion de priorité :

Bizarre ? Disons logique plutôt. On pourrait en fait s'attendre à ce que X2 prenne la main. Non, non, non et non ! Puisque nous serions alors dans un cas d'inversion de priorité.

Attention : une tâche Linux peut préempter une tâche Xenomai.

Il faut être attentif à deux choses pour les tâches en secondary mode afin d'éviter des comportements non souhaités :
- leurs priorités doivent être inférieures à celles en primary mode  ;
- leurs priorités doivent être supérieures aux tâches Linux s'exécutant dans la classe SCHED_FIFO (dépend de la distribution).

Les fameux « évènements » se précisent. Peuvent provoquer un rescheduling :

• les interruptions matérielles : timer pour les tâches périodiques, équipement prêt...
• les signaux logiciels : fin d'une tâche suite à une faute...
• les créations/destructions de tâche : fork, exit...
• les changements de caractéristiques d'une tâche : priorité, policy ;
• les deschedulings volontaires.

L'idée est d'avoir un comportement uniforme quels que soient le type d'évènements et le domaine d'origine. On réapplique ce que nous avions vu pour les interruptions matérielles : tous les évènements sont envoyés dans un tuyau et les domaines (OS) viennent y puiser les informations qui les intéressent.

Le patch ADEOS est « respectueux » du code initial du noyau Linux car il ne le modifie que très peu.

Petite parenthèse : lors du démarrage de la machine, le domaine Linux est créé avant le domaine Xenomai. Cette primauté lui confère le nom de root domain, terme que l'on va ensuite retrouver dans la liste des tâches Xenomai.

(27)Devinette : nous sommes en secondary mode, nous maîtrisons les priorités des autres processus Linux, quelle est la seule chose qui peut augmenter notre temps d'exécution ?

Tic, tac...

Bonne réponse : les handlers d'interruption Linux (top-half) et les tasklets hors de contrôle du scheduler des tâches (bottom-half).

Afin de s'en prémunir, un mécanisme appelé Interrupt shield protège les tâches en secondary mode en filtrant les interruptions. Le temps d'exécution de la tâche est alors borné.

Mais alors pourquoi l'IS n'est-il pas activé par défaut lors de l'installation ? Simplement, car il y a un risque d'inversion de priorité.

Prenons l'exemple suivant, soit deux tâches T1 et T2 en secondary mode. T2 active l'InterruptShield. T1 a la main (normal car elle est prioritaire) puis se place en attente de données. Elle est alors deschedulée, T2 entre alors en jeu. Une interruption arrive. T1 est censée s'exécuter, or elle est schedulée par Linux, et celui-ci n'a pas encore été informé que l'interruption est arrivée (IS). T2 termine alors son traitement, l'interruption est relâchée, T1 est débloquée.

La solution serait alors que T2 soit protégée des interruptions Linux tout en laissant T1 s'exécuter si des données arrivent.

Ceci revient à dire qu'il faut que l'interruption pour T1 ne soit pas traitée par Linux mais directement par Xenomai. Si ce handler est géré par Xenomai, le read doit l'être également.

Tout ceci nous amène naturellement à définir des drivers spécifiques à Xenomai (RTDM: Real Time Model Device), un exemple de driver est présenté au chapitre XII.

C'est également depuis l'API RTDM que des tâches Xenomai en mode noyau peuvent être lancées (primitive rtdm_task_init()).