Rapport de projet de fin d'étude - Équipe Automatique ...icube-avr.unistra.fr/fr/images/8/87/Rapport_Berruer.pdf · de nombreux conseils et avis techniques au cours du projet

ENSPSPôle API – Parc d'innovationBd Sébastien BrantBP 1041367412 ILLKIRCH CEDEXTél : 03 90 24 45 10Fax : 03 90 24 43 46

Rapport de projet de fin d'étude

Portage et évaluation de Xenomai sur une plateforme PC/104

Sébastien BERRUERTel : 06 76 35 29 55

Option ISAVPromotion 2009

Altran OuestCentre d'affaires Alphasis

Espace PerformanceBâtiments J&K

35760 St GrégoireTel : 02 23 25 36 00Fax : 02 23 25 36 01


RemerciementsJe tiens à remercier Mme Alexandra Poirier, responsable des Ressources Humaines, et Mr Christophe Ducolone, Directeur Opérationnel, pour m'avoir donné la chance de faire ce stage au sein d'Altran Ouest.

Je voudrais remercier Mr Jean-Michel Hautbois, mon maître de stage. Il m'a prodigué de nombreux conseils et avis techniques au cours du projet. Il m'a offert la possibilité d'avoir une vision sur la fonction de chef de projet et sur la gestion de projet en général. Il a su me mettre en confiance et me motiver tout au long de la période.

Je souhaite remercier Mrs Stéphane Davy et Jean-Philippe Foures. Ces personnes ont travaillé dans le même contexte que moi et m'ont apporté leurs avis sur certains problèmes techniques. Ils ont aussi apporté une ambiance de travail studieuse mais décontractée.

Finalement, je remercie toutes les personnes que j'ai pu rencontrer au sein d'Altran Ouest pour leurs gentillesse et leur accueil.

2/104

RésuméJ'ai effectué mon stage de troisième année au sein du centre de service eLiSe. Ce centre de service est spécialisé dans le domaine des systèmes Linux embarqués. C'est une spécificité du groupe d'Altran Ouest. Le groupe Altran Ouest est un groupe implanté mondialement qui fait du conseil en innovation.

Au cours de ce stage, j'ai étudié le système temps-réel Xenomai. Cela m'a permis de comprendre les caractéristiques des systèmes temps-réels et de découvrir les domaines d'applications courants pour ces systèmes. J'ai aussi abordé les différences qu'apporte le patch-RT sur le noyau Linux. En regard de cette solution, j'ai profondément étudié le système Xenomai : son utilisation d'Adeos, la façon dont il gère le temps-réel et l'utilisation de ce système à travers son API.

J'ai effectué plusieurs tâches au cours de ces 5 mois. J'ai commencé par mettre en place mon environnement de travail. J'ai du me familiariser avec la carte Viper et les méthodes de communications avec cette carte. Suite à un problème de disponibilité de ressources, j'ai créé le système de fichier utilisé au cours de l'étude. Enfin, j'ai pu réaliser le portage de Xenomai sur la carte PC/104 et étudier les performances du système.

3/104


SummaryI spend 5 months in Altran Ouest for my training course. Particularly, I worked in the eLiSe service which is specialised in the development of embedded Linux systems.

I firstly spend my time to read the documentation about the subject. I learned the features and the specifics constrains of real-time systems. I learned too what are the domains who make use of those systems. I had a wide view about the RT patch for Linux and the differences that it introduces in the behaviour and the structure of the Linux kernel. Of course, I had a deep view in the Xenomai system : its use of Adeos, its structure and the API it shows.

During five months, I made activities that cover a large range of embedded systems. I began by installing the development environment in the host PC. Then, I learned how to use the computer board on which I realised the port. It supposed some specifics methods to communicate with the systems. I had to create a complete filesystem to integrate Xenomai on the board. I realized the port of Xenomai for the ARM® platform and performed some tests.

4/104

Table des matièresRemerciements.............................................................................................2Résumé........................................................................................................3Summary.....................................................................................................4Liste des abréviations.....................................................................................9Introduction................................................................................................10

Présentation de l'entreprise..............................................................................111.Groupe Altran...........................................................................................12

1.1.L'implantation.....................................................................................121.2.Les domaines d'activités......................................................................121.3.Les chiffres clés..................................................................................13

2.Altran Ouest.............................................................................................142.1.L'implantation.....................................................................................142.2.L'organigramme..................................................................................142.3.Les secteurs d'activités d'Altran Ouest...................................................152.4.Les compétences de la branche TEM......................................................16

3.eLiSe : embedded Linux Services................................................................173.1.Les compétences................................................................................17

3.1.1.Développement et personnalisation noyau.......................................183.1.2.Environnement de bas niveau.........................................................183.1.3.Intégration d'applications..............................................................183.1.4.Environnements de développement.................................................18

3.2.Les plateformes d'études.....................................................................183.2.1.Veille technologique......................................................................183.2.2.La carte industrielle Arcom VIPER...................................................193.2.3.Le téléphone « Android »...............................................................193.2.4.Le téléphone « OpenMoko »...........................................................19

3.3.Les services.......................................................................................203.3.1.Audit et expertise.........................................................................203.3.2.Études et avis de faisabilité............................................................203.3.3.Développement et support.............................................................20

Les systèmes temps-réels.................................................................................211.Introduction aux systèmes temps-réels........................................................222.Contraintes du temps réel..........................................................................22

2.1.Les échéances....................................................................................222.2.Les latences.......................................................................................222.3.La préemption....................................................................................24

3.Utilisations typiques..................................................................................243.1.Temps réel dur...................................................................................253.2.Temps réel mou..................................................................................25

4.Patch-RT..................................................................................................254.1.Modifications structurelles....................................................................26

4.1.1.Les chemins d'exécutions..............................................................264.1.2.La préemption du noyau................................................................264.1.3.La gestion des interruptions...........................................................27

4.2.Modifications comportementales...........................................................284.2.1.Les modes de configuration............................................................284.2.2.L'héritage de priorité.....................................................................29

5/104


4.3.Compteurs à haute résolution...............................................................305.Xenomai..................................................................................................31

5.1.Historique..........................................................................................315.2.Adeos................................................................................................32

5.2.1.Les domaines...............................................................................325.2.2.Le pipeline d'interruption...............................................................33

5.3.Gestion du temps-réel.........................................................................345.3.1.L'utilisation d'Adeos......................................................................345.3.2.L'architecture de Xenomai..............................................................355.3.3.Les modes d'exécution..................................................................36

5.3.3.1.La migration des fils d'exécution...............................................365.3.3.2.Le temps-réel dans le mode secondaire.....................................36

5.4.API temps-réel...................................................................................375.4.1.Les « Skins »...............................................................................375.4.2.L'API native temps-réel..................................................................375.4.3.Real-Time Driver Model.................................................................39

Travail réalisé..................................................................................................401.Environnement de développement...............................................................41

1.1.L'arborescence de travail......................................................................411.2.Les outils...........................................................................................42

1.2.1.Logiciel de suivi de version : git......................................................421.2.2.Le système d'information du centre de service..................................421.2.3.Portail de collaboration : Trac.........................................................43

1.3.Les outils de compilation croisée...........................................................441.3.1.Contraintes..................................................................................441.3.2.Dépaquetage...............................................................................451.3.3.Modification des variables d'environnement......................................451.3.4.Tests de l'environnement...............................................................45

2.Prise en main de la carte Viper....................................................................462.1.Le chargeur d'amorçage : RedBoot........................................................462.2.Communication avec la carte Viper........................................................47

2.2.1.Liaison série avec C-Kermit............................................................472.2.2.Liaison Ethernet et console Telnet...................................................47

2.3.Configuration de démarrage.................................................................482.3.1.Le chargement du noyau par TFTP..................................................482.3.2.Le montage du système de fichier par NFS.......................................49

3.Création du système de fichier....................................................................503.1.Motivations........................................................................................503.2.Squelette de base...............................................................................51

3.2.1.Les directives du FHS....................................................................513.2.2.Les fichiers de périphériques..........................................................52

3.3.Applications.......................................................................................533.3.1.SysVinit.......................................................................................533.3.2.BusyBox......................................................................................54

3.4.Démarrage.........................................................................................563.4.1.Le choix du système rc..................................................................563.4.2.Les sessions utilisateurs................................................................573.4.3.Le serveur inetd...........................................................................573.4.4.Le serveur Telnet..........................................................................58

4.Portage de Xenomai..................................................................................59

6/104

4.1.Manipulations sur le noyau Linux...........................................................594.1.1.Patch du noyau............................................................................594.1.2.Configuration du noyau.................................................................604.1.3.Compilation du noyau...................................................................60

4.2.Installation sur le système de fichier......................................................614.2.1.Mise en place du noyau.................................................................614.2.2.Compilation des librairies...............................................................62

5.Évaluation de Xenomai...............................................................................635.1.Visualisation de la console....................................................................635.2.Critères d'évaluations..........................................................................64

5.2.1.Les situations propices aux latences................................................645.2.2.La mesure de la gigue...................................................................65

5.3.La suite de tests.................................................................................655.3.1.Clocktest.....................................................................................665.3.2.Cyclic..........................................................................................675.3.3.Klatency......................................................................................675.3.4.Latency.......................................................................................68

5.4.Résultats...........................................................................................685.4.1.Commentaires critique..................................................................685.4.2.Analyse des mesures de « clocktest »..............................................695.4.3.Analyse des mesures de « latency »................................................69

5.5.Le traceur du pipeline..........................................................................706.Développement sous Xenomai....................................................................70

6.1.Réalisations.......................................................................................706.1.1.Les compétences acquises.............................................................706.1.2.Les outils.....................................................................................71

6.2.Développer des « bonnes pratiques »....................................................716.2.1.Le management des tâches............................................................716.2.2.L'accès aux données.....................................................................72

6.3.Le déboguage des applications..............................................................736.3.1.Déboguage symbolique.................................................................736.3.2.Le traçage des appels systèmes......................................................74

Conclusion..................................................................................................76Ouverture...................................................................................................76

Annexes.........................................................................................................77A.Caractéristiques de la carte Viper................................................................78

A.1.Processeur.........................................................................................78A.2.Mémoire............................................................................................79A.3.Connecteurs série...............................................................................79A.4.Fonctionnalités réseau.........................................................................79

B.Résultats du programme « latency »............................................................80B.1.Mesures relevées (n°1).......................................................................80B.2.Mesures relevées (n°2).......................................................................81B.3.Mesures relevées (n°3).......................................................................82B.4.Mesures relevées (n°4).......................................................................83

C.Logiciel de suivi de version : git..................................................................84C.1.Concepts...........................................................................................84C.2.Utilisation..........................................................................................85C.3.Autres commandes.............................................................................87

D.Logiciel de suivi de version : svn.................................................................89

7/104


D.1.Concepts...........................................................................................89D.2.Utilisation..........................................................................................90D.3.Autres commandes.............................................................................92

E.Mise en place d'un serveur TFTP..................................................................94E.1.Installation........................................................................................94E.2.Configuration.....................................................................................94E.3.Vérification de la configuration..............................................................95

F.Mise en place d'un serveur NFS...................................................................96F.1.Installation.........................................................................................96F.2.Configuration......................................................................................96

G.Déboguage symbolique : gdb.....................................................................97G.1.Procédure de déboguage à distance......................................................97G.2.Les commandes usuelles.....................................................................98

Bibliographie.............................................................................................101Sites Internet.........................................................................................101Livres...................................................................................................101Articles.................................................................................................102

8/104

Liste des abréviationsAPI Application Programming Interface

ARM Advanced RISC Machine

Bash Bourne again shell

EABI Embedded-Application Binary Interface

GNU GNU is Not Unix

HTTP HyperText Transfer Protocol

IP Internet Protocol

NFS Network FileSystem

PC Personal Computer

RAM Random Access Memory

RISC Reduced Instruction Set Computer

SRAM Static Random Access Memory

SSH Secured SHell

Telnet Teletype network

TFTP Trivial File Transfer Protocol

URL Uniform Resource Locator

9/104


IntroductionJ'ai effectué mon stage de troisième année dans le centre eLiSe du groupe Altran, à Rennes. Ce centre est spécialisé dans les systèmes Linux Embarqués.

Dans le cadre du développement de l'activité de cette branche, j'avais pour mission de porter l'environnement temps-réel Xenomai sur une carte industrielle et d'en évaluer les performances. Cette carte industrielle avait la particularité d'être conforme au format PC/104 et d'embarquer un processeur de type ARM®.

Dans le présent de ce rapport de stage, je commence par présente le groupe Altran. J'y détaille l'activité du groupe et je donne quelques chiffres clés. Je présente ensuite l'organisation du groupe au niveau de Rennes ainsi que les activités d'Altran Ouest dans la région. Enfin, je présente le centre de service eLiSe.

Je joint dans le rapport un « compte-rendu » de mes recherches sur les systèmes temps-réels de type Linux. Je décris les spécificités des systèmes temps-réels, les distinctions qui peuvent exister dans ce domaine ainsi que les principaux utilisateurs de tels systèmes. Au cours des recherches sur Xenomai, j'ai souvent rencontré des références au patch-RT pour le noyau Linux ; je présente donc un rapide aperçu des modifications qu'il apporte au noyau Linux. Enfin, après un rapide historique du projet Xenomai, j'explique le système Adeos et la façon dont Xenomai l'utilise pour gérer le temps-réel. Je termine la présentation de Xenomai en faisant une description des mécanismes introduit au niveau utilisateur (utilisation des API).

Le corps du rapport est constitué par la présentation des activités que j'ai mené au cours de ces 5 mois. Je présente donc : la mise en place de l'environnement de développement, la prise en main de la carte Viper et le processus de création du système de fichier. Une fois ces étapes réalisées, j'ai pu procéder au portage de l'environnement Xenomai sur la carte. Mon stage consistait aussi à faire une évaluation des performances du système. Dans cette optique, j'ai développé quelques applications utilisant l'API temps-réelle de Xenomai.

10/104

Présentation de l'entreprise

Altran Ouest


1. Groupe Altran

1.1. L'implantationLe groupe Altran a été fondé en 1982. Il est implanté dans 26 pays dans le monde.

Le nombre important d'implantations sur le continent Européen permet au groupe de se positionner aujourd'hui comme le leader européen dans le domaine du conseil en innovation.

1.2. Les domaines d'activitésLe groupe fédère des entreprises qui officient dans trois domaines d'activités différents (appelés « Business Lines »).

12/104

Illustration 1 : Implantations d'Altran dans le monde

En Amérique : En Europe :

• Brésil• Canada• États-Unis

d'Amérique

• Allemagne• Autriche• Belgique• Espagne• France• Irlande• Italie• Luxembourg• Pays-Bas

• Pologne• Portugal• République Tchèque• Roumanie• Royaume-Uni• Slovaquie• Suède• Suisse

En Asie :

• Chine• Corée du Sud• Inde• Japon• Malaisie• Singapour

Les domaines d'activités - Les domaines d'activités

Les trois domaines, constituant le « cœur » du diagramme ci-dessus, sont :

• le conseil en technologies et R&D

C'est la capacité de mettre en œuvre le savoir-faire, les méthodes techniques et scientifiques des consultants ingénieurs pour mener à bien des projets innovants.

• le conseil en organisation et systèmes d'information

Il permet de fournir aux entreprises la capacité de rester compétitif face aux contraintes de croissance d'entreprise, de rentabilité et de législation. Les entreprises qui font appel à Altran sur ce point cherchent à faciliter leurs prises de décisions, et leurs agilité organisationnelle.

• le conseil en stratégie et management

Il permet aux entreprises de maîtriser leurs environnement et d'anticiper les évolutions du secteur dans lesquelles elles travaillent. Cela leurs permettent d'augmenter leurs potentiel de succès sur le long terme.

Comme le présente la « couronne » sur le schéma 2, le positionnement des trois domaines d'activités permet de couvrir totalement un cycle de produit.

1.3. Les chiffres clésPour l'année 2008, le chiffre d'affaire s'est élevé à 1650,1 million d'euros. Il a été réalisé à 57% hors de France. La génération du CA étant :

13/104

Illustration 2 : Les trois "Business Lines" et le cycle d'innovation


• près de la moitié du chiffre d'affaire est réalisé par les activités de la branche « conseil en technologies et R&D »

• un tiers du chiffre d'affaire provient des activités de la branche « conseil en organisation et systèmes d'information »

• environ 15% du chiffre d'affaire est produit par la branche « conseil en stratégie et management »

Les consultants du groupes étaient 18522 en décembre 2008. Il y a eu 1020 recrutements nets au cours de l'année 2008.

2. Altran Ouest

2.1. L'implantationAu niveau Français, une réorganisation a été menée pour fusionner une multitude de sociétés. Il a donc été délimité six zones, en plus de Paris : la région Ouest, la région Est, la région Nord, la région Sud-ouest, la région Rhône-Alpes et la région Méditerranée.

L'implantation du groupe Altran dans l'Ouest date de 1984. Les trois plus gros pôles de l'Ouest sont, dans l'ordre : Rennes, Brest et Nantes. Dans l'Ouest, le groupe se veut centré autour des clients, tout en s'appuyant sur sa force à l'international.

Cette implantation historique permet de compter aujourd'hui 425 ingénieurs répartis sur les régions Bretagne, Pays de Loire et Poitou-Charentes. Pour mieux cerner la répartition, on compte 230 consultants à Rennes, 85 à Brest et 110 à Nantes.

2.2. L'organigrammeLe groupe Altran est gouverné grâce à un comité exécutif et un conseil d'administration. Le premier (le comité exécutif) regroupe les personnes responsables de la direction du groupe : le Président-Directeur Général, le directeur financier et trois directeurs généraux adjoints. Le second (le conseil d'administration) décide de la politique du groupe.

Ensuite, au niveau régional, les compétences sont réparties de la façon suivante :

14/104

L'organigramme - L'organigramme

• Les consultants sont les personnes qui effectuent la réalisation des projets. Ils ont le profil ingénieur. On retrouve deux types de compétences : les experts et les chefs de projet. Les experts sont spécialisés dans un domaine particulier. Les chefs de projet se situent à la frontière du management et de la technique. Au cours d'un projet, ils coordonnent le travail de plusieurs autres consultants. Ils peuvent demander l'accompagnement de consultants experts dans un domaine. Les consultants de la direction des offres ont des rôles souvent plus transversaux : ils interviennent pour répondre aux appels d'offres publics, ils organisent les fonctions liés à la Qualité...

• Les managers ont trois rôles principaux : le recrutement, le management d'une équipe et la relation commerciale. Ainsi, ils démarchent les clients pour trouver des projets à réaliser. En fonction des demandes des clients, ils recherchent les compétences parmi les personnes disponibles au sein d'Altran. Ils se mettent généralement en rapport avec les consultants pour bénéficier de l'avis technique de ces derniers lors de la phase de décision des projets. Ils participent aux négociations et aux chiffrages financiers des projets.

• Les équipes administratives et la direction des Ressources Humaines apportent leur support à tout les niveaux de l'organisation.

• Le directeur opérationnel oriente la politique du groupe au niveau régional. Il sollicite les managers en leurs donnant une direction commerciale. C'est généralement à lui que revient la décision de lancer la réalisation d'un projet.

2.3. Les secteurs d'activités d'Altran OuestDans la région Ouest, les activités sont partagées dans cinq secteurs « métiers ». En effet, au niveau régional, Altran se tourne vers ses clients. Son activité est donc menée selon les secteurs :

• AIT : Automotive Infrastructure & Transportation

Altran met son expertise à la disposition de ses clients pour améliorer leurs efficacité, la qualité et le processus de leurs produits. Les consultants interviennent sur les tâches de Bureaux d'Étude et R&D, de phase

15/104

Illustration 3 : Organigramme au sein d'Altran Ouest


d'industrialisation, de production, logistique, de Qualité...

Cette branche regroupe plus de 80 consultants dans l'Ouest.

• ASD : Aéronautique, Spatial, Défense

Altran Ouest officie essentiellement sur deux grands domaines, dans la région : les sciences et techniques de la mer, l'aéronautique et la défense. Le premier est un domaine spécifique à d'Altran Ouest. Il fait appel à des compétences telles que l'acoustique sous-marine, la géophysique... Le second domaine nécessite plutôt des personnes travaillant dans les domaines de l'électronique, des systèmes embarqués, de la mécanique...

Actuellement, on compte 65 consultants dans l'Ouest.

• CIS : Conseil & Systèmes d'Information

Cette branche d'activité a pour but la performance des entreprises en améliorant leurs organisation et leurs systèmes d'informations. Le groupe est capable de mettre en place des projets de conseils et d'expertise, de faire de la maîtrise d'œuvre et de la maîtrise d'ouvrage, de l'ingénierie système et intégration...

Cette branche regroupe 120 consultants.

• EILIS : Energy, Industry & Life Sciences

À travers cette ligne d'activité, Altran Ouest vise : les industries de production d'énergie, les industries chimiques, les industries agro-alimentaires et les industries de la santé (pharmacie et cosmétique). Elle aide ses clients sur les problématiques d'hygiène, de sécurité et d'environnement.

Désormais, 15 consultants sont rattachés à ce domaine.

• TEM : Telecoms & Media

On peut considérer que c'est la branche historique d'Altran Ouest. Le groupe revendique une expérience de plus de 20 ans dans les domaines de la téléphonie mobile & TV numérique, les réseaux & télécommunications, l'électronique.

Plus de 120 consultants font partie de cette branche.

2.4. Les compétences de la branche TEMLa branche TEM propose des compétences dans trois grands domaines :

• la téléphonie et la télévision numérique

Dans ce domaine, les compétences proposés sont celles liées au matériel, à la création de codecs vidéo et audio, à la connaissance des spécificités des bandes de diffusion, à l'application des protocoles de communication (GSM, MPEGx, ...).

• l'électronique

Au sein de ce domaine, on compte des compétences telles que : la connaissance de plates-formes matérielles spécifiques ou le design de cartes. Dans cette spécialité, au niveau système, le groupe à la capacité de proposer la

16/104

Les compétences de la branche TEM - Les compétences de la branche TEM

conception et la réalisation de drivers, l'intégration et la connaissance de systèmes embarqués et temps-réel.

• les réseaux et les télécommunications

Les compétences dans ce domaine permettent de proposer au client des solutions sur ses problèmes de conception et de sécurisation des réseaux, sur l'interopérabilité, etc… Altran peut apporter son expertise sur des techniques telles que la VoIP, le WiFi, le WiMax.

3. eLiSe : embedded Linux ServicesLe centre eLiSe est une particularité de la branche TEM dans l'Ouest. Les compétences des personnes rattachées à ce groupe concernent les systèmes embarqués de type Linux. Le centre est capable de proposer ses services sur une large partie d'un cycle de vie d'un produit. C'est aussi une plateforme permettant aux consultants de développer leurs compétences ou d'explorer un sujet parmi le domaine des systèmes embarqués.

3.1. Les compétencesLes compétences déployées au sein du centre de service touchent tous les domaines des systèmes embarqués, autant au niveau du matériel que du code source. L'étendue de ces compétences permet de garantir une totale maîtrise des systèmes développés dans le centre. Il en résulte une meilleure qualité de ceux-ci.

17/104

Illustration 4 : Un système GNU/Linux intégré au dessus d'une plateforme matérielle


3.1.1. Développement et personnalisation noyauLe développement noyau comporte la mise au point du BSP. Les portions de code spécifique développées pour une plateforme matérielle donnée sont généralement minimales. À côté du support de la carte, il faut parfois développer des drivers spécifiques pour les périphériques. En plus de tout cela, l'expertise du centre permet de choisir les sous-systèmes les plus performants pour une application donnée ; par exemple, le choix d'un système de fichier parmi les variantes ext, jffs2.... Par rapport au schéma 4, les compétences explicitées précédemment se situent au niveau du noyau, de ses drivers et de ses modules.

3.1.2. Environnement de bas niveauDans cette section, le travail porte sur la mise en place des librairies (librairie GNU C, par exemple). Il peut aussi porter sur l'intégration des applications standards pour utiliser une machine (un interpréteur de commandes, les applications ls, cat...). Il pourra y avoir parfois a effectuer le développement d'outils spécifiques pour l'initialisation du système, le management du matériel... Le travail se situe donc au dessus du noyau Linux, vis-à-vis des librairies et des applications GNU (voir le schéma 4).

3.1.3. Intégration d'applicationsIl faut garantir au client final le bon fonctionnement d'une application embarquée. Donc, il faut s'assurer que le logiciel fonctionnera bien sur la machine, que ce soit en terme de trace mémoire, de consommation d'énergie ou de rapidité d'exécution. On peut aussi faire de l'analyse statique de code pour le réduire et/ou l'améliorer (avec la possibilité que l'impact mémoire soit réduit).

3.1.4. Environnements de développementLe centre propose parfois de mettre en place des chaînes de compilation finement adaptées à un matériel. Des chaînes de compilation adaptées permettent d'améliorer grandement le code exécutable des applications. Le centre met en avant sa compétence pour installer des environnements de développements avec des outils issus du monde du logiciel libre (par exemple, le logiciel de suivi de version git, le logiciel de déboguage gdb...).

3.2. Les plateformes d'études

3.2.1. Veille technologiqueLe centre de service répond à des besoins clients spécifiques mais il se place aussi en amont de la demande, en gérant des études en interne. Ces études permettent d'anticiper les problèmes clients. Cela permet d'acquérir des compétences et d'entretenir la collaboration au sein des communautés Open Source, ce qui peut-être mis en avant face aux clients.

18/104

La carte industrielle Arcom VIPER - La carte industrielle Arcom VIPER

3.2.2. La carte industrielle Arcom VIPERLa carte Arcom™ VIPER est une carte industrielle, typique des applications automatisées et/ou des réseaux embarqués.

Le travail réalisé pour cette plateforme a, en premier lieu, été le portage de la version 2.6.28 du noyau Linux. Il a continué avec le portage et la création d'applications à visés multimédia (bibliothèque graphique Qt, application vidéo VLC). Pour ma part, j'ai effectué le portage de l'environnement temps-réel Xenomai sur cette carte.

3.2.3. Le téléphone « Android »Le téléphone HTC G1 permet de faire fonctionner le système d'exploitation Android. Le système Android est un système d'exploitation (ayant une base Linux et utilisant majoritairement le langage Java pour ses applications) à destination des téléphones et des appareils mobiles. L'effort de développement de cette plateforme est soutenu par Google. Le téléphone HTC G1 est appelé couramment le « Google phone » ou « Android », en rapport avec son système d'exploitation.

Actuellement, le système Android semble se dessiner comme une alternative intéressante pour les appareils mobiles connectés (smart-phones, MID, net-books...). La société HTC a été la première à commercialiser un téléphone utilisant ce système, mais elle a été suivi cet été par Samsung. Un certain nombre de rumeurs envisagent que des constructeurs de net-books (Dell, par exemple) se mettent aussi à proposer des appareils fonctionnant avec ce système d'exploitation.

Dans ce contexte, le groupe Altran se positionne en avance de phase en formant des personnes sur cette plateforme. Au cours de l'été, un travail a été réalisé visant à porter le décodeur h.264 SVC sur la plateforme. Ce format de compression (h.264 SVC) permet l'adaptation de la taille d'un flux vidéo en fonction de la disponibilité du réseau. Les prochains lecteurs vidéo téléphoniques, intégrant ce format de compression, devraient apporter une meilleure expérience aux utilisateurs en fournissant de la vidéo sans interruptions.

3.2.4. Le téléphone « OpenMoko »Le téléphone Neo FreeRunner permet de faire fonctionner le système d'exploitation OpenMoko. Ce téléphone est un véritable smart-phone utilisant le GSM, le WiFi, le GPRS, un écran tactile...

L'intérêt de ce téléphone repose sur l'entière ouverture de ses spécificités, depuis les composants matériels jusqu'aux briques logicielles qui composent le système. La communauté qui est à l'initiative de ce téléphone a publié absolument tout les documents de conception. Par exemple, il est possible d'aller jusqu'à étudier les masques de fabrication de la carte du téléphone.

19/104


3.3. Les servicesLes services du centre se positionnent tout au long du cycle de vie d'une application.

3.3.1. Audit et expertiseLes personnes qui appartiennent au centre sont capables de proposer des évaluations aux clients. Ils peuvent mettre en avant les contraintes de compatibilités matérielles et logicielles. Ils savent estimer la faisabilité d'un portage d'une application sur une plateforme donnée.

L'expertise de ces mêmes personnes leurs permet de proposer l'optimisation d'applications pour que celles-ci fonctionnent parfaitement sur un matériel donné. L'optimisation peut porter sur la vitesse d'exécution, l'empreinte mémoire ou la consommation...

3.3.2. Études et avis de faisabilitéLe centre de service se positionne sur les études de faisabilité de produits. Il est capable de faire des propositions de matériel et de logiciel qui répondent à un besoin client. En effet, il existe des cas où le matériel impose des contraintes, ou apporte des spécificités, qui influent sur les performances d'un système.

Le centre se propose d'aider ses clients à migrer d'un environnement propriétaire à un environnement Linux selon une méthode guidé, pas-à-pas. Cette migration se fait en conservant l'isolation du code propriétaire et du code source issu de la communauté Open-source. Par exemple, cela évite la « pollution » des portions de codes régies par une licence GPL.

3.3.3. Développement et supportLe développement est un terme générique pour indiquer que le centre de service peut proposer des conseils sur le développement d'un BSP, la réalisation de celui-ci (portage, développement de drivers...) et le maintien de ce BSP. Il est aussi capable de proposer du management d'applications. Ce terme inclut le développement de modules spécifiques, le maintien d'applications... Cela permet de satisfaire les contraintes sur la durée de vie d'un produit, et donc de la rentabilité sur le long terme.

Lors du développement d'un solution Linux embarqué, le centre de services produit des conseils vis à vis de l'architecture du système, des tests à réaliser et propose une démarche d'assurance qualité. Les personnes du centre peuvent être amenées à dispenser des sessions de formation aux clients sur les spécificités du monde embarqué.

20/104

Les systèmes temps-réels

Les solutions temps-réels de type Linux


1. Introduction aux systèmes temps-réelsLes systèmes temps-réels se caractérisent par des contraintes sur l'exécution de leurs processus. Ils visent généralement à la tenue de certaines échéances. Pour cela, ils cherchent à diminuer les temps de latences et à autoriser la préemption du système.

Les systèmes temps-réels sont traditionnellement utilisés dans certains domaines. Ces domaines imposent plus ou moins de contraintes vis-à-vis des échéances ; ce qui caractérise deux types de temps-réel : le temps-réel dur et le temps-réel mou.

Au fil du temps, plusieurs approches ont été suivies pour satisfaire ces contraintes en utilisant le noyau Linux : la modification du noyau existant ou l'utilisation de systèmes temps-réels à part entière, fonctionnant à côté du noyau.

La première approche repose sur la modification du code source du noyau Linux. L'un des points les plus marquant est la possibilité de préempter l'exécution du noyau. De plus, des mécanismes spécifiques sont introduit grâce au patch, ainsi qu'une nouvelle gestion du temps.

La deuxième approche a aboutit à la création du projet Xenomai. Cette solution repose sur l'utilisation d'un autre projet : Adeos. Cela induit une architecture particulière pour la gestion du temps-réel et la proposition d'une API spécifique pour le temps-réel.

2. Contraintes du temps réel

2.1. Les échéancesLa contrainte d'un système temps réel est le fait que le bon fonctionnement de ce système ne dépend pas seulement de la réussite des opérations menées, mais aussi de la réussite de ces opérations dans un temps donné. Si les limites de temps sont dépassés, on dit alors que le système à échoué.

Ainsi, les systèmes temps réels ne sont pas nécessairement rapides. Un système temps réel peu fonctionner sur une plateforme matérielle lente et à bas coût. Par contre, il est nécessaire que la réalisation des opérations, dans les limites de temps imparties, soient garanties par un système d'exploitation spécifique.

On parle généralement de déterminisme. Il faut que l'on soit assuré que l'opération menée soit terminée avant l'échéance.

2.2. Les latencesLa latence est le temps qui peut exister entre le moment où un événement est notifié et celui où il est effectivement traité.

En s'appuyant sur le schéma Erreur : source de la référence non trouvée, on peut imaginer l'exemple d'un programme qui, au cours de son exécution, fait la demande d'une donnée issue d'un périphérique. Lorsqu'il fait appel à cette donnée, cette information n'est pas nécessairement disponible immédiatement. Il est donc mis en « sommeil » de façon à ce qu'un autre programme utilise l'unité de calcul, en

22/104

Les latences - Les latences

attendant que la donnée soit disponible. Lorsque le signal d'interruption indique que la donnée est disponible, il existe un certain temps entre cette notification et la poursuite du traitement du premier programme. Ce délai est appelé une latence d'exécution suite à une interruption.

La latence d'exécution (6) peut être expliquée en détail :

1. Latence à l'exécution de la routine d'interruption

Il existe un certain temps entre le moment où le signal électrique (issu du périphérique) signale l'interruption et le moment où la routine d'interruption correspondante commence à être exécutée. Cela s'explique par le fait que le processeur doit d'abord terminer l'exécution de l'instruction en cours. En effet les interruptions matérielles sont, par nature, asynchrones et les instructions complexes prennent généralement plusieurs cycles à s'exécuter entièrement. Avant d'exécuter la routine d'interruption, le système doit commencer par sauver le contexte d'exécution du processus actuel. Finalement, il prépare le contexte d'exécution de l'interruption (lecture de la position du vecteur d'interruption dans une table, mise en place de la pile...).

2. Temps d'exécution de la routine d'interruption

Il faut ajouter le temps d'exécution de cette routine d'interruption.

3. Latence à l'exécution de l'ordonnanceur

Une fois cette routine d'interruption exécutée, il peut y avoir un appel à l'ordonnanceur. Là encore, il existe un délai entre le moment où l'ordonnanceur est appelé et le moment où il commence à s'exécuter. Ce temps s'explique de la même façon que pour la routine d'interruption : le noyau peut avoir à effectuer d'autres opérations avant d'exécuter l'ordonnanceur (enlever un masque d'interruption...).

4. Temps d'exécution de l'ordonnanceur

De même, il faut compter le temps d'exécution du code de l'ordonnanceur.

5. Restauration du contexte d'exécution

Enfin, il faut rétablir le contexte d'exécution du processus qui avait été mis en sommeil. Il faut commencer par rétablir les valeurs des registres d'exécution du processeur. Ainsi, le processus reprend sont exécution au point où il en était rendu, de façon transparente.

23/104

Illustration 5 : Latences d'exécution suite à un interruption


Au total, il faut comprendre que l'on doit attendre la somme de toutes ces durées avant qu'un programme ne réagisse à un événement donné.

2.3. La préemptionLa préemption est la capacité d'interrompre l'exécution d'une tâche en faveur de l'exécution d'une autre tâche.

Pour donner l'impression que plusieurs processus ont accès en même temps à l'unité de calcul, les systèmes multi-tâches mettent un place le mécanisme d'ordonnancement des tâches. Ce concept (partage du temps d'utilisation du processeur) repose sur la capacité du système à préempter l'exécution du processus en cours. Dans les systèmes multi-tâches, la préemption du processus en cours se fait au profit de l'ordonnanceur. L'ordonnanceur mène un arbitrage pour décider quel processus doit s'exécuter.

Dans un système temps-réel, il paraît logique que les tâches qui sont les plus critiques gagnent le droit d'utiliser le processeur lorsqu'elles ont besoin de s'exécuter. Ainsi, toute section de code exécutable doit pouvoir être interrompue au profit d'une autre. Ce principe est valable à la fois pour les processus utilisateurs et pour le code du noyau.

De plus, lorsque la préemption est faite pour organiser la politique d'ordonnancement, cette politique doit satisfaire en priorité les demandes en ressources des processus les plus critiques. Ce point est régis par la mise en place, dans les systèmes temps-réels, d'ordonnancements spécifiques : ordonnancement rapide (type « Round-Robin »), ordonnancement à héritage de priorités...

3. Utilisations typiquesLes systèmes temps-réels ne reposent pas que sur l'aboutissement des traitements, ils font apparaître des contraintes sur les échéances. Selon la gravité de la non tenue des échéances, on définit la « dureté » du temps réel.

24/104

Illustration 6 : Répartition des applications en fonction de leurs contraintes

Utilisations typiques - Utilisations typiques

En fonction de l'importance de la tenue des échéances pour la réalisation des opérations, on définit deux grandes catégories de temps-réel : le temps-réel dur et le temps-réel mou.

3.1. Temps réel durOn distingue les applications dites de temps réel dur, pour lesquelles, le non respect des échéances peut entrainer des graves problèmes de sécurité ou le non respect de la qualité du service rendu. Dans ce cas, les exigences se présentent sous une forme impérative. Par exemple, la tâche doit être terminée en, au maximum, 3ms.

Parmi les secteurs nécessitant des systèmes temps réel dur, on retrouve l'aéronautique, la robotique ou l'industrie de contrôle/supervision.

3.2. Temps réel mouLes applications de temps réel mou peuvent se permettre de voir, bien que très rarement, des échéances non respectées. Les exigences de temps se présentent sous la forme d'un ou plusieurs intervalles ainsi qu'un ratio de réussite associé. Par exemple, on voudra que la tâche soit terminée en moins de 3ms dans 80% des cas et en moins de 5ms dans 99,9% des cas. La mesure de cette probabilité définie la Qualité de Service.

On voit apparaître des applications de temps réel mou dans les domaines de la finance et du multimédia.

Le premier domaine (la finance), bien que fonctionnant avec des intervalles de décompte de l'ordre de la milli-seconde, impose que les échéances soient tenues. C'est ce qui a suscité la mise en application de systèmes temps-réel dans ce domaine. Par exemple, l'indicateur des cents plus grosses capitalisations boursières du Royaume-Uni, le « FTSE1 100 Index », est calculé et diffusé toutes les quinze secondes, en temps-réel.

Le second domaine (le multimédia) illustre le fait que l'on puisse parfois accepter que des échéances ne soient pas vérifiées. L'exemple typique est celui de la vidéo. Un utilisateur courant accepte généralement que le décodage d'une vidéo ou d'une musique soit brièvement manqué lorsque son ordinateur est soumis à une forte charge.

4. Patch-RTDepuis plusieurs années, plusieurs personnes ont eu la volonté de modifier le noyau Linux pour qu'il soit capable de répondre aux contraintes du temps-réel, sans l'aide de co-noyau. Le patch-RT a la vocation de transformer le noyau Linux (par l'application d'un patch sur le code source du noyau) en un véritable système temps réel. Le mainteneur actuel de ce patch est Ingo Molnar, un ingénieur de la société Red Hat.

Les programmes qui utilisent ce noyau modifié n'utilisent pas d'API particulière, ils se basent sur l'utilisation de l'API POSIX.

1 FTSE : Financial Times Stock Exchange

25/104


En effet, dans la ligné du standard POSIX2 (norme IEEE Std 1003.1), il a été défini un certain nombre d'appels systèmes pour résoudre les contraintes de temps-réel (management de l'ordonnancement, signaux temps-réels, méthodes de création de « threads »...). Présentés sous la forme d'amendements pour la version IEEE Std 1003.1-1990, ils ont été incorporés comme des options à la norme, lors de sa révision en 2001.

4.1. Modifications structurelles

4.1.1. Les chemins d'exécutionsLe chemin d'exécution d'un processus est un indicateur macroscopique du déroulement des opérations réalisés par ce processus. C'est une manière unifiée et linéaire de se représenter le déroulement des opérations du programme. En réalité, le chemin d'exécution d'un processus n'est pas linéaire : de par la façon dont sont exécutées les instructions par le processeur, de par la façon dont a été optimisé le code à la compilation...

On distingue généralement les portions où le processus fait appel au noyau (via des appels systèmes) pour que celui-ci effectue des tâches particulières : on dit que le processus s'exécute dans l'espace noyau. À l'inverse, lorsque le processus n'effectue pas de tâches critiques, on dit qu'il s'exécute dans l'espace utilisateur.

4.1.2. La préemption du noyauGénéralement, le noyau est la partie de code la plus critique du système. C'est dans le contexte du noyau que sont manipulés des structures de données sensibles : la table des processus, la table des pages mémoires... C'est pour cela qu'il n'est généralement pas possible de préempter l'exécution du noyau. Pourtant, si le noyau préempte un processus et met longtemps à compléter son chemin d'exécution, cela introduit des latences d'exécutions. L'exécution du noyau peut empêcher l'exécution de processus de hautes priorités.

La première solution est de modifier la structure du noyau pour raccourcir les chemins d'exécution. En plus de cette première approche, on peut décider que le noyau puisse être préempté.

2 La norme POSIX (Portable Operating System Interface) est issu de la nécessité pour les différents systèmes de type Unix (d'où le « X » du nom de la norme) d'avoir une interface identique, simplifiant ainsi la portabilité des applications.

26/104

La préemption du noyau - La préemption du noyau

Si un processus demande un service au noyau (suite à un appel système, par exemple), on considère que son chemin d'exécution passe en mode noyau. Dans le schéma 7, le chemin d'exécution du processus 1 peut être compris comme la « trace » verte. La préemption du noyau intervient lorsqu'une tâche de plus haute importance a aussi besoin de s'exécuter dans l'espace noyau. Dans le schéma précédent, le processus 2 préempte l'exécution du processus 1, qui est en mode noyau, au profit de sa propre exécution. Ainsi, la tâche de plus haute importance n'est pas obligée d'attendre la fin du chemin d'exécution noyau du premier processus.

Toutefois, si l'on accepte que le noyau soit ré-entrant, il faut baliser les portions où sont faites des modifications dans les structures sensibles du noyau. Il faut empêcher que deux processus modifient les mêmes données lorsqu'ils ont un accès concurrent au noyau. Le patch-RT met en place, autour des portions de code critique, des structures spécifiques (« mutex3 », par exemple) qui empêchent l'accès simultané de ces portions. On protège ainsi l'accès aux structures sensibles et l'on assure la cohérence des données contenues.

4.1.3. La gestion des interruptionsDans un noyau standard, et pour un driver correctement construit, le traitement des interruptions se découpe en : une routine d'interruption (très courte) et une « softirq » (ou « tasklet »). La routine d'interruption essaye de faire uniquement le travail le plus important (copier les données depuis le « buffer » du périphérique vers un emplacement mémoire, modifier un bit d'acquittement sur le matériel...). Elle laisse le reste des traitements à la tâche de la « softirq ».

Les composants qui gèrent une interruption (ISR4 et softirq) préemptent les processus pour s'exécuter, quels que soit leurs priorités. Ce mécanisme peut-être pénalisant dans un système temps-réel : si le traitement de l'interruption est long, il empêche le processus de s'exécuter et apporte une latence dans le système. Il peut aussi y avoir un flot soudain d'interruptions. Dans un noyau classique, cela nécessite l'exécution de nombreuses routines d'interruptions à la suite. Pendant que les routines d'interruptions occupent le processeur, les processus ne peuvent pas s'exécuter.

Dans les systèmes temps-réel, il faut pouvoir décider que certaines interruptions soient retardées si leurs importance est moindre, comparé à l'exécution et à

3 MUTEX : MUTual Exclusion (exclusion mutuelle)4 ISR : Interrupt Service Routine

27/104

Illustration 7 : Préemption du noyau


l'aboutissement du traitement mené par un processus.

Bien sûr, on ne peut empêcher le signal électrique de l'interruption d'interrompre le fonctionnement du processeur. Seulement, lorsqu'un signal d'interruption arrive, un noyau patché (avec le patch-RT) prend le parti de créer un fil d'exécution noyau (un « thread noyau »). Il ne fait que cette opération avant de retourner à l'exécution du processus précédent : créer et compléter la structure contenant les informations du fil d'exécution. Le fil d'exécution contiendra le corps de la routine d'interruption.

L'avantage de cette configuration est que les fils d'exécution peuvent être ordonnancés au même titre que des processus classiques (par exemple, ils apparaissent dans la liste des processus que donne la commande ps). Il est possible de modifier la priorité d'exécution des routines d'interruption. La gestion du temps-réel sur le système repose ensuite sur la capacité de l'administrateur à échelonner correctement les priorités des processus. Il faut que les processus critiques aient la possibilité de mener leur traitement à temps et que l'ordonnancement des routines d'interruptions n'amènent pas la perte de données. Il faut aussi réfléchir à ce que n'apparaisse pas une situation d'inter-blocage (« deadlock »).

4.2. Modifications comportementales

4.2.1. Les modes de configurationLe patch-RT propose plusieurs configurations possibles pour la modification des sources. Une fois que le patch est appliqué, de nouvelles entrées apparaissent dans le menu de configuration du noyau, avant la compilation. Elles se trouvent dans le sous-menu « Preemption mode » du menu « Processor type and features ». Ces options sont :

• pas de préemption (PREEMPT_NONE)

Lorsque le première option est choisie, le noyau Linux fonctionne comme il le faisait dans les versions antérieures à 2.4. Lorsque du code s'exécute en mode noyau, il est impossible de le préempter. Ce mode est avantageux dans le sens où il y a moins de changements de contextes et donc moins de charge pour système (« overhead » lié à l'ordonnancement, par exemple). De plus, le cache est moins souvent renouvelé et donc mieux utilisé.

• préemption volontaire du noyau (PREEMPT_VOLUNTARY)

La deuxième option repose sur le fait que le code du noyau contient des appels à une fonction utilisée à des fin de déboguage : la fonction might_sleep. Traditionnellement, cette fonction vérifie si l'ordonnancement peut être effectué sans problèmes et affiche un message indiquant le résultat de ses tests. La deuxième configuration du patch-RT utilise cette fonction pour effectuer un appel à l'ordonnanceur. Ainsi, chaque endroit où la fonction apparaît devient un point de préemption possible. Cette option est sécurisante et améliore la réactivité d'un système. Elle présente le désavantage de restreindre la préemption à des zones bien déterminées du noyau.

• préemption du noyau (PREEMPT_DESKTOP)

La préemption du noyau est possible par l'insertion de verrous tournants

28/104

Les modes de configuration - Les modes de configuration

(« spin-lock ») autour des sections de code critique. Dans cette méthode, un processus qui bloque sur un verrou se met à exécuter une boucle infinie en attendant que le verrou ne se libère. La méthode trouve sa meilleure application sur les systèmes multi-processeurs.

Il y a tout de même certains défauts majeurs pour cette implémentation.

En général, le code qui est protégé par le verrou est court et donc, la boucle d'attente ne dure qu'un bref instant. Il faut toutefois comprendre que le temps d'attente de la boucle active est conditionné par la longueur du code qui est protégée. Cela va à l'encontre du déterminisme : on ne peut savoir à l'avance quel processus (et donc, quel longueur de code) va être la cause du blocage.

Si un processus détient un verrou, il empêche tout les autres processus de le préempter, même s'ils ne souhaitent pas accéder à la portion de code actuellement utilisée.

Dans le cas d'un système mono-processeur, l'attente active consiste à continuer d'autoriser l'accès au processeur pour une tâche qui ne fait rien d'autre que d'attendre et de tester la disponibilité de la ressource. Il y a donc un consommation de cycles processeurs.

• préemption complète (PREEMPT_RT)

La stratégie qui est mise en place dans la configuration précédente ne résout pas complètement le problème. Il faudrait que chaque portion de « code critique » soit protégée par son propre système de verrou. Pour cela, dans la configuration « préemption complète », la majorité des verrous qui étaient implémentés dans la configuration précédente sont transformés en « mutex ». Ainsi, le processus qui tente d'atteindre la ressource, et bloque sur le « mutex », est mis en sommeil laissant la possibilité à d'autres processus d'être ordonnancés. Le mécanisme mis en place permet de diminuer le temps de réaction des processus temps-réel. Les latences sont largement réduites.

4.2.2. L'héritage de prioritéIl existe un problème récurrent dans la théorie d'ordonnancement des tâches. Ce problème est connu sous la dénomination : « inversion de priorité ».

On présente généralement un exemple avec trois processus, de priorités croissantes.

29/104


Le processus 1, de plus faible priorité, s'exécute et protège un accès à une donnée sensible à l'aide d'un mécanisme de type « mutex ». Un processus de plus haute priorité (processus 3) est démarré. Il préempte l'exécution du premier processus puisqu'il possède une priorité plus élevée. Si le processus souhaite avoir accès à la même donnée que le processus de faible priorité, selon les mécanisme de mutex, il est mis en sommeil. Il va devoir attende que le processus de plus faible priorité termine sont traitement. Le problème apparaît si un processus de priorité « intermédiaire » (processus 2) est démarré car il préempte l'exécution du processus de plus faible priorité. Il retarde donc d'autant le redémarrage du processus de plus haute priorité (qui est toujours en attente de la libération de la ressource par le processus de plus faible priorité).

La solution est de faire hériter la priorité élevé du processus qui fait la demande de ressource, au processus qui la détient. Le processus qui détient la ressource est donc ordonnancé prioritairement. Il libère donc la ressource plus rapidement. Une fois qu'il libère la ressource, il retrouve sa priorité originelle, et se fait préempter par le processus de plus haute priorité qui faisait une demande concurrente. Le temps d'attente est donc réduit.

Si ce problème apparaît dans l'exécution de fils d'exécution noyau, cela peut avoir des effets désastreux (un processus de priorité élevé peut se retrouver bloqué quasi infiniment). C'est pour cela que le patch-RT met en place l'héritage de priorité sur les mécanismes de protection du noyau.

Thomas Gleixner, Ingo Molnar et d'autres contributeurs ont implémentés un mécanisme de protection, à base de mutex, rapide et robuste appelé « robust futex ». Ce mécanisme a été implémenté à partir des mutex légers (ou « futex ») en espace utilisateurs qui avait été apporté par Rusty Russell. Les « futex » ont été introduit dans le noyau à partir de la version 2.6.18 (septembre 2006). Il est a noter que ces structures ne sont accessible en espace utilisateur qu'à travers une librairie C GNU de version 2.5 ou supérieure.

4.3. Compteurs à haute résolutionPour que le noyau soit capable de répondre à l'arrivée d'un évènement, il faut qu'il

30/104

Illustration 8 : Exemple d'inversion de priorité

Compteurs à haute résolution - Compteurs à haute résolution

soit capable de distinguer l'arrivée de cet évènement dans le temps. La plus petite unité que le noyau est capable de résoudre est le « jiffy ». La fréquence (en Hertz) des « jiffies » est essentiellement calculée à partir d'une variable nommée HZ.

La diminution de cette unité de temps minimale permet d'augmenter la résolution temporelle du système. Mais, la mise à jour du compteur de « jiffies » nécessite l'exécution d'une routine d'interruption lié à l'horloge. Donc, il y a le risque de surcharger le système (avec le traitement de cette interruption) lorsque l'on augmente la résolution du système.

L'implémentation originale des compteurs fait apparaître des latences importantes.

L'implémentation des compteurs à haute résolution temporelle a été ajoutée pour l'architecture x86 depuis la version 2.6.20. L'architecture de base avait été rajoutée dans le noyau Linux depuis la version 2.6.18. On peut rendre fonctionnel ce système depuis le menu de configuration de la compilation du noyau. Le travail de développement continu d'être fait dans le patch-RT.

5. XenomaiPour implémenter le temps réel avec des systèmes de type GNU/Linux, on peut faire fonctionner deux noyaux côte-à-côte (on parle de systèmes à co-noyaux). L'approche consiste à ajouter un noyau (ou « micro-noyau ») à côté d'un noyau Linux classique. C'est l'approche qui est faite par Xenomai. Le micro-noyau s'occupe de la gestion des interruptions matérielles, fait fonctionner des tâches temps-réelles, apporte des fonctionnalités de gestion du temps...

5.1. HistoriqueOn situe généralement le lancement du projet Xenomai suite à la publication de l'article de Karim Yaghmour sur Adeos en 20015. Xenomai a été créé pour faciliter la migration des applications qui reposaient sur des

solutions temps-réels propriétaires vers une solution Open Source (système de type GNU/Linux). Un des points critiques de la migration est de continuer à garantir la bonne tenue des échéances (contrainte typique des systèmes temps-réels).

C'est en 2002 que Xenomai a été porté sur Adeos. Ceci a permis d'affranchir Xenomai des dépendances liés aux différents systèmes d'exploitations existants et d'améliorer la prédiction des latences d'interruptions.

En 2003, le projet originel a été fusionné avec le projet RTAI dont le but était lui aussi de proposer un solution temps-réel libre. Le code source de RTAI et la partie spécifique à Xenomai (qui s'appelait alors RTAI/fusion) sont restés relativement indépendants. C'est après ce regroupement, et au cours des développements qui ont suivi, que le projet Xenomai a gagné sa capacité d'être porté sur différentes architectures matérielles.

En 2005, le projet Xenomai s'est séparé du projet RTAI et a repris son indépendance. À cette date, le projet Xenomai a pris son nom actuel.

5 « Adaptive Domain Environment for Operating Systems », dans la Bibliographie

31/104


5.2. AdeosAdeos (« Adaptive Domain Environment for Operating Systems ») est une couche de virtualisation disponible sous la forme d'un patch du noyau Linux. Adeos a pour but d'autoriser et de partager l'accès à une même ressource physique pour plusieurs systèmes.

5.2.1. Les domainesL'une des applications courantes de cette couche est le fonctionnement de deux noyaux côte à côte sur le même matériel.

Pour rendre cela possible, Adeos introduit le concept de « domaine ». Généralement, un système d'exploitation complet prend place dans un domaine, bien que ce ne soit pas une contrainte. Par contre, le point commun de ces domaines est le fait qu'ils sont en compétition pour traiter des événements externes (interruptions matérielles) ou internes (exceptions, interruptions logicielles).

Un système, cantonné dans un « domaine », se définit un espace d'adressage privé et des abstractions telles que les processus, les adresses virtuelles... Entre parenthèses, un tel système n'est pas restreint à son domaine s'il est capable de détecter Adeos et de l'utiliser comme intermédiaire. L'utilisation d'Adeos par un système donné lui permet de partager des ressources avec d'autres systèmes.

1. Dans l'usage général, le système contenu dans le domaine accède au matériel sans aucune restriction. Tout se passe comme si Adeos n'était pas présent.

2. Adeos reçoit le contrôle du matériel lorsqu'une interruption matérielle ou logicielle surgit. Le système Adeos peut aussi accéder au matériel pour ses propres besoins.

3. Lorsque le système d'exploitation n'a pas conscience de la présence d'Adeos, Adeos doit préparer l'environnement de traitement des interruptions pour le système sus-jacent. En particulier, il présente la pile de façon à ce que le

32/104

Illustration 9 : Adeos et les domaines

Les domaines - Les domaines

gestionnaire d'interruption du système agisse correctement.

4. Lorsque le système a connaissance de la présence d'Adeos, il peut alors demander à avoir accès aux ressources des autres domaines, demander à changer la priorité sur son accès aux interruptions... La communication entre Adeos et le système devient bi-directionnelle.

5.2.2. Le pipeline d'interruptionAdeos supervise l'accès aux ressources par les différents domaines. Par exemple, Adeos hiérarchise l'accès aux interruptions en les distribuant à travers une « file d'interruption ».

La notification d'une interruption est postée à l'entrée du pipeline. Elle parcourt ensuite le pipeline. Les différents domaines sont placés les uns à la suite des autres, en fonction des priorités qui leurs ont été attribuées. Le domaine ayant la plus haute priorité reçoit la notification en premier.

Chaque domaine décide d'une action :

• accepter l'interruption (accept)

L'interruption est vue par le système contenu dans le domaine et elle est traitée.

• ignorer l'interruption pour le moment (stall)

L'interruption n'est pas traitée immédiatement par le domaine. Par exemple, le domaine se protège de l'irruption d'interruptions pendant qu'il effectue un traitement particulier.

• se défausser de l'interruption (discard)

L'interruption passe au domaine suivant comme si le système n'en avait pas eu connaissance.

• terminer une interruption (terminate)

L'interruption n'est plus propagée aux domaines suivants.

Une fois que le traitement a été mené par la routine d'interruption du domaine, le domaine concerné fait appel à un service de Adeos. Ce service autorise le domaine suivant dans le pipeline à prendre le contrôle du CPU et donc, de faire les traitements

33/104

Illustration 10 : Pipeline d'interruption et disposition des domaines


nécessaires.

Il a été évoqué la possibilité que le système soit dans l'incapacité de recevoir une interruption. Pour éviter que les notifications d'interruptions soient perdues pour le domaine, elles sont enregistrées dans une zone qui servent de « tampon » pour le domaine. Cette zone est appelée « log » d'interruption. Une fois que le système est de nouveau capable de traiter les interruptions, il tente de traiter toutes les interruptions en attentes. Cette étape permet de re-synchroniser les domaines.

5.3. Gestion du temps-réel

5.3.1. L'utilisation d'AdeosXenomai repose sur le système Adeos. Lors du patch du noyau, il est définit par défaut quatre domaines pour Adeos. Dans le premier domaine, le système temps-réel prend place (Xenomai utilise la dénomination de « nucleus »). Dans le second domaine, un système de type GNU/Linux fonctionne. Les deux autres domaines ne sont pas utilisés.

Le noyau Linux est de type GPOS6. Il est pratique d'avoir un tel noyau car il bénéficie d'un support matériel important (nombre de pilotes de périphériques). De plus, il permet de faire fonctionner des tâches Linux courantes. On a le bénéfice d'un système polyvalent (GNU/Linux), utilisé avec un système spécifique pour le temps-réel (Xenomai).

6 GPOS : General Purpose Operating System

34/104

Illustration 11 : Xenomai et le noyau Linux

L'utilisation d'Adeos - L'utilisation d'Adeos

Le schéma 11 illustre les deux domaines (contenant respectivement Linux et Xenomai), fonctionnant au dessus d'Adeos. On peut donc utiliser des applications spécifiques pour chacun des domaines. Puisque le système Adeos utilise une couche d'abstraction matérielle, il est relativement indépendant du matériel qui est sous-jacent.

Grâce au mécanisme de pipeline d'interruption (décrit au paragraphe 5.2.2.), Xenomai (qui est dans le domaine primaire) reçoit tout les événements avant le noyau Linux (qui se trouve dans le domaine secondaire). Xenomai peut donc traiter les interruptions immédiatement, quel que soit l'état du noyau Linux (même si, par exemple, le noyau utilise le mécanisme de « masque » du processeur pour cacher les interruptions).

Xenomai peut aussi privilégier le contrôle de ses fils d'exécution, quels que soit le domaine où ils résident. Ceci permet de garantir des temps de latence inférieurs à la micro-seconde, quel que soit la tâche menée par le noyau Linux.

Dans la figure 11, on observera que Adeos doit se situer entre la couche d'abstraction matérielle et Xenomai. La majorité des requêtes que doit traiter Adeos viennent donc de cette couche. En pratique, les services ont été implémentés dans des fichiers qui sont ajoutés aux sources du noyau Linux au cours du patch7.

Les fonctions spécifiques qui sont implémentées commencent généralement par le préfixe « rthal_ ». Dans le cas des systèmes de type ARM®, il faut explorer les fichiers kernel/xenomai/arch/generic/hal.c et arch/arm/xenomai/hal.c des sources patchées du noyau Linux.

5.3.2. L'architecture de XenomaiLe micro-noyau de Xenomai (« nucleus ») est en fait une abstraction de noyau temps-réel (RTOS) reposant sur :

• des structures de données

• des services (des méthodes)

• des flags

Parmi les structures de données qui sont manipulées par Xenomai, on peut retenir : « xnthread_t » qui est l'abstraction de tâche temps-réel, « xnsynch_t » qui est un objet générique permettant de synchroniser des tâches, « xntimer_t » qui est un implémentation générique de compteur temporel.

Parmi les différents services qui sont proposés par Xenomai, il faut comprendre au moins le « pod » et le « regsitre ».

Le pod (dénommé « xnpod » dans l'implémentation) est l'abstraction qui s'occupe du management des tâches temps-réel. C'est cette abstraction qui est responsable de la création et de la suppression des tâches (des structures « xnthread_t »), du changement de la politique d'ordonnancement, de l'appel à l'ordonnanceur... C'est un des éléments central du noyau temps-réel.

Le registre est un moyen de partager facilement les descripteurs d'objets. Lorsqu'un

7 En effet, Adeos (et donc, le système Xenomai) repose sur l'application d'un patch sur les sources du noyau Linux.

35/104


objet est créé, simultanément, une entrée est créée dans un registre. Ensuite, tout autre service qui veut utiliser l'objet utilise le nom symbolique (de l'objet) pour retrouver l'entrée correspondante dans le registre. Le nom de l'objet sert de « clé » pour retrouver l'entrée dans l'index. C'est finalement la structure identifiant l'objet, dans le registre (« xnhandle_t »), qui contient le descripteur de l'objet. La structure d'index partagé permet de centraliser les données.

5.3.3. Les modes d'exécutionIl est généralement fait état du mode d'exécution primaire et secondaire. Le premier traduit le fait que les fils d'exécution s'exécutent au dessus du domaine de plus forte priorité (le domaine contenant Xenomai). Le second traduit le fait que les fils d'exécution s'exécutent dans l'espace utilisateur courant (le domaine Linux).

5.3.3.1. La migration des fils d'exécutionXenomai dérive ses « threads » (xnthread) de la structure de « thread » (task_struct) implémentée dans Linux. En fait, un processus se voit attacher une structure particulière (appelée « real-time shadow ») lorsqu'elle fonctionne dans le domaine primaire.

Une telle architecture permet à une tâche temps-réel d'être ordonnancée indifféremment par l'un ou l'autre des domaines. C'est ce qui autorise la « migration » des tâches entre les domaines. Une tâche temps-réel qui fait un appel système ne pouvant pas être traité par Xenomai est « migrée » dans le domaine Linux pour répondre à sa demande. Elle reste dans le domaine correspondant pour le reste de son exécution (pour ne pas pénaliser la latence du système par la charge apportée lors de la migration de la tâche) tant qu'elle ne fait pas un appel temps-réel.

Lorsqu'une tâche temps-réel du domaine Xenomai s'exécute au dessus du domaine Linux, elle reste considérée comme telle. En effet, les priorités des tâches temps-réel de Xenomai s'échelonnent entre 1 et 99. Dans le système Linux, les tâches peuvent avoir une priorité s'échelonnant entre 1 et 139. Sachant que les tâches courantes ont une priorité comprise entre 100 et 139 et que les tâches dont la priorité est inférieure à 100 sont considérées comme temps-réel. Cela permet d'avoir une correspondance des priorités et garantie l'ordonnancement prioritaire. Toutefois, cela peut les pénaliser puisqu'elles sont soumises aux latences du système Linux.

Un autre des avantages de la réutilisation de la structure de thread Linux apparaît lors de la période de développement d'une l'application. Un processus temps-réel peut continuer à être tracé à l'aide d'une application de déboguage, quel que soit le domaine où il s'exécute.

5.3.3.2. Le temps-réel dans le mode secondaireSi une tâche est considérée comme temps-réel, il faut que sa priorité soit renforcé quel que soit son domaine d'exécution. Par exemple, une tâche s'exécutant dans le domaine primaire (donc, temps-réel) doit pouvoir être préempté par une tâche de plus haute priorité s'exécutant dans le domaine secondaire. Par contre, lors d'une tentative d'accès au CPU, une tâche non temps-réel (donc, pas connue par Xenomai) doit toujours être préemptée au profit d'une tâche temps-réel du premier domaine.

36/104

Le temps-réel dans le mode secondaire - Le temps-réel dans le mode secondaire

Toutefois, lorsque le second domaine ordonnance ses processus et décide de celui qu'il va exécuter, toutes les tâches (temps-réel ou non temps-réel) rentrent en compétition. Il faut comprendre qu'une tâche temps-réel dans le second domaine, bien qu'ayant une priorité plus élevée qu'une tâche quelconque, devra régulièrement laisser sa place pour l'exécution d'autres tâches. Le système Linux conserve son caractère de système multi-tâches.

Les tâches doivent être préservés des problèmes d'inversion de priorité. Xenomai le fait nativement, mais seul le noyau Linux patché avec PREEMPT_RT permet cette protection. Il faut donc continuer à vérifier les différents cas si l'on utilise un système Xenomai basé sur la branche principale du noyau Linux.

5.4. API temps-réel

5.4.1. Les « Skins »Les applications industrielles embarqués ont généralement demandées un effort de déboguage et d'optimisation important avant d'atteindre leurs formes stables. Au sein d'une entreprise, les personnes compétentes dans le domaine du temps-réel ne peuvent pas forcément être employées dans un processus de portage long et contraignant. Les équipes de développement ne sont pas prêtes à changer la base de leurs applications : le changement d'API représente une charge de travail trop importante (changement de nombreux appels de fonctions, modifications des objets manipulés...).

Pourtant, bien que présentant des différences subtiles, les objets ou les concepts qui sont utilisés dans les API propriétaires sont sensiblement équivalents (mutex, appels systèmes, tâches de synchronisation, ordonnancement). Il a donc été crée des objets génériques dans l'environnement de Xenomai et des couches sont rajoutées qui implémentent la grammaire ou les mécanismes spécifiques de chaque API. Ces couches sont appelées « skins » et miment le comportement d'un certain nombre d'APIs temps-réels (POSIX 1003.1b, pSOS+, RTAI, uITRON, VRTX, VxWorks).

Les « skins » se présentent comme des modules noyau qui peuvent être chargés au besoin. On peut aussi décider que ces fonctionnalités soient intégrées dans le noyau au moment de la compilation plutôt que d'avoir des modules.

5.4.2. L'API native temps-réelXenomai propose sa propre API pour la réalisation d'applications temps-réel. Cette API se veut relativement succincte et laisse au programmeur le choix d'agencer les fonctionnalités de bases pour créer des mécanismes évolués.

37/104


Les appels systèmes invoqués par les applications temps-réels dans l'espace utilisateur sont redirigés vers le noyau depuis l'espace utilisateur grâce à une librairie spécifique de Xenomai : libnative.so.

On peut créer des modules temps-réels qui font appels aux services du micro-noyau. Cette approche, qui ressemble à celle préconisée par d'autres système temps-réel (RTAI, notamment), n'est pas à privilégier. Il est préférable d'avoir des applications temps-réels, évitant ainsi que le noyau ne soit complètement bloqué (et impose un redémarrage du système) à cause d'une erreur d'exécution du module temps-réel.

Dans cette API, on fait appel aux services apportés par le noyau temps-réel à l'aide d'appels systèmes spécifiques. Parmi ces appels, on retrouve :

• le management des tâches temps-réel

Il existe un certain nombre d'appels systèmes pour créer ou détruire des descripteurs de tâches temps-réels. La création et le démarrage des tâches est indépendant (à l'opposé de l'API POSIX, par exemple). Il est ainsi possible d'imaginer des fonctions qui se chargent d'initialiser tout les objets et d'autres qui se chargent de les détruire. Le lancement des traitements est alors clairement indiqué à l'endroit où l'opération doit être effectuée.

Il est possible d'introduire des mécanismes d'attentes entre les tâches. On peut aussi explicitement déclarer une tâche comme étant périodique, ou lui imposer un délai d'attente. Il est possible qu'une tâche fasse des appels à l'ordonnanceur, pour elle même ou pour une autre tâche. On peut donc imaginer un modèle où une tâche principale coordonne l'activité de toutes les

38/104

Illustration 12 : Appels systèmes temps-réels depuis l'espace utilisateur et l'espace noyau

L'API native temps-réel - L'API native temps-réel

autres.

• la gestion du temps

Les principaux mécanismes consistent à gérer des compteurs de temps. La particularité de l'API Xenomai se situe dans sa capacité à adresser une horloge plusieurs horloges, en fonction des besoins de l'utilisateur. De plus, il est possible, au moment de la compilation, de choisir si l'horloge système compte le temps en « ticks » ou en unité de temps (nano-seconde, par exemple). L'API propose alors des méthodes de conversions.

Le fait de ne compter qu'en « ticks » système permet de réduire la charge en ce qui concerne la conversion des données brutes en unités compréhensibles à un niveau macroscopique. Par contre, il faut évaluer l'effet des masquages d'interruptions et l'irrégularité apportée à la base de mesure.

• la synchronisation entre tâches

Dans cette section, il faut prendre en compte les méthodes qui permettent d'utiliser des « mutexs », des « sémaphores ». Ce sont essentiellement les appels pour créer l'objet, le retrouver depuis son nom symbolique, le détruire et effectuer les opérations de bases de cet objet (acquérir ou libérer, dans le cas des « mutex »).

• la communication entre tâches

La communication entre les tâches peut se faire par le biais de files de messages, de tubes inter-processus (IPC) ou de portions de mémoire partagées.

Le premier mécanisme est généralement utilisé au sein d'un même programme qui est multi-threadé. Le second est utilise entre deux (ou plus) processus indépendant qui ne se connaissent pas nécessairement au moment du démarrage.

5.4.3. Real-Time Driver ModelRTDM est un « skin » spécifique pour la gestion des entrées/sorties sur périphériques. Par exemple, il permet de créer des modules ou des drivers de périphériques ayant des contraintes temps-réel qui sont portables. En effet; les modules implémentés utilisent une API commune.

39/104


40/104

Travail réalisé

Portage et évaluation de Xenomai sur une plateforme PC/104


1. Environnement de développementParce que le matériel et les performances du système embarqué ne sont pas suffisantes pour développer les logiciels nécessaires (car, pas destinées à cet usage), on choisit généralement de déporter le développement sur un ordinateur plus puissant. Le choix au sein du centre de service eLiSe est de faire le développement sur un ordinateur de type PC. Ce système hôte, sur lequel j'ai effectué le développement du système (récupération des sources, paramétrage, compilation...), fait fonctionner la version la plus à jour de la distribution Ubuntu. De cette façon, il n'y a pas de différences entre le type du système hôte et du système cible (tout deux de type Linux).

Pour effectuer le portage de Xenomai, j'ai du commencer par organiser mon environnement de développement. Ensuite, j'ai du apprendre à utiliser des outils spécifiques au développement. Enfin, j'ai installé les outils de compilation croisée.

1.1. L'arborescence de travailJ'ai suivi les conseils du livre « Building Embedded Linux Systems »8 pour organiser mon environnement de travail. J'ai donc créé un dossier de projet nommé xenomai/. À l'intérieur de ce dossier, on trouve les sous-dossiers suivants : archives/, build/, conf/, debug/, images/, rootfs/, sysapps/, tmp/.

• archives/ Ce dossier contient les archives sous forme compressées des fichiers sources que j'ai utilisé. Par exemple, on y retrouve l'archive du compilateur croisée. Ainsi, on conserve une trace des ressources utilisées pour de futurs développements.

• build/ À l'intérieur de ce dossier se trouvent les fichiers issus des compilations du noyau (et donc, de Xenomai). Je conservais ainsi les dossiers des sources de Linux et de Xenomai, vierges des binaires de compilations.

• conf/ Pour éviter de retaper les mêmes commandes d'une fois sur l'autre, j'ai fait un certains nombres de scripts Bash. J'ai décidé de les placer dans ce dossier.

• debug/ Pour le test de l'environnement de Xenomai, j'ai eu besoin de faire la compilation croisée de quelques applications de déboguage. J'ai donc placé les exécutables correspondants dans ce dossier.

• images/ La compilation du noyau génère beaucoup d'objets mais tous ne sont pas utiles dans l'utilisation finale du système. Dans mon cas, je ne gardais que le fichier binaire du noyau, le fichier binaire compressé du noyau, la table des symboles, le fichier de configuration (.config).

• rootfs/ Ce dossier contient l'architecture d'un système de fichier selon la norme du FHS et les fichiers utiles à tous les types de systèmes. On y retrouve, par exemple, le fichier /etc/fstab, les fichiers de la libc, les fichiers de périphériques).

• sysapps/ Ce dossier contient les sources des applications intégrées dans le

8 Voir dans la Bibliographie

42/104

L'arborescence de travail - L'arborescence de travail

système. Par exemple, je conservais les sources de BusyBox ou de SysVinit dans ce dossier. Il contient aussi les portions de code que j'ai créé pour utiliser les API temps-réels.

• tmp/ Traditionnellement, ce dossier contient des fichiers temporaires (tentatives ou essais de compilations, développements...).

Dans un premier temps, j'avais décidé de suffixer certains de ces dossiers (les dossiers build/ et rootfs/) par les terminaisons _xeno ou _std pour en expliciter le contenu (pour indiquer qu'ils contiennent des documents liées à Xenomai ou à leurs versions « standards »).

En fait, j'ai été amené à faire plusieurs compilations d'un même type de système avec des paramètres de compilation différents. J'ai donc changé de pratique. J'ai inséré trois sous-dossiers : Branches/, Tags/, Trunk/. Ces trois sous-dossiers sont habituellement rencontrés dans les projets de développement. Le dossier Branches/ me permettait de conserver plusieurs versions différentes. Le dossier Trunk/ du dossier rootfs/ contenait une version du système de fichier dont j'avais la certitude que ses éléments étaient fonctionnels. Le dossier Trunk/ du dossier build/ contenait les éléments de la compilation actuellement menée.

1.2. Les outils

1.2.1. Logiciel de suivi de version : gitDe façon à mettre en place un développement basé sur les dernières versions des sources, il a été décidé d'utiliser le logiciel de suivi de version git9. Ce logiciel permet de faire une copie locale des fichiers depuis un dépôt. En plus de copier l'arborescence de fichiers du projet que l'on récupère, le logiciel met en place un certains de nombre fichiers qui lui sont propres et qui lui permettent de garder une trace de l'historique du projet.

En plus de pouvoir mettre à jour les sources régulièrement, j'ai pu personnellement créer des branches de développement sur le PC hôte.

• D'abord, j'ai créé une branche contenant les sources du noyau Linux dans leurs version 2.6.28. En effet, pour l'architecture ARM®, le patch Adeos ne prend pas en compte les évolutions de maintenance (corrections de bugs).

• J'ai dupliqué cette branche et j'y ai appliqué le patch de Xenomai dans sa version 2.4.8. Une fois que les modifications ont été apportées aux fichiers sources, j'ai choisit de les « suivre » grâce à la fonction correspondante du logiciel git.

• Enfin, j'ai créé une branche spécifique depuis la version des sources Linux 2.6.28 pour appliquer une version de Xenomai patchée. Ces patchs m'ont été proposés au cours d'un échange avec la « mailing-list » d'entraide de Xenomai.

1.2.2. Le système d'information du centre de serviceDans le centre de service eLiSe, au sein duquel j'ai travaillé, chaque personne dispose

9 Une présentation détaillée du fonctionnement de git est faite en page 86, en Annexe

43/104


de sa propre machine pour effectuer son travail. Toutefois, tout les postes sont en réseau et peuvent accéder à des ressources communes, disponibles sur un serveur. Le serveur est appelé « gforge ».

En plus de pouvoir récupérer les données depuis le serveur (en faisant de la copie tunnelée par SSH), il a été mis en place un système de montage de dossier par NFS. Ainsi chaque ordinateur peut accéder à un dossier nommé partage dont le contenu est sur le serveur.

1.2.3. Portail de collaboration : TracTrac est un outil de gestion de projet. Il comprend :

• un wiki

Ce composant est utilisé pour que tout le consultants créent une base de connaissance. Ils remplissent les pages de façon collaborative. J'ai créé des pages sur le Wiki, dans la section réservée à Xenomai, décrivant la marche à suivre pour mettre en place l'environnement de compilation, par exemple.

• une système de gestion de version

Trac peut être couplé avec le logiciel de suivi de version Subversion. Lorsque l'on met à jour les fichiers sur le serveur svn, ils apparaissent dans l'interface web. On peut parcourir les éléments sans avoir à les télécharger sur la machine de développement.

• un système de « billets »

Trac un outil accessible de façon décentralisé. Bien que les données et le logiciel qui servent de base à l'architecture soient contenus sur le serveur « gforge », les postes du centre de service peuvent accéder au portail grâce à un navigateur Internet.

44/104

Portail de collaboration : Trac - Portail de collaboration : Trac

L'outil étant accessible depuis Internet, il comprend un système d'authentification avec mot de passe. Il est ainsi possible pour des clients de suivre l'avancement d'un projet, depuis ce portail, de façon sécurisée.

La combinaison du Wiki et du logiciel de suivi de version est très utile car elle permet de conserver un historique des tâches menées sur une plateforme donnée. Au cours des premiers mois, j'ai souvent utilisé cet deux composants pour voir les opérations qui avaient été menées sur la carte Viper. Je me suis souvent inspiré des méthodes utilisées par le passé (pour la mise en place des outils de compilation croisée, pour la modification du script de démarrage de la carte...).

1.3. Les outils de compilation croisée

1.3.1. ContraintesLa compilation vers la carte Viper nécessite des outils capables de fonctionner sur le PC hôte, et capables de produire des binaires compatibles avec le matériel présent sur la carte : ce sont les outils de compilation croisée (compilateur, éditeur de liens...).

On notera que le compilateur doit être assez récent pour pouvoir supporter les options de compilation liées au standard EABI. C'est au cours de la première compilation de Xenomai que ce point a été soulevé. J'avais commencé par installer et utiliser les outils fournis sur les Cds livrés avec la carte. Mais la version de cette chaîne de compilation était trop vieille et ne supportais pas les options liées à EABI. Il a fallu

45/104

Illustration 13 : Page d'accueil du portail Trac dans le navigateur Firefox


trouver la raison de l'échec de la compilation dans les messages de compilation, puis faire une recherche et récupérer les outils sur le site du support Internet du constructeur de la carte.

Lorsque j'ai eu à tester l'environnement Xenomai, j'ai du activer une fonctionnalité spécifique de Xenomai. Le fait d'activer cette fonctionnalité a, de nouveau, soulevé des problèmes de compilation.

L'un des mainteneurs du projet Xenomai m'a indiqué que le problème était dû à la chaîne de compilation. Cette fois-ci, la version du compilateur était trop récente et était sensible à certains paramètres. J'ai donc décidé de changer à nouveau d'outils et d'utiliser ceux qu'il me garantissait comme fonctionnels.

1.3.2. DépaquetageL'installation des outils est très simple. On commence par aller chercher le paquet qui contient les outils, depuis le dossier de partage /media/nfs/partage/viper/ :

cp /media/nfs/partage/viper/arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 ~

Puis, on installe cet environnement de compilation dans le dossier /usr/local/arm/ :

sudo mkdir /usr/local/arm && cd /usr/local/arm

sudo tar -xjf ~/arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

1.3.3. Modification des variables d'environnementLes logiciels sont désormais présents dans le dossier /usr/local/arm/arm-2008q1/bin/. Pour pouvoir facilement les utiliser, j'ai modifié une variable d'environnement du système. Pour que tout les utilisateurs puissent avoir un accès à ces exécutables, il faut modifier la variable PATH dans le fichier /etc/environment de la façon suivante :

PATH="/usr/local/arm/arm-2008q1/bin:/usr/local/bin[...]"

J'ai rajouté le chemin vers les fichiers exécutables de la chaîne de compilation au début de la variable PATH.

1.3.4. Tests de l'environnementSi l'on veut vérifier la prise en compte de ces manipulations (après redémarrage du système), dans un terminal, on tape :

arm-none-linux-gnueabi-gcc --version

Cette ligne de commande doit normalement donner un aperçu de la version du logiciel

46/104

Tests de l'environnement - Tests de l'environnement

et de sa configuration.

Pour tester le fonctionnement du logiciel, j'ai mené la compilation de plusieurs autres sources. En particulier, j'ai compilé un noyau Linux non patché et ses modules. Cet exécutable a été utilisé au cours des essais du chargement du noyau par TFTP expliqué dans la partie 2.3.1.. J'ai aussi compilé le logiciel BusyBox.

Le fait que les exécutables (noyau Linux, BusyBox) fonctionnent correctement permet de valider le bon fonctionnement du compilateur, du bon déroulement de l'édition de lien sur la librairie C... On peut considérer qu'un exécutable aussi sensible que le noyau est un test approprié pour la validation.

2. Prise en main de la carte Viper

2.1. Le chargeur d'amorçage : RedBootLe chargeur d'amorçage (ou « bootloader ») est un logiciel de taille généralement faible qui se charge de vérifier le matériel présent sur la carte et d'effectuer des opérations simples de management. Il est aussi responsable du chargement du noyau, et de fait, du système. L'utilisation de « bootloader » est courante dans les systèmes embarqués. En effet, les plus petits systèmes ne disposent généralement pas de BIOS. De plus, les chargeurs d'amorçage sont généralement configurables, plus facilement qu'un BIOS.

Le chargeur d'amorçage de la carte Viper (appelé RedBoot) dispose de ces fonctionnalités de base. Il possède aussi un éventail de fonctions plus évoluées accessible depuis une invite de commande (management de la mémoire, gestion de l'horloge...). Par exemple, RedBoot utilise un script pour effectuer le démarrage du système. Ce script est éditable et personnalisable à volonté. Pour modifier le script de démarrage, on tape la commande dans l'invite de RedBoot :

RedBoot>fconfig

J'ai du apprendre à utiliser cette fonctionnalité essentielle pour autoriser la conservation des éléments du système (noyau et système de fichier) de façon déportée. Pour mieux appréhender cette fonctionnalité, j'ai fait des essais de configurations mixtes (noyau dans la mémoire Flash, système de fichier déporté sur le PC de développement...) ; notamment, avec le précédent noyau Linux qui avait été porté sur la carte.

Au cours de ces manipulations, j'ai appris que RedBoot, en commandant le démarrage du niyau, est responsable de certains comportements du système GNU/Linux (choix du périphérique servant de console, vitesses de transferts des données...).

Le chargeur d'amorçage RedBoot est dérivé d'un autre chargeur plus connu : eCos. J'ai donc dû rechercher certaines informations sur l'utilisation de ce logiciel dans le manuel de eCos.

47/104


2.2. Communication avec la carte ViperLa carte Viper ne possède pas d'écran ou de clavier puisque c'est un système qui est censé fonctionner en autonomie lorsqu'il est déployé dans un contexte industriel.

2.2.1. Liaison série avec C-KermitLa méthode de connexion habituelle est le raccordement du PC de développement et de la carte Viper par un câble série spécifique dit : « null-modem cable ». Dans ce câble, la pin d'envoi des données, à l'une des extrémités, est reliée à la pin de réception des données à l'autre extrémité. Il permet à deux ordinateurs de pouvoir s'échanger des données sans avoir besoin d'un modem entre ceux-ci. On peut vérifier le câble avec un simple voltmètre.

Pour communiquer avec la carte, on démarre un logiciel d'émulation de terminal. Il a été choisit d'utiliser le logiciel C-Kermit. Ce choix a été dicté par la compatible entre le logiciel d'émulation de terminal et la gestion de la liaison série du logiciel RedBoot. La communication par la liaison série permet indifféremment :

• de se connecter sur la console de RedBoot

• d'obtenir les informations de la console de démarrage du noyau Linux

• de se connecter à la carte Viper lorsqu'un terminal fonctionne sur l'un des ports série de celle-ci

L'avantage de cette connexion est la possibilité d'envoyer des caractères d'interruption (du type « Ctrl+C »). Entre parenthèses, c'est ce caractère qui permet de notifier l'interruption du script de démarrage à RedBoot et d'accéder à son invite de commande.

J'ai malheureusement eu des problèmes avec cette connexion. En effet, lorsque la carte reste trop longtemps sous tension, il devenait impossible d'avoir des données compréhensibles. Parfois, le logiciel C-Kermit n'affichait plus du tout de données en provenance du port série.

Pour trouver la cause de ce problème, j'ai adopté une approche « top-down ». J'ai commencé par vérifier que les paramètres du programme (fonctionnant sur le PC) étaient bon : choix du port série, format des données... L'apparition d'un flot de caractères non compréhensibles m'a fait supposer un problèmes de synchronisation ; j'ai donc particulièrement vérifié la vitesse de transmission des données. J'ai ensuite vérifié l'état du câble reliant les deux machines. Puis, tout les éléments précédents étant corrects, j'ai observé ce port série avec un oscilloscope. Je me suis auparavant documenté pour comprendre comment les octets de données sont envoyés sur une liaison série. J'ai découvert que la ligne de communication tombait quasiment au même niveau que la masse après quelques instants de fonctionnement, alors que son état de repos (dans la norme) est un état de tension haut. J'en suis donc arrivé à la conclusion que le contrôleur série de la carte est endommagé.

2.2.2. Liaison Ethernet et console TelnetÉtant donné les problèmes que j'ai pu avoir avec le port série, j'ai décidé d'utiliser un client Telnet depuis le PC hôte, pour se connecter à la carte. J'ai choisit cette solution,

48/104

Liaison Ethernet et console Telnet - Liaison Ethernet et console Telnet

car ainsi, on utilise ainsi le contrôleur Ethernet de la carte au lieu du contrôleur de la liaison série. De plus, j'ai découvert qu'il était aussi possible d'avoir accès à la console du chargeur d'amorçage par cette méthode.

J'ai utilisé deux configurations pour relier le PC à la carte :

• un câble Ethernet croisé qui relie directement les cartes réseaux des deux machines. Cette configuration ne dépend pas d'un matériel supplémentaire.

• un concentrateur placé entre le PC et la carte ; les deux machines étant reliées à cet appareil central par des câbles Ethernet droits.

Lorsque le système ne démarre pas (pas de noyau présent, par exemple...), le chargeur d'amorçage reste en fonction et présente son invite de commande. Il est possible d'avoir cette invite de commande autrement que par la liaison série. En effet, le chargeur d'amorçage se place en écoute sur le port Ethernet. Je pouvais alors m'y connecter depuis le PC de développement en initiant une connexion Telnet sur le port 9000. Ainsi, il faut taper la commande, sur le poste fixe :

telnet 192.168.0.118 9000

Trying 192.168.0.118...

Connected to 192.168.0.118.

Escape character is '^]'.

[...]

Lorsque le système d'exploitation de la carte est démarré, si un serveur Telnet fonctionne il est possible de s'y connecter par la liaison Ethernet. Si ce serveur a été configuré par défaut, il est en écoute sur le port 23, selon la classification des ports bien connus (« well-known ports »). Il suffit alors de donner l'adresse IP de la carte Viper au client Telnet sur le PC de développement :

telnet 192.168.0.118

La connexion par Ethernet présente un défaut majeur : on ne peut pas avoir accès aux informations de la console noyau au cours du démarrage. En effet, le noyau est capable d'afficher les informations de démarrage sur un port série car il charge un minimum de support pour une liaison de ce type. La même chose ne peut être faite avec le port Ethernet, ce qui nécessiterait de charger toute la pile réseau au préalable. Entre le moment où RedBoot passe la main au démarrage du noyau et le moment où le système est pleinement opérationnel, il n'y a aucun programme en écoute sur le port Ethernet.

2.3. Configuration de démarrage

2.3.1. Le chargement du noyau par TFTPPlutôt que de flasher la mémoire de la carte à chaque nouvelle compilation du noyau, j'ai décidé d'utiliser la capacité du chargeur d'amorçage à récupérer des fichiers depuis un poste distant par le protocole TFTP. On gagne ainsi le temps nécessaire à la

49/104


procédure de copie sur la mémoire Flash de la machine. De plus, la mémoire Flash est limitée en terme de nombre de recopies. On évite donc d'user prématurément la puce mémoire.

J'ai choisi de le recopier en grande partie le script de démarrage qui était présent à l'origine sur la carte Viper. J'ai modifié deux lignes de façon à rendre la procédure possible :

RedBoot>ip_address -l 192.168.60.118

RedBoot>load -r -b %{FREEMEMLO} -h 192.168.0.117 -m tftp zImage-2.6.28-xeno

La première ligne permet au chargeur d'amorçage de paramétrer les connexions réseaux. Le fait d'attribuer une adresse IP à la carte permet à RedBoot de déduire le réseau associé et le masque de sous-réseau. Une fois la configuration réseau effective, il peut aller télécharger (avec la directive « load ») le fichier spécifié sur le serveur TFTP se situant sur la machine dont l'adresse IP est donnée. Il place les données à l'adresse mémoire indiqué dans l'alias « FREEMEMLO ».

2.3.2. Le montage du système de fichier par NFSPour les mêmes raisons (rapidité de mise à jour du système de fichier sur la cible...), j'ai décidé de conserver l'image du système de fichier sur la machine hôte et de monter ce système de fichier grâce au protocole NFS.

Il existe un autre avantage lié à la conservation du système de fichier sur la machine de développement : il y a la possibilité de modifier les fichiers en cours de fonctionnement. J'ai utilisé cette fonctionnalité pendant le développement des applications. Je menais la compilation sur le PC hôte puis je plaçais le code compilé dans l'image du système de fichier pendant son fonctionnement. Cela le rendait immédiatement disponible au système Linux fonctionnant sur la Viper, sans que je sois obligé de flasher la mémoire et de redémarrer le système.

Pour commencer, j'ai du vérifier que la capacité de montage du système de fichier par NFS était activée dans la configuration du noyau Linux. Ensuite, j'ai modifié le script de démarrage de RedBoot. Pour simplifier la modification du script en lui-même, j'ai définis un alias qui comporte la ligne de paramètres pour le noyau :

RedBoot>alias cmdlinenfs=\""rootfs=/dev/nfs/ root=/srv/nfsboot/ nfsvers=3,tcp ip=192.168.0.118:192.168.0.117::::off"\"

Ce qui fait que le noyau reçoit cette ligne de paramètres lorsque le script de démarrage exécute la commande :

RedBoot>exec -c %{cmdlinenfs}

J'ai construit la chaîne de paramètres en me basant sur une précédente chaîne de paramètres définie dans RedBoot. J'ai aussi directement regardé les explications qui sont données dans le fichier kernel-parameters.txt, fournis avec le noyau Linux.

50/104

Création du système de fichier - Création du système de fichier

3. Création du système de fichier

3.1. MotivationsAu cours des premiers tests, je devais normalement réutiliser un système de fichier existant. Malheureusement, ce système de fichier a été créé de façon à autoriser seulement des sessions utilisateurs avec mot de passe. Les mots de passe n'étaient pas ceux traditionnellement utilisés au sein du centre eLiSe ou fixés par le constructeur de la carte.

Pour contourner ce problème, j'ai tenté de passer des arguments au noyau. Pour cela, j'ai modifié la chaîne de paramètres passée au noyau dans le script de démarrage de RedBoot. Par exemple, j'ai tenté de passer l'argument « -S » pour faire initialiser le système en mode utilisateur unique. J'ai découvert que cette option ne permet pas de débloquer le système. En effet, le système de fichier était issus d'un distribution Debian modifiée. Dans les distributions de ce type, le fait de passer l'argument « -S » sous-entend que l'utilisateur unique est l'administrateur du système ; il est tout de même demandé le mot de passe de ce super-utilisateur.

J'ai aussi tenté de donner directement le chemin de la première application à lancer grâce au paramètre « init ». J'avais donc un alias du type :

RedBoot>alias cmdline="init=/bin/sh"

Dans ce cas, l'application doit effectivement démarrer mais elle ne se place pas en attente sur le port série. Il n'est donc pas possible d'avoir un environnement de travail depuis l'interpréteur de commande.

Enfin, j'ai tenté de faire démarre l'application « getty » de la même façon que précédemment (en donnant le chemin vers cet exécutable). Cette application sert d'intermédiaire : elle se place en écoute sur le port série et est censé démarrer un interpréteur de commande quand elle détecte une connexion. En fait, il est d'abord fait appel à « sulogin » (qui se charge de gérer l'authentification de l'utilisateur) avant de démarrer un interpréteur de commande.

J'ai découvert seulement plus tard, dans les pages du manuel, que le programme « sulogin » lis les fichier /etc/passwd et /etc/shadow. C'est pour cela qu'il demande le mot de passe du super utilisateur. Si ces fichiers n'existent pas, le mot de passe n'est pas demandé. Peut-être aurait-il fallu supprimer les deux fichiers pour ne pas avoir de demande de mot de passe.

Au final, je n'ai pas réussi à passer outre cette protection par mot de passe. En accord avec mon encadrant, il a été décidé de créer entièrement un système de fichier. Ce choix a été fait pour contrer le problème mais il se révèle, dans le cadre de ma formation, que c'est une démarche instructive pour la compréhension globale d'un système. De plus, dans le cadre des systèmes embarqués, le fait de créer soi-même le système de fichier permet de s'assurer que l'on garde des proportions acceptables en terme de taille mémoire. J'ai fait cela en suivant différentes démarches décrites dans « Building Embedded Linux Systems » ou dans « Linux From Scratch »10 (LFS).

10Voir dans la Bibliographie

51/104


Une autre raison qui conforte dans la création d'une nouvelle arborescence de fichier est la capacité à maintenir et à finement adapter le système à la carte. En effet, j'ai tenté plusieurs fois de copier une arborescence de fichier d'une distribution existante (Debian et OpenSuse) et de la simplifier pour qu'elle s'adapte à la carte, malheureusement, ceci aboutit à des erreurs qu'il est difficile de retracer.

3.2. Squelette de base

3.2.1. Les directives du FHSSelon les directives du « Filesystem Hierarchy Standard », un certain nombre de dossiers doivent être présent dans un système de fichier de type Linux/Unix. Ceci permet aux applications de pré-supposer les emplacements d'installation des fichiers ou des dossiers. Cela permet aussi à une personne de maintenir un système en ayant le même type de pré-supposés.

Pour les personnes qui connaissent les systèmes de type GNU/Linux, on retrouve l'arborescence de base de ces systèmes. Dans la liste suivante, j'ai détaillé les dossier que j'ai du peupler et dont l'architecture des sous-dossiers et des fichiers a été particulièrement travaillé au cours du stage.

• bin/ est le dossier qui contient les commandes essentielles au système. C'est dans ce dossier que prennent place les liens vers le logiciel BusyBox, pour donner l'impression que toutes les applications de la suite CoreUtils sont présents. J'ai essentiellement vérifié la présence de ces liens et le fait qu'ils pointaient bien vers le binaire de l'application.

• boot/ est le dossier qui contient le noyau et les configurations nécessaires au démarrage. Je n'ai pas placé les fichiers du noyau puisque j'ai essentiellement utilisé le chargement du noyau par TFTP. J'avais créé ce dossier dans le but de tester le système en totale autonomie sur la carte Viper.

• dev/ est le dossier qui contient les fichiers de périphériques. Je l'ai peuplé de façon statique (sans utilisation du logiciel udev) pour qu'il contienne les fichiers de périphériques usuels et ceux dont j'avais besoin pour accéder au matériel présent sur la carte Viper.

• etc/, ce dossier contient les fichier de configuration du système et des applications. J'y ai mis les différents scripts qui composent le système de démarrage et les fichiers de configuration de applications (en particulier pour les serveurs inetd et telnetd).

• lib/ est le dossier qui contient les librairies utiles au système. C'est dans ce dossier que j'ai du placer une copie de la libc. Cette version de la librairie C a été utilisé aussi au cours des compilations croisées.

• root/ est le dossier personnel de l'administrateur système. C'est un dossier optionnel selon les directives du FHS mais que j'ai rajouté puisque j'ai créé ce compte unique dans le système.

• sbin/ est le dossier qui contient les applications nécessaires au système et/ou utilisées pas l'administrateur du système. Il est nécessaire de créer ce dossier (au même titre que le dossier bin/) pour que BusyBox puisse placer les liens

52/104

Les directives du FHS - Les directives du FHS

correspondant à des applications telles que init.

• tmp/ est un dossier contenant des fichiers temporaires au cours du fonctionnement des applications.

• usr/, ce dossier correspond aux « UNIX System Ressources ». Il contient plusieurs sous-dossiers. En particulier, il comprend un sous-dossier bin/ qui contient les binaires des applications utilisées par les utilisateurs courant. J'y ai placé certaines des applications que j'ai compilé pour la Viper ; en particulier les applications de déboguage (gdbserver et strace).

• var/, c'est dans ce dossier que prennent place des fichiers susceptibles d'être modifiés par le fonctionnement des applications. En particulier, j'y trouvais le fichier qui sert de log d'erreur pour le système.

Les dossiers media/, mnt/, opt/ et srv/ ne sont pas décrit car je ne les ai pas utilisés au cours de l'étude.

Puisque j'utilisais un noyau Linux, il a été nécessaire de rajouter deux dossiers. Ces dossiers sont des points de montage pour des systèmes de fichiers virtuels. Ils permettent de faire l'interface entre les programmes (ou les utilisateurs) et le noyau. Ce sont :

• proc/ Ce système de fichier virtuel recense les informations du système (numéro de version du noyau, matériel, accès aux descripteurs de tâches...)

• sys/ Ce système de fichier virtuel a sensiblement le même rôle que le précédent. Toutefois, il possède une présentation du matériel de façon hiérarchique qui est plus compréhensible.

3.2.2. Les fichiers de périphériquesLe livre « Building Embedded Systems » rappelle qu'un certain nombre de « nœuds » doivent être présents dans le système de fichier. L'ouvrage rappelle aussi que les numéros majeurs et mineurs nécessaires pour la création des fichiers de périphériques sont contenus dans le fichier devices.txt du dossier Documentation/ des sources du noyau Linux. En suivant ces directives, j'ai créé les fichiers de périphériques suivant :

• console : interface d'affichage des informations du noyau

• mem : interface avec la mémoire du système

• null : périphérique virtuel dont l'écriture est toujours possible

• random : périphérique de génération de valeur aléatoire

• zero : périphérique virtuel dont la lecture est toujours possible

Parmi les fichiers basiques, j'ai dû ajouter ceux utilisés par les consoles (dénommés tty*). En plus des consoles, puisque la communication avec la carte s'est faite dans un premier temps par la liaison série, j'ai créé les fichiers correspondants aux consoles séries (dénommés ttyS*). Étant donné que la commande pour créer ces fichiers est quasi identique, j'ai décidé d'automatiser ce processus et de créer un script. Il comporte les lignes suivantes :

53/104


for i in {{0..4},{64..67}} ; do

if [ $i -lt 64 ] ; then

j=$i

else

j="S$(($i-64))"

fi

mknod -m 600 tty$j c 4 $i

done

J'utilise la liste des numéros mineurs au sein de la boucle « for ». Selon que le numéro mineur est inférieur (pour les terminaux) ou supérieur (pour les terminaux série) à 64, je modifie l'indice qui apparaît à la suite de la chaîne de caractères « tty ».

J'ai du aussi créer un dossier /dev/pts/ qui est monté au cours du démarrage. Il permet de créer des pseudo-terminaux. Les pseudo-terminaux étant des programmes qui simulent le fait que l'on se connecte à un terminal. Il était nécessaire de créer et de monter ce dossier au démarrage, en particulier pour pouvoir utiliser Telnet.

Enfin, j'ai créé quatres liens symboliques dans le dossier /dev/. Un programme, au cours de son exécution, doit pouvoir accéder à son entrée standard et à ses sorties (standard et erreur). Ainsi, j'ai d'abord commencé par créer /dev/fd qui est un lien symbolique vers /proc/self/fd, puis j'ai rajouté les liens vers les descripteurs de fichiers usuels : entrée standard (stdin), sortie standard (stdout), sortie d'erreur (stderr). J'ai rajouté ces opérations dans le script précédent en ajoutant :

ln -s /proc/self/fd /dev/fd

j=0

for i in {in,out,err} ; do

ln -s /dev/fd/$((j++)) /dev/std$i

done

3.3. ApplicationsUn certain nombre d'applications sont absolument nécessaires pour faire fonctionner un système GNU/Linux.

3.3.1. SysVinitLes systèmes de type GNU/Linux utilisent généralement le système de démarrage dit « SysVinit » (comprendre « System V init », en rapport avec l'apparition de ce système dans la version 5 de Unix distribuée par AT&T). Particulièrement, la procédure de démarrage nécessite la présence de l'application (init). D'autres outils sont aussi utilisés pour gérer l'extinction du système.

54/104

SysVinit - SysVinit

J'ai commencé par récupérer les sources de ce système. Puis, j'ai effectué la compilation croisée de toutes les applications composant le système en donnant le nom du compilateur (avec l'option CC) :

cd ~/xenomai/sysapps/sysvinit-2.86/src

make CC=arm-none-linux-gnueabi-gcc

Il est a noter que, dans la logique d'un système embarqué, je n'ai pas installé la documentation associée aux programmes. Pour cela, j'ai parcouru le fichier Makefile pour trouver les opérations correspondant à l'installation des pages du manuel et les commenter pour qu'elles ne soient pas exécutées. Ceci est possible car le fichier a vraisemblablement été rédigé à la main (il n'est pas issu d'une génération automatique). Il reste clair et compréhensible. Il est donc facile de trouver la cible « install » et de commenter les lignes :

install:

[...]

for i in $(MAN1); do \

$(INSTALL) -m 644 ../man/$$i $(ROOT)$(MANDIR)/man1/; \

done

[...]

Une fois ces lignes commentées, j'ai installé les programmes dans le futur système de fichier de la carte (grâce à l'option ROOT). J'ai donné en paramètres le numéro d'identifiant et le numéro du groupe de référence de mon identité sur le PC de développement. Cela évite de donner l'appartenance de ces applications au super utilisateur et de devoir changer d'identifiant pour éditer les applications au cours du développement.

make BIN_OWNER="$(id -un)" BIN_GROUP="$(id -gn)" \

>ROOT=~/xenomai/rootfs install

3.3.2. BusyBoxLes systèmes embarqués disposent généralement de peu de mémoire ; que ce soit de la mémoire vive (utile au cours du fonctionnement) ou de la mémoire Flash (pour la sauvegarde des données lorsque le système est hors tension). Pour donner un ordre d'idée, la carte que j'ai utilisé au cours de mon stage possède 64Mo de SRAM et 32Mo de Flash11.

Pour répondre à ces contraintes, il a été développé le logiciel BusyBox. Il regroupe dans un seul exécutable une grande majorité des commandes usuelles (cat, rm, ls...) qui composent la suite de logiciels appelée GNU Core Utilities.

Plutôt que de compiler le paquet coreutils, il a été choisit d'utiliser cette application.

11Un présentation détaillée la carte Viper est faite en page 80, en Annexe

55/104


C'est pour cela que j'ai récupéré les sources de ce logiciel avec git :

cd ~/xenomai/sysapps

git clone git://busybox.net/busybox.git

Il faut introduire le fait que BusyBox implémente une version simplifié de init. Malheureusement, dans une première version de mon système de fichier, je n'ai pas réussit à faire fonctionner cette implémentation de façon à ce que les scripts de démarrage soient exécutés. Des recherches sur Internet ont soulevées que ce problème était courant : l'application BusyBox semble n'utiliser que le fichier /etc/inittab et n'exécute pas les scripts qui peuvent apparaître dans ce fichier. Hors, suite au problème de connexion série12, j'avais besoin que le processus init soit capable de configurer les interfaces réseau et de démarrer un serveur Telnet, ce qu'il ne faisait pas.

J'ai donc décidé d'utiliser SysVinit pour le démarrage et BusyBox pour les autres applications. J'ai donc dû prêter attention à la configuration de compilation de BusyBox. J'ai commencé par appliquer la configuration par défaut. Ensuite, j'ai recensé les applications présentes dans SysVinit. Finalement, j'ai configuré BusyBox de façon à ce que les différents liens qui auraient pu entrer en conflit ne soient pas créés.

Pour appliquer la configuration par défaut, il faut donner la cible « defconfig » à make. Le reste de modifications se fait de manière interactive en utilisant le menu de configuration. Il faut donc donner la cible « menuconfig » à make :

cd ~/xenomai/sysapps/busybox

make CROSS_COMPILE=gnu-none-linux-gnueabi- ARCH=arm defconfig

make CROSS_COMPILE=gnu-none-linux-gnueabi- ARCH=arm menuconfig

Puis, j'ai compilé le logiciel en donnant la cible « install » de façon à ce que les objets compilés soient installés dans le squelette de l'arborescence de fichier système (grâce à l'option CONFIG_PREFIX) :

make CROSS_COMPILE=gnu-none-linux-gnueabi- ARCH=arm \

>CONFIG_PREFIX=~/xenomai/rootfs install

Une fois ces opérations terminés, j'ai pu vérifier qu'il n'a été créé qu'un seul exécutable (qui a été placé dans le dossier /bin/). Toutes les autres commandes sont en fait des liens symboliques vers cet exécutable :

12Voir la partie 2.2.1.

56/104

BusyBox - BusyBox

ls -l ~/xenomai/rootfs/bin

lrwxrwxrwx 1 root root 7 2009-05-27 addgroup -> busybox

lrwxrwxrwx 1 root root 7 2009-05-27 adduser -> busybox

lrwxrwxrwx 1 root root 7 2009-05-27 ash -> busybox

-rwxr-xr-x 1 root root 822620 2009-05-27 busybox

[...]

3.4. Démarrage

3.4.1. Le choix du système rcLa procédure de démarrage des systèmes GNU/Linux repose sur le programme init et une architecture de scripts de démarrage. Le programme init est le premier programme à être invoqué par le noyau. Ce programme va lire le fichier de démarrage /etc/inittab dans lequel apparaît différentes règles. Ces règles régissent le lancement d'applications ou l'exécution de scripts.

Il existe essentiellement deux systèmes de démarrage. Le premier, dit SysVinit, se retrouve dans les distributions Linux courantes (Ubuntu, Debian, Fedora, OpenSuse) avec plus ou moins de variations. Le deuxième est dit « système rc » est plutôt originaire des systèmes de type « BSD13 ».

J'ai tenté plusieurs fois de mettre en place un système de démarrage du premier type, parce que je pensais utiliser la distribution Ubuntu sur laquelle je travaillais. Je pensais copier système existant et le simplifier pour qu'il réponde à mes besoins. Malheureusement cette approche laisse souvent des erreurs dans les scripts. Ces erreurs sont ensuite difficile à retracer. De plus, la distribution Ubuntu a adopté un processus de démarrage différents de la norme SysVinit et pour lequel il est difficile d'avoir des informations sur Internet.

J'ai donc pensé créer entièrement le système pour la carte en simplement en copiant l'esprit du démarrage de SysVinit. Je me suis basé sur des distributions qui étaient plus respectueuses de la norme : OpenSuse ou Fedora, par exemple. Le problème de ces distributions est la complexité inhérente à l'accumulation des années de développement. J'avais donc du mal à faire ressortir les commandes nécessaires de celles plus optionnelles. Pour illustrer le degré de complexité des architectures de démarrage, il faut savoir que les distributions citées précédemment proposent généralement un logiciel pour manager les scripts de démarrage.

J'ai finalement opté pour le deuxième système de démarrage qui est plus compact et plus simple. Je me suis basé sur les informations données dans le manuel de présentation de la distribution Slackware. En effet, cette distribution Linux implémente un système de démarrage de type BSD. Il faut savoir que la distribution Slackware est en partie issue du projet LFS14. J'avais donc deux sources de documentation pour

13BSD : Berkeley Software Distribution. Distribution historique développée au sein de l'université de Berkeley depuis le système UNIX

14LFS : Linux From Scratch. Distribution minimale à développer soi-même.

57/104


créer les différents scripts.

3.4.2. Les sessions utilisateursBien que les systèmes embraqués ne soient pas des systèmes interactifs avec des utilisateurs, j'ai trouvé qu'il serait intéressant de configurer au moins un compte : le compte du super-utilisateur. De cette manière, à l'ouverture de session, un mot de passe est demandé et protège l'accès au système.

La mise en place des sessions utilisateurs repose sur la présence de trois fichiers : /etc/passwd, /etc/shadow, /etc/group. Je me suis basé sur les fichiers de la distribution Ubuntu que j'utilisais pour le développement. J'ai supprimé de nombreux comptes et groupes qui n'étaient pas utiles pour le système que je mettais en place.

Par exemple, sur les distributions Ubuntu, il est définit un groupe ayant la possibilité de créer des tâches périodiques (démarrées périodiquement par le démon « cron »). De cette façon, seuls les utilisateurs qui appartiennent à ce groupe peuvent ajouter des tâches périodiques dans le « pool » du démon. Toutefois, cette fonctionnalité n'étant pas présente et pas utile sur le système, j'ai enlevé le groupe correspondant.

L'initialisation du compte de super-utilisateur s'est fait en trois étapes :

1. j'ai créé un fichier vide pour contenir les mots de passe

2. j'ai donc démarré le système sans le système de comptes utilisateurs

3. j'ai ajouté le mot de passe de l'administrateur en utilisant la commande passwd

3.4.3. Le serveur inetdLe serveur inetd est couramment appelé le « super-serveur ». Il permet de remplacer l'écoute de tous les serveurs sur un système disposant de peu de ressources. En effet, il se place en écoute sur tout les ports de la machine. C'est seulement lorsqu'une requête arrive sur l'un des ports qu'il démarre le serveur correspondant pour répondre à la demande.

Dans la logique d'un système embarqué (donc, disposant de peu de ressources), j'ai décidé de mettre en place une telle architecture. Pour cela, j'ai utilisé l'implémentation du serveur inetd par BusyBox.

Le serveur inetd ne démarre en fait que les serveurs spécifiés dans un fichier de configuration appelé inetd.conf. Dans ce fichier, il est précisé :

• le type de service (ce qui va déclarer le numéro du port d'écoute par défaut)

• le type de données échangés

• le protocole de communication utilisé

• la manière dont doit se comporter le serveur à la réception d'une requête

• le chemin vers l'exécutable du serveur

• la ligne de paramètre à passer au serveur

J'ai cependant du adapter la ligne de ce fichier à cause de BusyBox. En regardant le fichier de configuration, on voit que l'on donne la chaîne de paramètre « telnetd -

58/104

Le serveur inetd - Le serveur inetd

i » au serveur Telnet, ce qui semble absurde :

# Telnet server:

telnet stream tcp nowait root /usr/sbin/telnetd telnetd -i

En fait, le fichier /usr/sbin/telnetd n'est qu'un lien vers BusyBox. Hors, BusyBox fonctionne de la façon suivante : il décide de mimer l'exécution du programme dont il reçoit le nom comme premier argument. Donc, selon la rédaction que j'ai faite du fichier, la ligne de commande suivante est exécutée (après remplacement du lien par l'exécutable pointé) et prend tout son sens :

busybox telnetd -i

3.4.4. Le serveur TelnetL'implémentation simplifiée du serveur Telnet par BusyBox nécessite :

• la présence du dossier /dev/pts/ (comme indiqué au point 3.2.2.)

• le montage des pseudo-terminaux dans ce dossier

• le fichier de périphérique /dev/ptmx

Ces nécessités n'apparaissent ni dans les pages du manuel de cette application ni dans dans celles de BusyBox. Au départ, je n'avais créé aucun de ces éléments et je n'arrivais donc pas à faire fonctionner le serveur Telnet. J'ai du chercher sur Internet quel était le problème. En fait, j'ai trouvé la solution indirectement, en cherchant une explication sur la notion de pseudo-terminal.

Lorsqu'un client Telnet envoi une requête à un serveur Telnet, la communication se fait par un réseau de type Ethernet. Le serveur possède un descripteur de fichier qui est monté dans le dossier /dev/pts/ de la machine sur laquelle il fonctionne. Lorsqu'une demande d'initialisation de session est faite (par le client), le serveur

59/104

Illustration 14 : Pseudo-terminal lors d'une connexion Telnet entre de deux machines


Telnet lance le programme responsable de cette tâche. Le programme qui initie les sessions utilisateurs (identification, puis lancement d'un interpréteur de commande) s'appelle getty. Lorsque cet outil démarre, il s'attache à une interface lui donnant l'impression qu'il est raccordé à un terminal série. En l'occurrence, il tente d'ouvrir le périphérique raccordé au fichier /dev/ptmx.

Comme le montre le schéma 14, la notion de pseudo-terminal apparaît dans le mécanisme qui relie le périphérique ouvert par le programme getty (/dev/ptmx) au descripteur de fichier détenu par le serveur Telnet (et monté dans le dossier /dev/pts/). Cette notion cache au programme getty que la communication ne se fait pas par le biais d'un terminal, mais par le réseau Ethernet.

Une fois que j'ai découvert cette nécessité, j'ai rajouté le dossier et le fichier dans le dossier /dev/. J'ai aussi rajouté, dans l'un des scripts de démarrage que j'ai écrit, une opération analogue à :

mount -t devpts devpts /dev/pts

À l'instar du montage du système de fichier /proc/, j'ai découvert que le paramètre indiquant le périphérique source (dans ce cas, le deuxième « devpts ») est ignoré par la commande mount. Toutefois, il est plus intéressant de donner le nom « devpts » plutôt que « none », s'il la commande se termine en erreur et qu'un message est affiché dans la console du système.

4. Portage de Xenomai

4.1. Manipulations sur le noyau Linux

4.1.1. Patch du noyauXenomai se présente sous la forme d'un patch de noyau Linux. Dans ce sens, j'ai exécuté le script de préparation sur le dossier contenant les sources du noyau Linux. Cette opération est détaillée dans un fichier (README.INSTALL) à la base de l'arbre des sources de Xenomai. J'ai adapté la commande de façon à ce que l'architecture du système cible soit la bonne :

~/xenomai/xenomai-2.4/scripts/prepare-kernel.sh \

>--linux=~/xenomai/linux-2.6.28.y \

>--arch=arm \

>--adeos=~/xenomai/xenomai-2.4/ksrc/arch/arm/patches/adeos-ipipe-2.6.28-arm-1.12.00.patch

Dans cette commande, on indique trois paramètres :

1. la location des sources du noyau Linux (option --linux)

2. l'architecture cible (option --arch)

60/104

Patch du noyau - Patch du noyau

3. la location du patch Adeos qui va être appliqué (option --adeos)

En guise de travail préparatoire, j'ai utilisé les commandes du logiciel (de suivi de version) git pour que les fichiers des sources du noyau soient tels qu'à la version 2.6.28. Sinon, les mises à jour successives et les patchs appliqués depuis cette version introduisent trop de différences dans les fichiers sources, et l'application du patch se termine en erreur.

On notera que le patch se présente comme un fichier texte qui répertorie les fichiers et les lignes de code à modifier. La symbolique de ces fichiers est relativement simple : la position du changement est encadré par une double répétition du symbole « @ ». Les lignes qui sont ajoutées sont précédées du symbole « + » tandis que celles qui sont enlevées sont précédées du symbole « - ». Les autres lignes de codes sont la pour fournir un contexte.

Une bonne pratique pour vérifier l'application du patch était de choisir un fichier modifié et de cibler une modification effectuée dans celui-ci. Il me suffisait ensuite de regarder dans le fichier, à la position indiquée, et de vérifier que les modifications étaient effectives.

4.1.2. Configuration du noyauAvant de lancer la compilation, on fait fonctionner le logiciel make pour qu'il soit créé un fichier .config. Ce fichier regroupe les options de compilation du noyau, selon la plateforme matérielle choisie, à la manière d'une liste de paramètres. Cette opération se fait avec la commande :

make viper_defconfig

Des fichiers par défaut, pour les architectures ARM® supportées par la communauté de développement du noyau Linux, se trouvent dans le dossier arch/arm/configs/ des sources. Le précédent responsable du centre eLiSe avait effectué le portage du noyau Linux sur la carte Viper. Il avait donc créé le fichier de configuration par défaut de la carte et l'avait soumis à la communauté.

J'ai du adapter la configuration du noyau (à partir de cette configuration par défaut) pour répondre parfaitement aux contraintes de Xenomai. Par exemple, j'ai du enlever les options qui permettent normalement d'avoir une diminution de la consommation d'énergie : l'adaptation de la fréquence du processeur en fonction de la charge et la mise hors tension des périphériques lorsqu'ils sont inactifs. Ces deux options sont susceptibles d'induire des variations dans la fréquence de rafraichissement des horloges du systèmes et donc, peuvent créer des latences non désirées. Ce point particulier est soulevé dans le fichier TROUBLESHOOTING, présent dans les sources de Xenomai.

4.1.3. Compilation du noyauLe processus de compilation du noyau est une tâche complexe, qui nécessite de compiler de nombreux systèmes (gestion de la mémoire, gestion du réseau...), eux-mêmes constitués de nombreux fichiers sources. Pour automatiser la compilation, une arborescence de fichiers Makefile a été développé au cours des années. Ce système

61/104


(couramment dénommé « kbuild ») propose aussi un certains nombre de cibles (par l'intermédiaire des « Makefile ») pour aider le développement du noyau. J'ai utilisé les fonctionnalités de ce système au cours du processus de portage de Xenomai.

Par exemple, pour garder les sources du noyau aussi propres que possible au cours des différentes compilations, j'ai systématiquement passé une option à make. Cette option indique que les résultats de compilation doivent mis dans un autre dossier que le dossier contenant les sources. Ainsi, j'évitais que des objets issus d'une précédente compilation ne viennent poser des problèmes lors de la compilation en cours.

La ligne de commande permettant de lancer la compilation du noyau et de ses modules ressemblait donc, en ajoutant cette option (« O ») :

make O=~/xenomai/build zImage modules

Une fois que la compilation avait été correctement menée, j'utilisais l'une des cibles du Makefile pour installer les modules dans le dossier contenant les objets compilés. Cette cible s'appelle « modules_install » et doit être utilisé avec l'argument « INSTALL_MOD_PATH ».

make INSTALL_MOD_PATH=~/xenomai/images/modules-2.6.28-xeno \

>modules_install

4.2. Installation sur le système de fichier

4.2.1. Mise en place du noyauUne fois que la compilation est terminée, il faudrait copier le noyau et les fichiers importants sur le système de fichier de la carte Viper. En fait, dans l'environnement de développement que j'ai utilisé (où les objets étaient conservés sur le PC hôte), le noyau était disponible par le serveur TFTP et le système de fichier par le serveur NFS. Je m'occupais de copier les éléments aux bons emplacements avant de lancer toute opération sur la carte.

Dans un premier temps, je commençais par archiver les données dans un dossier spécifique : le dossier images/. J'ai créé un script qui se chargeait de ces opérations. Le script se présentait de la manière suivante :

62/104

Mise en place du noyau - Mise en place du noyau

work_date = $(date +%d%m%y)

type = dbg

version = 2.6.28-xeno-$type-$work_date

cd $build

cp vmlinux ~/xenomai/images/vmlinux-$version

cp arch/arm/boot/zImage ~/xenomai/images/zImage-$version

cp System.map ~/xenomai/images/System.map-$version

cp .config ~/xenomai/images/$version.config

Ce script permettait la copie de :

• l'image du noyau (vmlinux)

• l'image compressé du noyau (zImage)

• la table des symboles (System.map)

• le fichier de configuration utilisé au cours de la compilation (.config)

Je conservais ces éléments et suffixais (ou préfixais) les noms de façon à ce qu'ils soient rapidement reconnaissables. Le préfixe contenait le type de configuration (« dbg » pour les versions d'évaluation, « patch » pour les versions modifiées, « trace » lorsque le traceur du pipeline d'interruption était activé) et la date à laquelle la compilation avait été menée.

Une fois que ces informations étaient archivées, je pouvait copier le dossier contenant les modules dans le système de fichier à l'aide de la commande :

cp -a ~/xenomai/images/modules-2.6.28-xeno/* ~/xenomai/rootfs

Il faut noter la présence de l'option « -a » dans la commande. Cette option permet de conserver les attributs des fichiers et les liens. Il faut être vigilant à cette option, particulièrement pour les liens. Si un objet est utilisé à plusieurs endroits, il n'y a généralement pas de duplication de l'objet ; mais la création de plusieurs liens pointant vers cet unique objet.

4.2.2. Compilation des librairiesLe lancement d'un script configure depuis le dossier contenant les sources est un processus typique de compilation d'applications. L'exécution de ce script aboutit à la création d'un fichier Makefile. C'est cette procédure qui est utilisée pour compiler les bibliothèques de Xenomai. Le script accepte un certain nombre de paramètres. Dans mon cas, la commande a pris la forme suivante :

63/104


cd ~/xenomai/build_xeno

~/xenomai/xenomai-2.4/configure \

>--host=arm-none-linux-gnueabi \

>--enable-arm-mach=pxa \

>--enable-arm-eabi

Il faut noter que le paramètre « --host » sert de préfixe à la recherche du compilateur croisé. Autrement dis, le script vérifie s'il existe des outils de compilation croisée sur la machine qui commencent par « arm-none-linux-gnueabi- ».

Selon la documentation disponible dans les sources de Xenomai, il n'y a pas besoin de donner l'option « --enable-arm-arch ». Seul l'architecture ARM® « integrator » oblige la présence de cette option. En effet, en explorant le script « configure », j'ai vérifié que la version de l'architecture est donnée par défaut.

Pour autoriser le déboguage des applications qui utilisent les librairies dynamiques, j'ai souvent rajouté le paramètre « --enable-debug ». Cette option conserve les symboles de déboguage lors de la compilation des librairies. Elle me permettait d'utiliser le débogueur au sein des librairies lorsque l'application avait été lié dynamiquement à ces librairies. Grâce à cette option, je pouvais faire du déboguage pas-à-pas même dans les fonctions des librairies.

Une fois que le Makefile a été généré, pour installer les librairies et d'autres utilitaires dans les sous-dossiers de /usr/xenomai/, il faut lancer la commande :

make DESTDIR=~/xenomai/rootfs install

J'ai remarqué qu'il ne fallait pas changer l'option « --prefix » lorsque je faisait fonctionner le script à l'étape précédente. En effet, l'option indique le dossier dans lequel les éléments seront installés dans le système de fichier. L'option « DESTDIR », dans la commande de make, indique le dossier de copie des éléments. Dans notre cas, c'est en modifiant ce paramètre que l'on pointe vers la racine du système de fichier de la carte Viper. Au final, les éléments sont installés dans $DESTDIR/usr/xenomai.

Pour une utilisation finale, sur un système embarqué, il aurait fallut que je veille à ne pas installer la documentation et les librairies statiques (dont l'extension est « .a »).

5. Évaluation de Xenomai

5.1. Visualisation de la consoleDans tout développement d'applications, et en particulier dans le domaine des systèmes embarqués, il est important d'avoir un retour d'informations sur ce qui se passe dans le système au travers de la console. J'ai donc du m'assurer des points suivant :

• Présence des fichiers de terminaux dans le système de fichier (/dev/ttyS*)

64/104

Visualisation de la console - Visualisation de la console

• Comportement de la console en fonction de la chaîne de paramètre passée au noyau par défaut (CONFIG_CMDLINE)

• Comportement de la console en fonction de la chaîne de paramètre du script de démarrage de RedBoot (qui réécrit la chaîne de caractère précédente)

Le visionnage des informations de la console est utile lors de la phase de démarrage. Il permet de suivre la découverte du matériel et le bon démarrage de certains modules. Dans le cas du portage de Xenomai, cela m'a permit de voir que le pipeline d'interruption était correctement activé. Ensuite, dans l'ordre, je pouvais voir que Xenomai était enregistré comme un domaine auprès d'Adeos, que le micro-noyau était chargé, puis que les différents « skins » étaient activés.

I-pipe 1.12-02: pipeline enabled.

[...]

I-pipe: Domain Xenomai registered.

Xenomai: hal/arm started.

Xenomai: real-time nucleus v2.4.8 (Lords Of Karma) loaded.

Xenomai: starting native API services.

Xenomai: starting POSIX services.

Xenomai: starting RTDM services.

Dans le cas où le noyau subit un crash, il fournit toujours des informations sur la console. Il donne une trace des dernières instructions qui ont été exécutées sur le processeur. Il donne aussi la valeur des tout les registres au moment de l'erreur fatale.

Par exemple, j'ai utilisé cette information pour me faire aider sur la mailing-list de Xenomai. Cette information a permis à l'un des mainteneurs de pointer une erreur sur la compilation des librairies de Xenomai. En effet, la trace des dernières instructions indiquait que les applications tentaient d'utiliser des instructions de calcul flottant alors que le processeur XScale de la carte Viper ne possède pas d'unité de calcul de ce type.

5.2. Critères d'évaluationsLes connaissance acquises par la lecture des ouvrages ou des articles sur Xenomai et les systèmes temps-réels m'ont permis de mettre en avant des facteurs à évaluer.

5.2.1. Les situations propices aux latencesPour créer des situations propices aux latences, il faut identifier les causes communes de latences dans un système. Les latences sont généralement dues aux:

• nombreuses interruptions matérielles et aux traitements associés

On peut créer ce genre de situation sur notre carte de test en la soumettant à une série de « ping » depuis le PC de développement.

65/104


• nombreuses interruptions logicielles (exceptions)

On peut créer une charge factice qui génère beaucoup d'accès mémoires (et donc génère des appels systèmes défaillants) en tapant une commande en tâche de fond, de la forme :

dd if=/dev/zero of=/dev/null

5.2.2. La mesure de la gigueOn peut évaluer la gigue du système par des solutions logicielles.

Elle repose sur des mesures faites par une tâche périodique. Si une tâche est déclarée périodique (de période donnée), alors deux mesures de temps devraient être faites avec un écart égal à cette période. Si la différence entre les deux valeurs mesurés par les horloges est différente de la période indiquée, il y a de la gigue dans le système.

C'est la méthode qui est employée dans certains programmes de la suite de test (détaillés dans la partie suivante).

5.3. La suite de testsParmi les éléments qui sont installés par le script « configure » de Xenomai, il figure sept scripts. Ils font fonctionner des applications de test de Xenomai. Ces scripts sont disponibles dans le dossier /usr/xenomai/share/xenomai/testsuite/. Les applications se trouvent dans le dossier /usr/xenomai/bin/. Le principal intérêt de lancer les applications depuis les scripts réside dans le lancement d'une commande introduisant de la charge sur le système, en plus de l'application. Éventuellement, on peut utiliser directement les binaires des applications depuis le dossier.

Voici un tableau résumant les différentes applications :

Application Statut Description

clocktest fonctionnel Test des horloges systèmes

cyclic fonctionnel Test des « timers »

irqbench non fonctionnel Environnement de mesure des latences matérielles pour x86

klatency fonctionnel Mesure des latences dans le mode noyau

latency fonctionnel Mesure des latences dans le mode utilisateur

switchbench fonctionnel Évaluation de la fréquence maximale de migration entre domaines

switchtest fonctionnel Évaluation de la fréquence maximale de migration entre domaines en fonction de la charge du système

Les informations sur le fonctionnement des applications (dans les pages de manuel) sont très succinctes. J'ai donc du rapidement parcourir le code source des applications

66/104

La suite de tests - La suite de tests

pour comprendre quel était l'intérêt de chacune.

5.3.1. ClocktestDans un système, il existe généralement plusieurs compteurs qui servent d'horloge.En particulier dans les systèmes à multi-processeurs, chaque CPU possède sa propre horloge. Chaque horloge qui est redéfinie doit rester synchronisée avec une horloge de référence. L'application « clocktest » permet de mesure l'écart une horloge et l'horloge de référence, ainsi que l'écart entre les horloges de différents CPUs.

Cette application repose sur un thread qui est lancé de façon cyclique. D'une fois sur l'autre, la période de mesure est aléatoire (comprise entre 1 et 1,1ms). Au cours d'une période, le « thread » relève différents couples de valeurs depuis l'horloge de référence et l'horloge testée. En comparant la différence des valeurs fournies par ces deux horloges, il se définit un instant de référence pour la période de mesure. Cet instant de référence est le moment où la phase (la différence) entre les deux horloges est minimale.

Le programme définit alors :

• le décalage (« offset ») comme la différence entre les deux valeurs obtenues (depuis l'horloge de référence et l'horloge testée) au moment où la phase est minimale

for (i = 2; i < 10; i++) {

delta = tod_val[i] - tod_val[i-1];

if (delta < min_delta) {

min_delta = delta;

idx = i;

}

}

[...]

per_cpu_data->offset = clock_val[idx] - tod_val[idx];

• le glissement (« drift ») comme le rapport du temps écoulé depuis le début du test mesuré selon l'horloge de référence et celui mesuré par l'horloge testée

per_cpu_data->drift =

(clock_val[idx] - per_cpu_data->first_clock) /

(double)(tod_val[idx] - per_cpu_data->first_tod) - 1;

• la vrille (« warp ») comme la différence entre les valeurs de deux horloges de CPU différents

Le programme permet de tester deux types de compteurs :

• CLOCK_REALTIME qui est un compteur donnant le temps depuis une référence

67/104


fixe. Cette référence est communément appelée Epoch.

• CLOCK_MONOTONIC qui est un compteur arbitraire que chaque application peut définir et configurer.

5.3.2. CyclicUne demande d'ordonnancement périodique de threads repose sur des compteurs (les « timers », en anglais). Le but de ce programme est de mesurer les latences liés à ces « timers ».

Pour cela, le programme crée un certain nombre de threads qui sont ordonnancés par Xenomai. Une fois que ces threads sont démarrés, la tâche « main » se contente d'afficher les statistiques des threads au minimum toutes les 10000µs (il y a un appel à la fonction usleep).

Chacun des threads, lorsqu'il est créé, utilise la même routine. Cette routine repose principalement sur une boucle. Pendant la période où le « main » est en sommeil, les threads ont le temps d'effectuer plusieurs boucles. Pendant ces boucles, ils font la différence entre une mesure du compteur et une mesure précédente du compteur. Une fois cette mesure collectée, ils mettent à jour leurs statistiques : la latence minimale, actuelle, moyenne et maximale.

L'application donne une ligne d'en-tête. Cet en-tête est la recopie exacte du contenu du fichier /proc/loadavg. Dans les pages du manuel, on trouve que les trois premiers chiffres sont la moyenne du nombre de processus dans la file des processus (prêt à être exécutées), moyennés sur 1, 5 et 15 minutes. Le quatrième champ représente le nombre d'entités (processus ou thread) dans l'état RUNNING ou UNINTERRUPTIBLE, rapporté sur le nombre d'entités présent dans le système. Le dernier champ est le PID du dernier processus démarré.

Le programme présente pour chacun des « threads » un certain nombre d'informations : le numéro du thread dans l'application (ainsi que son TID15, au niveau système), la priorité pour le système Xenomai, le compteur interne de la boucle active et la latence minimale, actuelle, moyenne et maximale.

5.3.3. KlatencyPour faire fonctionner cette application, il est généralement nécessaire de charger un module noyau spécifique (la nécessité d'insérer le module dépend du choix qui a été fait à la compilation). On insère le module en utilisant la commande modprobe :

modprobe xeno_klat

Pour vérifier le chargement du module dans le noyau, on peut utiliser la commande lsmod ou aller voir le contenu de /proc/modules. L'avantage du « fichier » indiqué en dernier est de cibler les dépendances des modules. En effet, les lignes de ce fichier donnent (entre autres informations) le nom du module (le premier champ), le nom du

15TID : Thread ID. Dans un programme non multi-threadé, le TID est identique au PID. Dans le cas inverse, chaque thread d'une même application possède un identifiant unique (TID) et partagent le PID de l'application.

68/104

Klatency - Klatency

module dont il dépend (le quatrième champ) et l'état (l'avant dernier champ).

Le principe de ce test est de mesurer les latences pour une tâche périodique de 100µs fonctionnant en mode noyau.

5.3.4. LatencyCe programme est écrit en utilisant l'API native Xenomai. Il a pour but de mesurer les latences d'exécution de façon logicielle.

Le programme « main » a pour seule fonction de créer et de démarrer deux tâches. La première s'occupe de la mesure des latences et ne fait pas d'appels à des fonctions de la libc standard. Ainsi, elle reste continuellement ordonnancée par Xenomai. La seconde qui s'occupe de l'affichage voit nécessairement ses contraintes de périodicité relâchées.

Puisque la tâche d'affichage n'a pas de périodicité, mais effectue ses activités en synchronisation avec la tâche de mesure grâce à un sémaphore, la tâche de mesure peut effectuer plusieurs mesures lors d'une période d'affichage. Donc, les lignes commençant par RTD (Real Time Data) affichent :

• la gigue minimale sur une période d'affichage

• la gigue maximale sur une période d'affichage

• la gigue minimale sur la durée du test

• la gigue maximale sur la durée du test

• la gigue moyenne sur la durée du test

Le programme insère parfois une ligne commençant par RTT (Real Time Task) donnant un rappel de l'activité en cours. Cette ligne comprend une indication du temps d'exécution de la tâche depuis le début du test.

La tâche de mesure est censé faire des mesures avec la périodicité indiqué, pendant une seconde. Lorsque la seconde est passée, le groupe de mesures constitue un échantillon qui est mis-à-jour dans un histogramme. Une fois que la mise à jour est faite, un signal sur le sémaphore prévient la tâche d'affichage. Le cycle recommence par la ré-initialisation des valeurs minimale et maximale de gigue et le nombre de dépassements.

Si la tâche met plus que la durée de la période pour compléter sa mesure, elle manque un (ou plusieurs) point de libération périodique. Le nombre de points de libérations manqués peut être comptabilisé (grâce à l'appel rt_task_wait_period). Lorsque ce cas se présente, le nombre de cycles manqués est comptabilisé et la tâche tente de se recaler avec le prochain point de libération.

5.4. Résultats

5.4.1. Commentaires critiqueJ'ai finalement décidé de ne pas utiliser tout les tests qui sont présents dans la suite.

Par exemple, je n'ai pas utilisé l'application « cyclic ». Le code de cette application est

69/104


issus d'une précédente application qui permettait le test des compteurs à haute résolution. Dans le code source de cette application, la distinction entre le traitement et la mesure n'est pas clair. Par exemple, la boucle qui fait la mesure des latences ne fait pas que cette opération : elle se charge aussi de faire plusieurs traitements sur les données. De plus, l'introduction d'une différence entre les périodes des threads pose question. Il serait plus logique d'avoir des threads de priorités différentes. Une situation de concurrence de l'accès au processeur devrait être pris en charge par l'ordonnanceur et ne pas être « évitée » dans l'implémentation du test.

5.4.2. Analyse des mesures de « clocktest »L'affichage des résultats se présente de la façon suivante :

root@viper:$ ./clocktest/run

*

*

* Type ^C to stop this application

*

*

== Tested clock: 0 (CLOCK_REALTIME)

CPU ToD offset [us] ToD drift [us/s] warps max delta [us]

--- -------------------- ---------------- ---------- --------------

0 -5.4 -0.001 0 0.0

Pour la plateforme Viper, on a seulement un processeur. Il n'y a donc pas de « warps » et donc pas d'écart maximum (« max delta »).

Dans le cas du test de l'horloge CLOCK_REALTIME, j'ai obtenu des « offset » oscillant entre -5µs et -6,5µs.

Dans le cas du test de l'horloge CLOCK_MONOTONIC, j'ai obtenu des « offset » oscillant entre 11646669,0µs et 11646670,5µs.

Pour les deux cas, l'écart entre les deux mesures est de 1,5µs. On a donc pas de différence perceptible, à une échelle macroscopique, de la mise à jour des compteurs et du décalage des valeurs qui doit être fait, au niveau noyau, pour ensuite les présenter à l'utilisateur.

5.4.3. Analyse des mesures de « latency »Si l'on regarde les deux premiers listings16, on peut dire que la latence minimale est fonction de la période de la tâche. La diminution de la période de la tâche fait, dans un premier temps, diminuer la latence maximale rencontrée. On notera avec le deuxième et le troisième listing que la diminution de la latence minimale atteint un palier lorsque la période de la tâche devient petite.

16Les résultats que je présente sont disponibles en page 82, en Annexe

70/104

Analyse des mesures de « latency » - Analyse des mesures de « latency »

Lorsqu'il n'y a pas de dépassements, on peut imaginer que la différence entre la durée de la période et la latence maximale constitue le temps restant pour l'exécution de la tâche, de la manière suivante :

En réalité, cette première impression est fausse : les dépassements de "release point" interviennent même lorsque l'on présente un période plus grande que le temps restant évalué (comme le montre le dernier listing).

La priorité de la tâche n'a pas d'influence sur les latences rencontrées. Dans le cas présent, cela s'explique par le fait que la tâche s'exécute sans aucune autre charge pour le système (la tâche d'affichage étant basculé dans le domaine Linux).

5.5. Le traceur du pipelinePour comprendre la raison de certains blocages du systèmes, j'ai compilé Xenomai de façon à ce que le traceur du pipeline d'interruption soit présent. Le traceur du pipeline permet de voir les appels de fonction au niveau noyau. Ainsi, on peut suivre l'alternance des domaines au dessus d'Adeos.

6. Développement sous Xenomai

6.1. Réalisations

6.1.1. Les compétences acquisesJ'ai choisis de développer des applications utilisant l'API Xenomai. J'ai fais ce choix pour créer et étudier des situations typiques des temps-réels sur le système Xenomai (ordonnancement concurrent, accès aux données de façon concurrentes...). Cela m'a aussi permis de me perfectionner dans la maîtrise du langage de programmation C et dans les outils de développement. De cette manière, mon projet d'étude ne s'est pas restreint simplement à la compréhension du code mais bien à une démarche de compréhension et de résolutions de problèmes liés au temps-réel.

Effectivement, tout en me basant sur les applications disponibles dans la suite de test de Xenomai et dans les exemples qui sont joints avec la documentation de l'API, j'ai du faire face à des problèmes spécifiques :

• problèmes de synchronisation des tâches dans une application

Les appels systèmes spécifiques à Xenomai permettent de gérer la création et

71/104

Illustration 15 : Latence maximale et temps d'exécution


la synchronisation des tâches.

• accès et protection des ressources communes

• identification des portions de code qui sont susceptibles de générer des problèmes de latence

• ...

Il a fallut que j'adopte une démarche de test, d'analyse et de résolution de ces problèmes.

6.1.2. Les outilsJe me suis familiarisé avec les outils de développement logiciels :

• vi

Un éditeur de texte performant pour le codage mais qui demande un temps d'apprentissage non négligeable. J'ai appris les commandes usuelles d'édition et aussi quelques méthodes de substitutions rapides de texte.

• make et les fichiers Makefile

L'outil make aide à la compilation des applications. J'ai appris la syntaxe d'écriture des fichiers.

• gdb

Le débogueur « gdb » est couramment utilisé dans le monde Libre. J'ai du apprendre la manière dont s'utilise ce logiciel (mise en place des points d'arrêts, exécution pas à pas...). En plus de l'utilisation « normale » de ce logiciel, j'ai du apprendre à l'utiliser pour faire du déboguage à distance.

• l'utilisation du traçage du pipeline d'interruption (I-pipe tracer)

Pour comprendre la succession d'exécution des différents domaines, j'ai choisit d'activer cette option dans le patch Xenomai. L'utilisation de ce système a nécessité que je cherche quelles étaient les informations présentées dans la trace et que je comprenne les mécanismes du système Adeos.

• strace

Permet de faire le traçage des appels systèmes d'une application.

• svn

Ce logiciel permet de faire du suivi de version. Je l'ai utilisé pour conserver une copie de mon travail sur le serveur du centre de service.

6.2. Développer des « bonnes pratiques »Au cours de l'exploration de l'API Xenomai, j'ai mis à jour des points sur lesquels il faut être vigilant pour les applications temps-réels.

6.2.1. Le management des tâchesLes appels systèmes qui font appels à la création des tâches ont leur pendant pour la

72/104

Le management des tâches - Le management des tâches

suppression des ressources. Il est important de bien faire appel à la paire d'appels :

rt_task_create()

rt_task_delete()

De cette façon, on fait appel explicitement à la destruction de la tâche.

La gestion de la mémoire est un point critique dans tout développement d'application. C'est un point particulièrement important dans les systèmes embarqués où il y a généralement peu de mémoire vive disponible. En effet, si il y des fuites mémoires importantes, alors il y a des zones qui sont consommées inutilement et qui ne sont pas accessibles. Ce point est encore renforcé dans les systèmes temps-réel : ces zones sont susceptibles de créer des fautes de pages et donc d'aggraver le risque de latences.

6.2.2. L'accès aux donnéesSi l'on fait des variables globales et qu'il y a la possibilité qu'elles soient accédées en même temps, il faut songer à utiliser des mécanismes spécifiques.

Lorsque l'une des tâches produit des données avec des contraintes temps-réel tandis que les autres tâches ne font que disposer de ces données, on peut envisager de mettre en place le mécanisme des « queues » de messages. On utilise les appels suivant :

RT_QUEUE queue;

rt_queue_create()

rt_queue_delete()

La tâche temps-réel peut mettre ses données dans la file les uns à la suite des autres (dans le cas d'une FIFO17) sans nécessairement se préoccuper de la fréquence à laquelle les autres tâches vident la file.

Lorsqu'une donnée sert d'échange entre plusieurs tâches, il est préférable de déclarer un « mutex ». Grâce à une structure de ce type, on protège la donnée en restreignant la portion de code où l'on fait des modifications. Si l'on veut conserver le temps-réel dans le système (ne pas bloquer les activités de trop de tâches, trop longtemps), cela sous-entend que les opérations apportés sur la donnée soient brèves. Il y a donc des « règles » qui surgissent :

• on n'utilise généralement pas des appels systèmes Linux dans ces portions protégés (pas d'affichage avec printf, par exemple) pour limiter les changements de domaines.

• on déporte les traitements sur la variable dans les portions non protégées (par contre, on protège une lecture ou une assignation de la valeur)

17FIFO : First In, First Out (Premier entré, premier sorti)

73/104


6.3. Le déboguage des applications

6.3.1. Déboguage symboliquePuisque les applications sont compilées pour l'architecture ARM®, il n'est pas possible de les faire fonctionner directement sur le PC de développement. De plus, gdb, le débogueur est un logiciel particulièrement volumineux (4MB environ, même après l'opération de « strip »). Il faut donc faire du déboguage à distance. On utilise un petit programme (gdbserver) sur la machine cible, qui exécute les commandes envoyées depuis le débogueur (gdb).sur le PC hôte.

Avant de mettre en place l'environnement, il faut compiler le serveur pour la carte Viper :

cd ~/xenomai/debug/buil_gdbserver

../../sysapps/gdb/configure --target=arm-none-linux-gnueabi\

>--prefix=~/xenomai/sysapps/gdbserver

make

make install

Le Makefile servant à la compilation de cette application est créé par un script configure. On passe quelques arguments à ce script pour indiquer le type de machine sur lequel fonctionnera le programme (l'option --target). On indique aussi l'endroit où seront installé les fichiers, une fois la compilation menée à terme (l'option --prefix).

Une fois que le serveur a été compilé, j'ai pu le copier dans le système de fichier de la carte Viper. On lance le serveur sur la machine en spécifiant le programme que l'on va faire fonctionner, l'adresse IP de la machine qui fait fonctionner le débogueur et le port sur lequel le serveur se place en écoute.

gdbserver 192.168.0.118:2345 application

Sur la machine hôte, il faut lancer le débogueur avec une copie de l'application, compilée avec les symboles de déboguage. Ensuite, dans l'invite de commande de gdb, on indique que la cible se trouve sur une autre machine (on précise donc l'adresse IP de la machine sur laquelle fonctionne le serveur et le port d'écoute).

arm-none-linux-gnueabi-gdb application

(gdb)remote target 192.168.0.117:2345

Dans le livre de Karim Yaghmour, il est indiqué que le débogueur doit être compilé en indiquant le type d'application qui sera débogué. Il faudrait donc utiliser les outils de compilation croisée. En fait, je n'ai pas eu besoin de mener cette étape parce que l'environnement de compilation croisée que j'ai mis en place comportait déjà un débogueur pour les applications fonctionnant sur ARM®.

74/104

Le traçage des appels systèmes - Le traçage des appels systèmes

6.3.2. Le traçage des appels systèmesOn peut lister les appels systèmes qu'effectue une application au cours de son fonctionnement en utilisant l'outil strace. Cet outil, utilise à son tour l'appel ptrace définit par le noyau Linux.

Pour commencer, il a fallu que je compile cette application pour qu'elle puisse fonctionner sur la carte Viper. Cette opération est facilement réalisée car un script configure est fournis avec les sources de cette application.

cd ~/xenomai/debug/build_strace/

CFLAGS=~/xenomai/linux-2.6.28.y/include\

>~/xenomai/sysapps/strace-4.5.18/configure\

>--prefix=~/xenomai/debug/strace\

>--host=arm-none-linux-gnueabi

[...]

make

make install

Il faut noter plusieurs choses dans cette commande :

• on donne le chemin vers les fichiers d'en-tête du noyau (compilé pour la Viper) au pré-compilateur. En donnant l'option CFLAGS avant de faire fonctionner le script configure, la valeur de la variable est écrite dans le fichier Makefile.

• on précise le dossier où sera installé l'exécutable et les document relatifs (~/xenomai/debug/build_strace/) grâce à l'option prefix. On notera que le dossier indiqué est différent de celui qui contient les sources (~/xenomai/sysapps/strace-4.5.18/) et du dossier où se déroule la compilation (~/xenomai/debug/strace/). Ainsi, on conserve une distinction nette entre les fichiers de chaque étape.

• on précise le type de la machine cible avec l'option host. En plus de préciser le type de machine, le script utilise cette chaîne de caractères comme préfixe des outils de compilation croisée.

J'ai rencontré un problème lors des premières tentatives de compilation : une erreur était indiqué dans un fichier définissant les appels systèmes. Ce problème est spécifique au architectures ARM® qui utilisent l'interface ABI. On trouve rapidement sur Internet un patch qui permet de lever ce problème, par exemple sur le « Trac » du projet OpenWrt. Il suffit de l'appliquer sur les sources avant de les compiler, à l'aide de la commande patch :

cd ~/xenomai/sysapps/strace-4.5.18/

patch -p1 <~/xenomai/archives/strace_patch

La commande patch est simple d'utilisation : il suffit de spécifier le fichier de patch sur l'entrée standard de la commande et la valeur de l'option -p. Cette dernière option

75/104


permet de supprimer la première partie des chemins vers les fichiers à modifier, indiqués dans le fichier de patch et qui sont de la forme :

--- a/linux/arm/syscallent.h

+++ b/linux/arm/syscallent.h

Une fois que le programme est placé dans le système de fichier de la carte Viper, son utilisation permet de générer des fichiers textes donnant la liste des appels systèmes passés par l'application. J'ai parfois dû aller voir l'implémentation des appels dans les sources de Xenomai pour trouver où débute et où commence véritablement l'appel système.

Il est possible de suivre les appels systèmes des différentes « tâches » d'une application en faisant :

strace -ff nom_de_application

Le logiciel strace crée alors un fichier par fil d'exécution.

Lorsque les latences d'exécution étaient longues et que j'ai supposé que cela était dû à un appel système, j'utiliseais strace avec l'option :

strace -c nom_de_application

Dans cette configuration, la sortie présentais un résumé des appels systèmes, le nombre de fois où ils avaient été exécutés et le temps qu'ils avaient mis pour s'exécuter. En conjonction avec un précédent passage de l'application, on peut déterminer où se situent les portions critiques d'une application.

76/104

ConclusionL'étude du portage de Xenomai sur la carte Viper a mis en avant la faisabilité de cette opération. Elle est censé illustrer les performances de la carte.

Il pourrait être envisagé d'utiliser cet environnement dans le cadre du développement d'une application de robotique, par exemple. On pourrait aussi étudier la faisabilité du portage de l'environnement Orocos sur la carte.

D'un point de vue personnel, j'ai appris de nombreuses choses sur les systèmes Linux, sur les spécificités des systèmes embarqués, sur les systèmes temps-réels. D'un point de vue plus pratique, j'ai appris à utiliser un nombre important d'applications servant au développement d'applications, et pas seulement pour l'intégration de système.

J'espère pouvoir mettre en avant cette expérience lors de ma recherche d'emploi et ainsi, continuer à travailler dans ce domaine.

77/104


OuvertureSuite à des problèmes essentiellement administratifs, je n'ai pas pu faire mon stage dans le laboratoire de robotique mobile de l'université du Minnesota, aux États-Unis.

J'ai commencé le stage concernant le portage de Xenomai sur la carte Viper au mois d'avril. À la date du 02/09/09, il me reste encore 3 semaines avant la fin de mon stage. J'espère donc avoir le temps d'approfondir encore quelques points. En particulier, j'espère pouvoir utiliser complètement le traceur du pipeline d'interruption et ainsi mettre à jour les causes de latences. J'espère aussi pouvoir explorer le code de l'application « klatency » et donner quelques résultats sur l'impact du contexte d'exécution sur les latences.

78/104

Annexes


A. Caractéristiques de la carte Viper

A.1. ProcesseurLa carte Viper est équipée d'un processeur Intel XScale™ PXA255 cadencé à 400MHz. Ce processeur est basé sur l'architecture ARM© v5TE. Il est donc de type RISC. Les deux lettre qui suivent le numéro de version spécifient que ce processeur est capable d'utiliser un jeu d'instruction spécifique de taille réduite (dénommé « Thumb », d'où le « T ») et qu'il est adossé à un DSP pour effectuer les tâches multimédia (le « E » provient de la désignation « Enhanced »).

Il possède deux caches (un pour les données et un autre pour les instructions) de 32ko chacun. En plus de ces deux caches, il possède un cache plus petit de 2ko pour les données pour les données sous forme de flux.

Le processeur reçoit une mesure du temps depuis trois circuits.

• L'horloge principale du système est basé sur un oscillateur à 3,6864 MHz. L'oscillateur peut être contrôlé par un cristal externe de même fréquence. C'est la configuration qui a été retenue sur la carte Viper. Au final, c'est cette horloge qui est utilisée par le noyau Linux pour générer l'interruption 0 et maintenir la valeur du PIT.

80/104

Illustration 16 : Vue d'ensemble de la carte Arcom Viper, mettant en évidence la connectique

Annexes - Caractéristiques de la carte Viper

• Un circuit spécifique appelé « Real Time Clock » délivre un décompte à la fréquence de 32,768 kHz. Il permet de conserver la trace de la date et de l'heure même lorsque le système est mis hors tension, grâce à une pile de sauvegarde.

• Un troisième circuit délivre plusieurs horloges à des fréquences entre 1,8432 MHz et 25 MHz.

A.2. MémoireSur la carte Viper, on trouve quatre types de mémoire :

4. 32Mo d'Intel StrataFLASH pour contenir des données (système de fichier, par exemple)

5. 1Mo de Flash de type EPROM pour contenir le chargeur d'amorçage (RedBoot). C'est cette mémoire qui est accédée par le processeur au moment de sa mise sous tension.

6. 256Ko de SRAM

7. 64Mo de SDRAM pour la mémoire principale du système. On a accès à 16Mo de mots de 32bits. En fait, il y a deux puces mémoires contenant chacune quatre banques de mémoires de 4Mo, de mots de 16bits.

La mémoire principale est accédée par le bus principal, cadencé à 100MHz.

A.3. Connecteurs sérieLa carte comporte cinq connecteurs série de type UART. Les quatre premiers d'entre eux sont compatibles RS232. Dans la configuration série, il faut distinguer le contrôleur série, qui est intégré dans le processeur, du transmetteur, qui est une puce externe proche du connecteur.

A.4. Fonctionnalités réseauOn trouve un contrôleur Ethernet 10/100BaseTX sur la carte avec le connecteur associé. Les informations de configuration et l'adresse MAC de cette interface sont stockées dans une mémoire de type EEPROM spécifique. La présence de cette mémoire permet notamment au chargeur d'amorçage de faire une configuration basique de la liaison Ethernet et donc, d'initialiser une communication par le réseau de type Ethernet.

Un connecteur de type RJ45 permet de connecter les interfaces.

81/104


B. Résultats du programme « latency »

B.1. Mesures relevées (n°1)

root@viper:$ ./latency/run -p 1000 -T 20 -P 80

[...]

== Sampling period: 1000 us

== Test mode: periodic user-mode task

== All results in microseconds

warming up...

RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 80)

RTH|-lat min|-lat avg|-lat max|-overrun|-lat best|-lat worst

RTD| 295.952| 333.930| 348.578| 0| 295.952| 348.578

RTD| 50.184| 334.472| 426.703| 0| 50.184| - 426.703

RTD| 119.086| 333.387| 355.902| 0| 50.184| 426.703

RTD| 118.815| 333.658| 348.578| 0| 50.184| 426.703

RTD| 118.815| 337.185| 363.226| 0| 50.184| 426.703

RTD| 119.357| 345.865| 429.687| 0| 50.184| 429.687

RTD| 118.815| 346.950| 448.404| 0| 50.184| 448.404

RTD| 119.086| 341.796| 449.761| 0| 50.184| 449.761

RTD| 119.357| 333.658| 356.445| 0| 50.184| 449.761

RTD| 119.086| 333.658| 356.445| 0| 50.184| 449.761

RTD| 118.815| 333.387| 357.259| 0| 50.184| 449.761

RTD| 119.086| 334.472| 427.246| 0| 50.184| 449.761

RTD| 119.086| 333.658| 355.902| 0| 50.184| 449.761

RTD| 119.086| 336.371| 354.546| 0| 50.184| 449.761

RTD| 119.357| 343.967| 429.687| 0| 50.184| 449.761

RTD| 119.086| 346.950| 435.926| 0| 50.184| 449.761

RTD| 119.086| 343.967| 434.841| 0| 50.184| 449.761

RTD| 118.815| 334.201| 355.360| 0| 50.184| 449.761

RTD| 119.086| 333.658| 357.530| 0| 50.184| 449.761

---|--------|--------|--------|--------|--------------------

RTS| 50.184| 337.456| 449.761| 0| 00:00:20/00:00:20

82/104

Annexes - Résultats du programme « latency »



[...]




warming up...



RTD| 31.195| 222.710| 429.144| 0| 31.195| 429.144

RTD| 41.232| 341.254| 429.416| 0| 31.195| 429.416

RTD| 46.657| 340.440| 428.873| 0| 31.195| 429.416

RTD| 44.759| 339.626| 437.825| 0| 31.195| 437.825

RTD| 45.030| 339.626| 438.368| 0| 31.195| 438.368

RTD| 46.929| 339.626| 435.655| 0| 31.195| 438.368

RTD| 46.386| 339.626| 435.384| 0| 31.195| 438.368

RTD| 45.844| 339.626| 434.299| 0| 31.195| 438.368

RTD| 97.384| 339.626| 430.230| 0| 31.195| 438.368

RTD| 40.961| 336.914| 425.075| 0| 31.195| 438.368

RTD| 45.844| 339.355| 438.368| 0| 31.195| 438.368

RTD| 99.012| 341.796| 429.416| 0| 31.195| 438.368

RTD| 99.012| 340.169| 429.144| 0| 31.195| 438.368

RTD| 44.759| 339.626| 429.144| 0| 31.195| 438.368

RTD| 46.929| 339.626| 429.416| 0| 31.195| 438.368

RTD| 45.572| 339.898| 433.213| 0| 31.195| 438.368

RTD| 45.301| 339.355| 429.416| 0| 31.195| 438.368

RTD| 46.657| 339.355| 428.873| 0| 31.195| 438.368

RTD| 46.657| 339.084| 428.331| 0| 31.195| 438.368

---|--------|--------|--------|--------|--------------------

RTS| 31.195| 333.387| 438.368| 0| 00:00:20/00:00:20

83/104




[...]




warming up...



RTD| 22.243| 32.280| 85.177| 0| 22.243| 85.177

RTD| 67.816| 340.711| 429.687| 0| 22.243| 429.687

RTD| 45.844| 340.983| 448.133| 0| 22.243| 448.133

RTD| 46.929| 340.983| 437.282| 0| 22.243| 448.133

RTD| 40.690| 340.983| 429.416| 0| 22.243| 448.133

RTD| 40.690| 340.983| 439.181| 0| 22.243| 448.133

RTD| 40.690| 340.983| 438.096| 0| 22.243| 448.133

RTD| 46.115| 340.983| 437.825| 0| 22.243| 448.133

RTD| 40.690| 340.983| 438.910| 0| 22.243| 448.133

RTD| 41.232| 340.983| 457.356| 0| 22.243| 457.356

RTD| 40.690| 340.983| 434.841| 0| 22.243| 457.356

RTD| 41.232| 340.711| 439.453| 0| 22.243| 457.356

RTD| 40.961| 340.711| 429.687| 0| 22.243| 457.356

RTD| 42.317| 340.983| 429.416| 0| 22.243| 457.356

RTD| 41.503| 340.711| 430.230| 0| 22.243| 457.356

RTD| 38.248| 340.983| 435.655| 0| 22.243| 457.356

RTD| 45.844| 340.983| 437.011| 0| 22.243| 457.356

RTD| 46.115| 340.711| 429.687| 0| 22.243| 457.356

RTD| 45.572| 340.983| 433.485| 0| 22.243| 457.356

---|--------|--------|--------|--------|--------------------

RTS| 22.243| 324.435| 457.356| 0| 00:00:20/00:00:20

84/104

Annexes - Résultats du programme « latency »



[...]




warming up...



RTD| 18.174| 31.738| 74.055| 0| 18.174| 74.055

RTD| 55.881| 389.268| 669.487| 4| 18.174| 669.487

RTD| 41.232| 388.726| 666.775| 6| 18.174| 669.487

RTD| 34.993| 380.859| 669.216| 7| 18.174| 669.487

RTD| 36.892| 383.300| 669.216| 8| 18.174| 669.487

RTD| 45.572| 386.284| 657.823| 8| 18.174| 669.487

RTD| 42.317| 387.369| 667.317| 9| 18.174| 669.487

RTD| 40.418| 385.742| 669.216| 13| 18.174| 669.487

RTD| 38.519| 379.774| 662.706| 14| 18.174| 669.487

RTD| 40.147| 386.284| 656.738| 14| 18.174| 669.487

RTD| 40.147| 388.726| 666.503| 15| 18.174| 669.487

RTD| 34.450| 391.438| 647.786| 15| 18.174| 669.487

RTD| 47.471| 381.944| 647.243| 15| 18.174| 669.487

RTD| 40.690| 381.944| 657.280| 15| 18.174| 669.487

RTD| 43.131| 388.454| 657.009| 15| 18.174| 669.487

RTD| 40.147| 391.981| 660.807| 16| 18.174| 669.487

RTD| 44.759| 389.811| 666.775| 18| 18.174| 669.487

RTD| 45.030| 379.503| 657.280| 18| 18.174| 669.487

RTD| 40.418| 384.657| 657.009| 18| 18.174| 669.487

---|--------|--------|--------|--------|--------------------

RTS| 18.174| 367.024| 669.487| 18| 00:00:20/00:00:20

85/104


C. Logiciel de suivi de version : gitLe logiciel git est un logiciel de suivi de version. Il permet de conserver l'histoire d'un projet. Il met en avant sa simplicité et sa rapidité. Il a été initialement développé par Linus Torvalds pour le développement du noyau Linux.

C.1. ConceptsL'historique est contenu dans des fichiers référencés par des « object name ». Un nom est le haché (en utilisant la méthode SHA1) du contenu de ce fichier. Il est donc représenté par une chaîne de 40 caractères du type :

6ff87c4664981e4397625791c8ea3bbb5f2279a3.

Avec cette méthode, il est virtuellement impossible d'avoir deux objets différents avec le même nom.

C.1.1. Les objetsLe fonctionnement de git repose sur 4 types d'objets : « blob », « tree », « commit » et « tag ».

C.1.1.1. BlobUn « blob » retient un contenu binaire quelconque. C'est généralement le contenu d'un fichier. On notera que le « blob » ne retient pas le nom du fichier. C'est en accord avec le principe que git retient le contenu, pas le fichier ! Deux éléments qui auraient le même contenu dans une arborescence d'un projet auraient le même « blob ».

C.1.1.2. TreeUn « tree » retient un ensemble de pointeurs vers des « blobs » ou des « trees ». Il représente souvent un dossier ou un sous-dossier.

C.1.1.3. CommitUn « commit » lie l'état d'un arbre à la façon dont on est arrivé à cet état. Il retient le nom de différents « commits » précédemment effectués qui définissent cet état précédent. Ce sont les parents du de ce « cliché ».

C.1.1.4. TagUn « tag » contient le nom d'un objet et son type ainsi que d'autres informations. Il retient surtout un message.

C.1.2. Le dossier git et le dossier de travailLe dossier Git est un dossier qui contient toute l'histoire du projet sous la forme de

86/104

Annexes - Logiciel de suivi de version : git

méta-données. Il est généralement placé à la racine du projet et porte le nom « .git ». Il existe un seul dossier git par projet, à la différence de Subversion qui place un dossier à sous-dossier de l'arborescence du projet.

Le dossier de travail est celui qui contient les fichiers dans l'état actuel. Ces fichiers sont généralement modifiés ou déplacés par git lorsque l'on passe d'une branche de développement à un autre.

C.1.3. BranchesLes instantanées (les « commits ») ne sont pas nécessairement alignés les uns à la suite des autres, du plus ancien au plus récent. Le travail peut être mené de façon parallèle selon des développement parallèles (plusieurs développeurs qui travaillent ensemble sur un même projet, par exemple). On parle de branches de développement ; celles-ci pouvant diverger ou converger.

Le suivi d'une branche se fait en conservant la « tête » de cette ligne de projet (qui correspond au dernier « commit » de la branche). Ce point particulier est repéré par le mot clé « HEAD ».

C.2. Utilisation

C.2.1. Suivi d'un projet existantOn peut cloner un dépôt en utilisant la commande :

git clone git://git.kernel.org/pub/scm/stable/linux-2.6.28.y.git

A moins de spécifier un nom pour le dossier que l'on veut se créer dans son environnement de travail, il porte le nom du dossier d'origine. Si l'on se déplace dans ce dossier, on observe une copie des fichiers. Cette arborescence constitue le dossier de travail.

C.2.2. Travail collaboratifLorsque l'on veut récupérer les dernières modifications d'un dépôt distant que l'on a copié, on utilise la commande :

git pull

En effet, au moment du clonage, le logiciel git retient la location du dépôt.

C.2.3. Initialisation d'un suivi de projetOn commence par se déplacer dans le dossier du projet. On y créé un dossier .git/ qui est vide et qui assurera la gestion du suivi de version. Ce dossier est créé au cours de la commande :

87/104


git init

Il faut ensuite ajouter les fichiers que l'on souhaite suivre à l'index. Pour cela, on spécifie les noms des fichiers avec la commande « add ». Dans le cas d'un premier ajout, on peut vouloir ajouter tout les fichiers de façon récursive. On tape alors la commande :

git add .

Avant de faire le premier « commit », on peut avoir un résumé des fichiers qui ont été ajoutés ou modifiés depuis le dernier « commit » en faisant :

git status

Enfin, on peut demander à enregistrer les différences dans l'index en faisant :

git commit

L'enregistrement de ces modifications se fait essentiellement de façon interactive. On peut indiquer un message qui indique un résumé des changements.

C.2.4. Branches et convergencesOn a dit qu'un projet peut contenir plusieurs branches de développement. Pour créer une nouvelle branche de développement, on tape la commande :

git branch new_branch

Pour effectivement voir les branches qui existent dans le projet, on fait :

git branch

On remarquera que la branche sur laquelle on se situe actuellement est celle qui est précédée d'une astérisque. Si l'on veut se positionner sur la nouvelle branche de développement :

git checkout new_branch

Une fois que l'on est sur cette branche, on peut faire les modifications voulues sans impacter sur les autres branches. On peut créer des fichiers puis demander à les ajouter au suivi de la branche. Bien sûr, pour que les modifications soient prises en compte, il faudra faire un « commit ».

Si l'on veut commencer une nouvelle branche qui sera basé à partir d'un autre instantané que le moment présent, il faut l'indiquer lors de la création de la nouvelle branche. On peut donner le haché du « commit » sur lequel on veut se baser :

88/104

Annexes - Logiciel de suivi de version : git

git checkout -b new_branch hash

Si l'on veut faire converger la branche sur laquelle on se trouve avec une autre branche de développement, on utilisera la commande :

git merge other_branch

Lorsque les changements ne créent pas de conflits, il n'y a rien de plus à faire. Sinon, il faut éditer les fichiers avant de faire le « commit ». On peut au préalables voir les différences au sein des fichiers en faisant :

git diff

C.3. Autres commandesLorsque l'on veut observer les différents « commits » qui ont été effectués, il faut utiliser la commande :

git log

On peut visualiser une version graphique (à l'aide de caractères ASCII18) de la liste en ajoutant l'option « --graph ».

Cette commande liste les « commits » dans l'ordre du plus récent au plus ancien. Lorsque l'on se base sur une branche qui continu d'être développé mais où l'on veut travailler à un instant donné plus ancien, elle permet de vérifier que l'on a bien déplacé le « pointeur de tête » au bon endroit.

Le logiciel git conserve une trace seulement des documents qu'il répertorie. Par exemple, si l'on mène une compilation dans un dossier qui est suivi par git, les objets de compilation (qui portent l'extension « .o ») ne sont pas suivis. Il y a la possibilité de supprimer les fichiers qui ne sont pas suivis en utilisant le commande :

git clean -df

L'option « -d » permet de supprimer les dossiers qui ne sont pas suivis. Le comportement normal de la commande étant de ne supprimer que les fichiers.

Si l'on veut supprimer une branche, on fait :

git branch -d branch_to_be_deleted

L'option « -d » permet de s'assurer que les changements effectués sur l'autre branche ont été appliqués sur la branche actuelle. Pour forcer le comportement et ne pas tenir compte des changements appliqués sur la branche parallèle, on remplace le « -d » par « -D ».

18ASCII : American Standard Code for Information Interchange

89/104


Lorsque l'on se rend compte que l'on a fait une erreur et que l'on veut revenir à l'état du « commit » précédent, il faut utiliser la commande suivante :

git reset --hard HEAD

Ceci permet de remettre à la fois le dossier de travail et l'index dans l'état précédent.

90/104

Annexes - Logiciel de suivi de version : svn

D. Logiciel de suivi de version : svnLe logiciel Subversion (abrégé « svn » en rapport avec le nom de la commande à utiliser) est un logiciel de

suivi de version développé à partir de 2000 par CollabNet Inc. Il est utilisé par de nombreux projets Open Source tels que : Apache, KDE, GCC, Python...

D.1. Concepts

D.1.1. Les dossiers d'administrationChaque dossier de l'arborescence du projet contient un dossier spécifique. Ce dossier spécifique port le nom « .svn/ ». Il est appelé « dossier d'administration ». Il contient des fichiers qui permettent à Subversion de savoir quels sont les fichiers qui ont subis des changement, qui ne sont plus à jour avec le travail des autres, etc...

D.1.2. Les révisionsLorsque l'on effectue des modifications sur plusieurs fichiers, à chaque fois que l'on propose une nouvelle version du travail, toutes ces opérations sont comprises comme une seule opération (dite « opération atomique »).

À chaque fois que le dépôt accepte une nouvelle version du projet, il est créé une nouvelle « révision ». La révision correspond à l'état de l'arbre à un moment donné. Les révisions se voient assigner un entier naturel qui augmente à chaque nouvelle version. La première révision (notée 0) correspond à la création du dossier qui sert de racine au projet et qui est encore vide de tout fichier.

Le numéro de version est global à tout les fichiers. À chaque nouvelle révision, le numéro de version de chaque fichier est modifié, même pour les fichiers qui n'ont pas subis de changement. Parler de l'état de révision d'un fichier, c'est parler de l'état dans lequel il se trouvait quand le projet en était à la version donnée.

D.1.3. L'architecture du dossier projetIl existe des « bonnes pratiques » de suivi de projet. Par exemple, il est recommandé de constituer trois dossiers à la base du dossier du projet. Ces dossiers sont :

• trunk/ qui est le dossier contenant la version principale de développement du projet.

• branches/ qui peut contenir plusieurs autres dossiers. Les sous-dossiers sont des copies de la branche principale. Ils servent aux développements en parallèle ou en amont du projet. Ils portent généralement un nom différent qui explicite l'orientation du développement.

• tags/ qui contient des « instantanés » du projet. Ils peuvent être ensuite supprimés ou archivés, mais qui ne sont pas appelés à être modifiés.

91/104


Bien que le point présenté dans la partie précédente ne soit pas une nécessité pour faire fonctionner le programme Subversion, il est recommandé d'utiliser ce type de squelette.

De plus, Subversion ne retient pas fondamentalement le concept de « branches ». Il effectue des copies de dossier à dossier. Au cours de ces copies, il prend le soin de ne copier que les documents nécessaires et de conserver un historique des changements effectués. Ce mécanisme est masqué à l'utilisateur qui, lui, voit une copie complète des arbres. C'est l'utilisateur qui ajoute à ces branches le concept de « branche de développement ».

D.2. Utilisation

D.2.1. Suivi d'un projet existantOn peut cloner un projet situé sur un dépôt distant en utilisant la commande :

svn checkout http://svn.example.com:3894/repository/project

La commande de Subversion permet de récupérer le contenu du dossier « project » du dépôt « repository » qui se situe sur la machine « svn ». Les documents sont récupérés via le protocole HTTP. A moins de spécifier un nom pour le dossier que l'on veut se créer, il porte le nom du dossier d'origine. Si l'on se déplace dans le dossier créé, on observe une copie conforme des fichiers.

Le serveur Subversion distant peut utiliser un protocole spécifique au logiciel de suivi de version pour la transmission des données. On a alors des commandes qui indiquent ce protocole particulier : « svn ». Les commandes sont du type :

svn checkout svn://svn.example.com:3894/repository

Il faut faire attention à la façon dont on rentre l'URL. En particulier lorsque l'on entre des noms comportant des espaces. Dans ce dernier cas, il faut penser à indiquer l'URL entre guillemets.

D.2.2. Travail collaboratifLorsque l'on veut récupérer les dernières modifications du dépôt distant que l'on a copié, on utilise la commande :

svn update

Il n'y a pas besoin de redonner l'URL du dépôt car le logiciel Subversion retient la location du dépôt au moment du clonage .

D.2.3. Initialisation d'un suivi de projetTout commence par la création d'un dépôt. Tout les documents qui seront présents

92/104


dans ce dépôt bénéficieront du suivi de projet.

svnadmin create path_to_repos

Une fois le dépôt créé, on peut commencer à le peupler. Pour cela, on peu copier un dossier contenant le travail qui a déjà été commencé. Le fait de copier les données pour la première fois amène Subversion à faire un premier « commit ». Un « commit » est le fait de proposer des modifications ; cela fait aussi avancer la révision du projet. On peut joindre le texte décrivant brièvement le « commit » dans la commande avec l'option « -m ».

svn import directory file:///path_to_repos/project_dir \

>-m "Initial import"

On notera que dans cette commande, l'URL spécifie un fichier (avec le préfixe « file: ») contenu sur la machine, en local. Dans toute URL, le premier champ après la double barre oblique indique la machine qui contient le fichier. Dans le cas d'un fichier en local, on peut omettre de donner le nom de la machine, mais il faut alors continuer à indiquer le chemin d'accès au fichier (qui lui-même commence avec une barre oblique), d'où la présence, au final, de trois barres à la suite. C'est aussi à ce moment là qu'il est conseillé de créer un squelette de type TTB (« Trunk, Tags, Branches »).

On peut avoir un résumé des fichiers qui ont été ajoutés, supprimés ou modifiés depuis le dernier « commit » en faisant :

svn status

Enfin, pour propager les différences sur le dépôt, on fait :

svn commit

L'enregistrement de ces modifications se fait essentiellement de façon interactive. Par exemple, on peut indiquer un message qui indique un résumé des changements.

D.2.4. Branches et convergencesOn a dit qu'un projet peut contenir plusieurs branches de développement. Pour créer une nouvelle branche de développement, dans le dépôt, on créé un nouveau dossier. On place ce dossier où l'on veut (généralement dans le dossier « branches »), et on effectue une copie des fichiers depuis la branche principale :

svn copy http://svn.example.com/repository/project/trunk \

>http://svn.example.com/repository/project/branches/new_branch

Une fois que l'on a créé cette branche, on peut faire l'opération de clonage (avec « checkout ») sur sa machine. On pourra travailler et mettre à jour son travail sans impacter la branche principale.

93/104


Toute les jonctions de versions se font avec la commande « merge ». En utilisant cette commande, on fait converger les données de la version indiqué par l'URL dans la version de travail dans laquelle on se trouve. Si l'on prend un exemple où l'on a connaissance de changements sur la branche principale et que l'on veut mettre à jour sa branche de développement, on fait :

svn merge http://svn.example.com/repository/project/trunk

Avant de faire cette commande, il faut s'assurer que l'on a bien enregistré les changements effectués sur ses documents (par un « commit »). Sinon, on prend le risque de réécrire par dessus ces documents.

Pour faire la jonction de la branche de développement avec la branche principale, il faut faire quelques opérations supplémentaires :

• On prend soin de faire une mise à jour du travail terminé sur sa branche sur le serveur (« commit » depuis sa branche de développement).

• On se déplace sur une copie locale de la branche principale et on la met à jour (utilisation de la commande « update »).

• On demande à faire la jonction entre notre copie locale de la branche principale et notre branche de développement :

svn merge --reintegrate \

>http://svn.example.com/repository/project/branches/personnal

Lorsque les changements ne créent pas de conflits, il reste peu de choses à faire. Sinon, il faut éditer les fichiers avant de faire le dernier « commit ». On peut au préalables voir les différences au sein des fichiers en faisant :

svn diff

Cette commande présente les différences sous le format « diff », ce qui permet éventuellement de copier sa sortie dans un fichier de patch.

• Puis l'on met à jour la branche principale sur le serveur (en faisant un « commit »).

D.3. Autres commandesPour voir ce que contient un dossier spécifique du projet, on fait :

svn list file:///path_to_repos/project_dir

• Si l'on veut obtenir les informations du dossier sur lequel on travaille, on se déplace dans ce dossier et l'on fait :

svn info

94/104


On obtient alors des informations utiles telles que : l'URL de la racine du dépôt, l'URL du dossier de travail, la révision...

Lorsque l'on a supprimé des fichiers et que l'on se rend compte que l'on souhaitai les conserver, on peut faire appel au suivi de version. Pour restaurer un fichier, on peut faire :

svn revert file_name

95/104


E. Mise en place d'un serveur TFTP

E.1. InstallationDans le cadre de mon projet, en utilisant une distribution Ubuntu sur le PC hôte, le serveur est récupérable directement depuis les dépôts. Il suffit donc d'utiliser le gestionnaire de paquets :

sudo apt-get install tftpd tftp xinetd

On récupère le serveur (tftpd), le client (tftp) TFTP et l'on installe le super serveur Internet (xinetd) s'il n'est pas déjà installé.

E.2. ConfigurationOn commence par créer un dossier dans lequel les informations mises à la disposition des machines distantes seront déposées. Le dossier correspondant est créé à la base de l'arborescence système, dans le dossier /srv/. Ce dernier dossier est celui, dans le cas des systèmes de type Linux, abrite les données des serveurs qui fonctionnent sur la machine.

sudo mkdir /srv/tftpboot

sudo chmod -R 0777 /srv/tftpboot

sudo chown -R nobody /srv/tftpboot

En plus de créer le dossier, on change les priorités de ce dossier et le propriétaire de ce dossier. On accepte que le dossier appartienne à l'utilisateur non identifié, habituellement appelé « nobody ». On accepte aussi que les utilisateur de ce dossier aient le droit de visionner le contenu de ce dossier, d'écrire des fichiers dans ce dossier et de pénétrer dans ce dossier.

Une fois que ces modifications ont été faites, on édite le fichier /etx/xinetd.d/tftp.

96/104

Annexes - Mise en place d'un serveur TFTP

service tftp

{

protocol = udp

port = 69

socket_type = dgram

wait = yes

user = nobody

server = /usr/sbin/in.tftpd

server_args = /srv/tftpboot

disable = no

}

En particulier, il est important que le paramètre « server_args » corresponde au dossier dans lequel sont placés les documents à partager.

Un fois ces opération réalisées, on redémarre le serveur xinetd :

sudo /etc/init.d/xinetd restart

E.3. Vérification de la configurationOn peut tenter de faire une copie d'un fichier localement mais en utilisant le serveur.

Puisque nous étions plusieurs à être sur le même réseau, j'ai aussi demandé à l'un de mes collègues de faire l'opération depuis son poste.

97/104


F. Mise en place d'un serveur NFS

F.1. InstallationDans le cadre de mon projet, en utilisant une distribution Ubuntu sur le PC hôte, le serveur est récupérable directement depuis les dépôts. Il suffit donc d'utiliser le gestionnaire de paquets :

sudo apt-get install nfs-kernel-server

F.2. ConfigurationJ'ai décidé de créer un dossier dans lequel les informations mises à la disposition de la carte seront déposées. Le dossier correspondant est créé à la base de l'arborescence système, dans le dossier /srv/. Pour rappel, ce dernier dossier est celui qui, dans le cas des systèmes de type Linux, abrite les données des serveurs fonctionnant sur la machine.

sudo mkdir /srv/nfsboot

Les fichiers à partager, les personnes autorisées et les permissions sont définies dans un fichier spécifique : /etc/exports. Les fichiers et les permissions sont de la forme :

<dossier partagé> <hôte>(<options>) <hôte2>(<options>) ...

Dans mon cas, il prend la forme suivante :

/srv/nfsboot viper(rw,no_root_squash) montevideo(rw)

98/104

Annexes - Déboguage symbolique : gdb

G. Déboguage symbolique : gdb

G.1. Procédure de déboguage à distance

G.1.1. Les paramètres spécifiquesUne application est généralement liée dynamiquement à un certain nombre de librairies.

Au départ, le débogueur (sur la machine hôte) va chercher les librairies selon des chemins absolus, comme le montre la commande suivante :

(gdb) show solib-absolute-prefix

The current system root is "".

Il va donc chercher les librairies du système hôte, qui ne correspondent pas à celles qui sont utilisés par l'application sur la machine cible. Comme généralement, il existe une copie du système de fichier de la machine cible sur la machine hôte, on peut ajouter un préfixe pour la recherche des librairies dynamiques :

(gdb) set solib-absolute-prefix path_to_rootfs

(gdb) show solib-absolute-prefix

The current system root is "path_to_rootfs".

G.1.2. L'initialisation de la sessionOn commence par faire démarrer le programme avec le serveur gdb sur la machine cible :

root@viper:/root$ gdbserver 192.168.0.117:2345 example_task

Process example_task created; pid = 388

Listening on port 2345

De l'autre côté, sur la machine hôte, on démarre le débogueur gdb avec la version de notre programme contenant les symboles de déboguage :

berruer@montevideo:~/xenomai/tmp$ arm-none-linux-gnueabi-gdb \

>example_task

[...]

(gdb) target remote 192.168.0.118:2345

Remote debugging using 192.168.0.118:2345

99/104


La connexion doit alors être établie. On en a la confirmation par l'apparition de la ligne suivante sur la console de la cible :

Remote debugging from host 192.168.0.117

G.2. Les commandes usuellesBeaucoup d'informations peuvent être obtenues à partir de la commande « info » de gdb.

G.2.1. Le lien avec les librairies dynamiquesPour voir quelles sont les librairies qui sont liées à un programme, il faut utiliser la commande :

(gdb) i sharedlibrary

From To Syms Read Shared Object Library

0x400007c0 0x40017690 Yes /srv/nfsboot/lib/ld-linux.so.3

0x40068660 0x4014a7b0 Yes /srv/nfsboot/lib/libc.so.6

[...]

En plus de cette fonctionnalité, il est parfois utile de savoir et de vérifier que le lien avec les librairies dynamiques s'est bien passé. Pour cela, on peut demander au débogueur de s'arrêter au moment de la création du lien :

(gdb) set stop-on-solib-events 1

G.2.2. Le déboguage des applications threadéesLorsqu'une application possède plusieurs fils d'exécution, on peut visualiser ces différents « threads » par la commande :

(gdb) i threads

2 Thread 396 0x40048f5c in rt_task_sleep () from /srv/nfsboot/usr/xenomai/lib/libnative.so.1

* 1 Thread 395 main (argc=1, argv=0xbe9f4e34) at example_task.c:37

Pour spécifier au débogueur de s'attacher à un « thread » en particulier, plutôt que le « thread » principal, on utilise :

(gdb) thread x

La commande frame permet de visualiser les différents contextes d'exécution du processus. On utilise ensuite la même commande en spécifiant le numéro du contexte

100/104

Annexes - Déboguage symbolique : gdb

d'exécution que l'on choisit, pour changer de « thread » :

(gdb) frame x

101/104


Bibliographie

Sites Internetwww.pc104.org Consortium du standard PC/104.

www.xenomai.org Site du projet Xenomai avec un accès au code source, à la documentation technique

www.kernel.org Archives du noyau Linux

www.arm.linux.org.uk Projet de portage du noyau Linux sur l'architecture ARM®

www. arm .com Site du consortium ARM®

www. intel .com Site du constructeur Intel®

www.linuxfromscratch.org Guide de développement d'un système GNU/Linux complet

www. slackware .com Site de la distribution Linux Slackware

lttng .org Environnement de traçage du noyau

www.pathname.com/fhs Document du Filesystem Hierarchy Standard

www.linuxfoundation.org Fondation Linux (hébergeant le comité LSB)

LivresThe C Programming Language, 2nd EditionBrian W. Kernighan, Dennis M. Ritchie.Prentice Hall PTR, 1988 - 274 p.

Building Embedded Linux Systems, 2nd EditionKarim Yaghmour, Jon Masters, Gilad Ben-Yossef, Philippe Gerum.O'Reilly Media Inc, 2008 – 462 p.

Embedded Linux PrimerA practical Real-World ApproachChristopher Hallinan.Prentice Hall PTR, 2007 - 537 p.

Understanding Linux Kernel, 3rd EditionDaniel Bovet, Marco Cesati.O'Reilly Media Inc, 2005 – 942 p.

Programmation système en C sous Linux, 2nd ÉditionSignaux, processus, threads, IPC et socketsChristophe Blaess.Eyrolles, 2005 – 964 p.

102/104

http://Www.pc104.org/

http://www.xenomai.org/

Linux Device Drivers, 3rd EditionJonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman.O'Reilly Media Inc, 2005 – 636 p.

Linux Kernel in a Nutshell, 1st EditionGreg Kroah-Hartman.O'Reilly Media Inc, 2006 – 198 p.

Running Linux, 5th EditionMatthias Kalle Dalheimer, Matt Welsh.O'Reilly Media Inc, 2005 – 972 p.

Learning the vi and Vim Editors, 7th EditionArnold Robbins, Elbert Hannab & Linda Lamb.O'Reilly Media Inc, 2008 – 494 p.

ArticlesDocumentation/CodingStyle and BeyondGreg Kroah-Hartman, 8 p.www.kroah.com/linux/talks/ols_2002_kernel_ codingstyle _paper/ codingstyle .ps

Adaptive Domain Environment for Operating SystemsKarim Yaghmour, 2001 – 7 p.www.opersys.com/ftp/pub/Adeos/adeos.pdf

Xenomai, 1st EditionImplementing a RTOS emulation framework on GNU/LinuxPhilippe Gerum, 2004 – 12 p.http://www.xenomai.org/documentation/branches/v2.3.x/pdf/xenomai.pdf

Life with Adeos, rev Bwww.xenomai.org/documentation/branches/v2.3.x/pdf/Life-with-Adeos-rev-B.pdf

A tour of the native API, rev Cwww.xenomai.org/documentation/branches/v2.3.x/pdf/Native-API-Tour-rev-C.pdf

Proceedings of Linux Symposium, Volume two23 au 26 juillet 2008, Ottawa, Ontario, CANADA'Real Time' vs. 'Real Fast': How to Choose?Paul E. McKenneywww.linuxsymposium.org/2008/ols-2008-Proceedings-V2.pdf

An advanced course on PC/104Jim Blazer,PC/104 and smallformfactors (PC1042289),2007 – 3 p.www.smallformfactors.com/pdfs/RTD.Win07.pdf

Choosing the appropriate PC/104 format

103/104

http://www.smallformfactors.com/pdfs/RTD.Win07.pdf

http://www.linuxsymposium.org/2008/ols-2008-Proceedings-V2.pdf

http://www.xenomai.org/documentation/branches/v2.3.x/pdf/Native-API-Tour-rev-C.pdf

http://www.opersys.com/ftp/pub/Adeos/adeos.pdf


Kristin Allen,PC/104 and smallformfactors (PC1042115), Resource Guide 20072007 – 2 p.www.smallformfactors.com/pdfs/KristinAllenMktg.RG07.pdf

104/104

Documents

Rapport de projet de fin d'étude - Équipe Automatique ...icube-avr.unistra.fr/fr/images/8/87/Rapport_Berruer.pdf · de nombreux conseils et avis techniques au cours du projet