Rapport Berruer

ENSPS
Ple API Parc d'innovation

Bd Sbastien Brant
BP 10413
67412 ILLKIRCH CEDEX
Tl : 03 90 24 45 10
Fax : 03 90 24 43 46
Rapport de projet de fin d'tude

Portage et valuation de Xenomai sur une plateforme PC/104
Altran Ouest
Centre d'affaires Alphasis
Sbastien BERRUER Espace Performance
Tel : 06 76 35 29 55 Btiments J&K
35760 St Grgoire
Option ISAV Tel : 02 23 25 36 00
Promotion 2009 Fax : 02 23 25 36 01
Remerciements
Je tiens remercier Mme Alexandra Poirier, responsable des Ressources Humaines, et
Mr Christophe Ducolone, Directeur Oprationnel, pour m'avoir donn la chance de faire
ce stage au sein d'Altran Ouest.
Je voudrais remercier Mr Jean-Michel Hautbois, mon matre 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
gnral. Il a su me mettre en confiance et me motiver tout au long de la priode.
Je souhaite remercier Mrs Stphane Davy et Jean-Philippe Foures. Ces personnes ont
travaill dans le mme contexte que moi et m'ont apport leurs avis sur certains
problmes techniques. Ils ont aussi apport une ambiance de travail studieuse mais
dcontracte.
Finalement, je remercie toutes les personnes que j'ai pu rencontrer au sein d'Altran
Ouest pour leurs gentillesse et leur accueil.
2/104
Rsum
J'ai effectu mon stage de troisime anne au sein du centre de service eLiSe. Ce
centre de service est spcialis dans le domaine des systmes Linux embarqus. C'est
une spcificit 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 systme temps-rel Xenomai. Cela m'a permis de
comprendre les caractristiques des systmes temps-rels et de dcouvrir les
domaines d'applications courants pour ces systmes. J'ai aussi abord les diffrences
qu'apporte le patch-RT sur le noyau Linux. En regard de cette solution, j'ai
profondment tudi le systme Xenomai : son utilisation d'Adeos, la faon dont il
gre le temps-rel et l'utilisation de ce systme travers son API.
J'ai effectu plusieurs tches 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
mthodes de communications avec cette carte. Suite un problme de disponibilit
de ressources, j'ai cr le systme de fichier utilis au cours de l'tude. Enfin, j'ai pu
raliser le portage de Xenomai sur la carte PC/104 et tudier les performances du
systme.
3/104
Summary
I 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 matires
Remerciements.............................................................................................2
Rsum........................................................................................................3
Summary.....................................................................................................4
Liste des abrviations.....................................................................................9
Introduction................................................................................................10
Prsentation de l'entreprise..............................................................................11
1.Groupe Altran...........................................................................................12
1.1.L'implantation.....................................................................................12
1.2.Les domaines d'activits......................................................................12
1.3.Les chiffres cls..................................................................................13
2.Altran Ouest.............................................................................................14
2.1.L'implantation.....................................................................................14
2.2.L'organigramme..................................................................................14
2.3.Les secteurs d'activits d'Altran Ouest...................................................15
2.4.Les comptences de la branche TEM......................................................16
3.eLiSe : embedded Linux Services................................................................17
3.1.Les comptences................................................................................17
3.1.1.Dveloppement et personnalisation noyau.......................................18
3.1.2.Environnement de bas niveau.........................................................18
3.1.3.Intgration d'applications..............................................................18
3.1.4.Environnements de dveloppement.................................................18
3.2.Les plateformes d'tudes.....................................................................18
3.2.1.Veille technologique......................................................................18
3.2.2.La carte industrielle Arcom VIPER...................................................19
3.2.3.Le tlphone Android ...............................................................19
3.2.4.Le tlphone OpenMoko ...........................................................19
3.3.Les services.......................................................................................20
3.3.1.Audit et expertise.........................................................................20
3.3.2.tudes et avis de faisabilit............................................................20
3.3.3.Dveloppement et support.............................................................20
Les systmes temps-rels.................................................................................21
1.Introduction aux systmes temps-rels........................................................22
2.Contraintes du temps rel..........................................................................22
2.1.Les chances....................................................................................22
2.2.Les latences.......................................................................................22
2.3.La premption....................................................................................24
3.Utilisations typiques..................................................................................24
3.1.Temps rel dur...................................................................................25
3.2.Temps rel mou..................................................................................25
4.Patch-RT..................................................................................................25
4.1.Modifications structurelles....................................................................26
4.1.1.Les chemins d'excutions..............................................................26
4.1.2.La premption du noyau................................................................26
4.1.3.La gestion des interruptions...........................................................27
4.2.Modifications comportementales...........................................................28
4.2.1.Les modes de configuration............................................................28
4.2.2.L'hritage de priorit.....................................................................29
5/104
4.3.Compteurs haute rsolution...............................................................30

5.Xenomai..................................................................................................31
5.1.Historique..........................................................................................31
5.2.Adeos................................................................................................32
5.2.1.Les domaines...............................................................................32
5.2.2.Le pipeline d'interruption...............................................................33
5.3.Gestion du temps-rel.........................................................................34
5.3.1.L'utilisation d'Adeos......................................................................34
5.3.2.L'architecture de Xenomai..............................................................35
5.3.3.Les modes d'excution..................................................................36
5.3.3.1.La migration des fils d'excution...............................................36
5.3.3.2.Le temps-rel dans le mode secondaire.....................................36
5.4.API temps-rel...................................................................................37
5.4.1.Les Skins ...............................................................................37
5.4.2.L'API native temps-rel..................................................................37
5.4.3.Real-Time Driver Model.................................................................39
Travail ralis..................................................................................................40
1.Environnement de dveloppement...............................................................41
1.1.L'arborescence de travail......................................................................41
1.2.Les outils...........................................................................................42
1.2.1.Logiciel de suivi de version : git......................................................42
1.2.2.Le systme d'information du centre de service..................................42
1.2.3.Portail de collaboration : Trac.........................................................43
1.3.Les outils de compilation croise...........................................................44
1.3.1.Contraintes..................................................................................44
1.3.2.Dpaquetage...............................................................................45
1.3.3.Modification des variables d'environnement......................................45
1.3.4.Tests de l'environnement...............................................................45
2.Prise en main de la carte Viper....................................................................46
2.1.Le chargeur d'amorage : RedBoot........................................................46
2.2.Communication avec la carte Viper........................................................47
2.2.1.Liaison srie avec C-Kermit............................................................47
2.2.2.Liaison Ethernet et console Telnet...................................................47
2.3.Configuration de dmarrage.................................................................48
2.3.1.Le chargement du noyau par TFTP..................................................48
2.3.2.Le montage du systme de fichier par NFS.......................................49
3.Cration du systme de fichier....................................................................50
3.1.Motivations........................................................................................50
3.2.Squelette de base...............................................................................51
3.2.1.Les directives du FHS....................................................................51
3.2.2.Les fichiers de priphriques..........................................................52
3.3.Applications.......................................................................................53
3.3.1.SysVinit.......................................................................................53
3.3.2.BusyBox......................................................................................54
3.4.Dmarrage.........................................................................................56
3.4.1.Le choix du systme rc..................................................................56
3.4.2.Les sessions utilisateurs................................................................57
3.4.3.Le serveur inetd...........................................................................57
3.4.4.Le serveur Telnet..........................................................................58
4.Portage de Xenomai..................................................................................59
6/104
4.1.Manipulations sur le noyau Linux...........................................................59
4.1.1.Patch du noyau............................................................................59
4.1.2.Configuration du noyau.................................................................60
4.1.3.Compilation du noyau...................................................................60
4.2.Installation sur le systme de fichier......................................................61
4.2.1.Mise en place du noyau.................................................................61
4.2.2.Compilation des librairies...............................................................62
5.valuation de Xenomai...............................................................................63
5.1.Visualisation de la console....................................................................63
5.2.Critres d'valuations..........................................................................64
5.2.1.Les situations propices aux latences................................................64
5.2.2.La mesure de la gigue...................................................................65
5.3.La suite de tests.................................................................................65
5.3.1.Clocktest.....................................................................................66
5.3.2.Cyclic..........................................................................................67
5.3.3.Klatency......................................................................................67
5.3.4.Latency.......................................................................................68
5.4.Rsultats...........................................................................................68
5.4.1.Commentaires critique..................................................................68
5.4.2.Analyse des mesures de clocktest ..............................................69
5.4.3.Analyse des mesures de latency ................................................69
5.5.Le traceur du pipeline..........................................................................70
6.Dveloppement sous Xenomai....................................................................70
6.1.Ralisations.......................................................................................70
6.1.1.Les comptences acquises.............................................................70
6.1.2.Les outils.....................................................................................71
6.2.Dvelopper des bonnes pratiques ....................................................71
6.2.1.Le management des tches............................................................71
6.2.2.L'accs aux donnes.....................................................................72
6.3.Le dboguage des applications..............................................................73
6.3.1.Dboguage symbolique.................................................................73
6.3.2.Le traage des appels systmes......................................................74
Conclusion..................................................................................................76
Ouverture...................................................................................................76
Annexes.........................................................................................................77
A.Caractristiques de la carte Viper................................................................78
A.1.Processeur.........................................................................................78
A.2.Mmoire............................................................................................79
A.3.Connecteurs srie...............................................................................79
A.4.Fonctionnalits rseau.........................................................................79
B.Rsultats du programme latency ............................................................80
B.1.Mesures releves (n1).......................................................................80
C.Logiciel de suivi de version : git..................................................................84
C.1.Concepts...........................................................................................84
C.2.Utilisation..........................................................................................85
C.3.Autres commandes.............................................................................87
D.Logiciel de suivi de version : svn.................................................................89
7/104
D.1.Concepts...........................................................................................89
D.2.Utilisation..........................................................................................90
D.3.Autres commandes.............................................................................92
E.Mise en place d'un serveur TFTP..................................................................94
E.1.Installation........................................................................................94
E.2.Configuration.....................................................................................94
E.3.Vrification de la configuration..............................................................95
F.Mise en place d'un serveur NFS...................................................................96
F.1.Installation.........................................................................................96
F.2.Configuration......................................................................................96
G.Dboguage symbolique : gdb.....................................................................97
G.1.Procdure de dboguage distance......................................................97
G.2.Les commandes usuelles.....................................................................98
Bibliographie.............................................................................................101
Sites Internet.........................................................................................101
Livres...................................................................................................101
Articles.................................................................................................102
8/104
Liste des abrviations
API 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
Introduction
J'ai effectu mon stage de troisime anne dans le centre eLiSe du groupe Altran,
Rennes. Ce centre est spcialis dans les systmes Linux Embarqus.
Dans le cadre du dveloppement de l'activit de cette branche, j'avais pour mission de
porter l'environnement temps-rel 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 prsent de ce rapport de stage, je commence par prsente le groupe Altran.
J'y dtaille l'activit du groupe et je donne quelques chiffres cls. Je prsente ensuite
l'organisation du groupe au niveau de Rennes ainsi que les activits d'Altran Ouest
dans la rgion. Enfin, je prsente le centre de service eLiSe.
Je joint dans le rapport un compte-rendu de mes recherches sur les systmes
temps-rels de type Linux. Je dcris les spcificits des systmes temps-rels, les
distinctions qui peuvent exister dans ce domaine ainsi que les principaux utilisateurs
de tels systmes. Au cours des recherches sur Xenomai, j'ai souvent rencontr des
rfrences au patch-RT pour le noyau Linux ; je prsente donc un rapide aperu des
modifications qu'il apporte au noyau Linux. Enfin, aprs un rapide historique du projet
Xenomai, j'explique le systme Adeos et la faon dont Xenomai l'utilise pour grer le
temps-rel. Je termine la prsentation de Xenomai en faisant une description des
mcanismes introduit au niveau utilisateur (utilisation des API).
Le corps du rapport est constitu par la prsentation des activits que j'ai men au
cours de ces 5 mois. Je prsente donc : la mise en place de l'environnement de
dveloppement, la prise en main de la carte Viper et le processus de cration du
systme de fichier. Une fois ces tapes ralises, j'ai pu procder au portage de
l'environnement Xenomai sur la carte. Mon stage consistait aussi faire une
valuation des performances du systme. Dans cette optique, j'ai dvelopp quelques
applications utilisant l'API temps-relle de Xenomai.
10/104
Prsentation de l'entreprise
Altran Ouest
1. Groupe Altran
1.1. L'implantation
Le groupe Altran a t fond en 1982. Il est implant dans 26 pays dans le monde.
Illustration 1 : Implantations d'Altran dans le monde

En Amrique : En Europe :
Brsil Allemagne Pologne
Canada Autriche Portugal
tats-Unis Belgique Rpublique Tchque
d'Amrique Espagne Roumanie
En Asie : France Royaume-Uni
Irlande Slovaquie
Chine Italie Sude
Core du Sud Luxembourg Suisse
Inde Pays-Bas
Japon
Malaisie
Singapour
Le nombre important d'implantations sur le continent Europen permet au groupe de

se positionner aujourd'hui comme le leader europen dans le domaine du conseil en
innovation.
1.2. Les domaines d'activits

Le groupe fdre des entreprises qui officient dans trois domaines d'activits
diffrents (appels Business Lines ).
12/104
Les domaines d'activits - Les domaines d'activits
Illustration 2 : Les trois "Business Lines" et le

cycle d'innovation
Les trois domaines, constituant le cur du diagramme ci-dessus, sont :

le conseil en technologies et R&D
C'est la capacit de mettre en uvre le savoir-faire, les mthodes techniques et
scientifiques des consultants ingnieurs pour mener bien des projets
innovants.
le conseil en organisation et systmes d'information
Il permet de fournir aux entreprises la capacit de rester comptitif face aux
contraintes de croissance d'entreprise, de rentabilit et de lgislation. Les
entreprises qui font appel Altran sur ce point cherchent faciliter leurs prises
de dcisions, et leurs agilit organisationnelle.
le conseil en stratgie et management
Il permet aux entreprises de matriser leurs environnement et d'anticiper les
volutions du secteur dans lesquelles elles travaillent. Cela leurs permettent
d'augmenter leurs potentiel de succs sur le long terme.
Comme le prsente la couronne sur le schma 2, le positionnement des trois
domaines d'activits permet de couvrir totalement un cycle de produit.
1.3. Les chiffres cls

Pour l'anne 2008, le chiffre d'affaire s'est lev 1650,1 million d'euros. Il a t
ralis 57% hors de France. La gnration du CA tant :
13/104
prs de la moiti du chiffre d'affaire est ralis par les activits de la branche
conseil en technologies et R&D
un tiers du chiffre d'affaire provient des activits de la branche conseil en
organisation et systmes d'information
environ 15% du chiffre d'affaire est produit par la branche conseil en stratgie
et management
Les consultants du groupes taient 18522 en dcembre 2008. Il y a eu 1020
recrutements nets au cours de l'anne 2008.
2. Altran Ouest
2.1. L'implantation
Au niveau Franais, une rorganisation a t mene pour fusionner une multitude de
socits. Il a donc t dlimit six zones, en plus de Paris : la rgion Ouest, la rgion
Est, la rgion Nord, la rgion Sud-ouest, la rgion Rhne-Alpes et la rgion
Mditerrane.
L'implantation du groupe Altran dans l'Ouest date de 1984. Les trois plus gros ples
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 ingnieurs rpartis
sur les rgions Bretagne, Pays de Loire et Poitou-Charentes. Pour mieux cerner la
rpartition, on compte 230 consultants Rennes, 85 Brest et 110 Nantes.
2.2. L'organigramme
Le groupe Altran est gouvern grce un comit excutif et un conseil
d'administration. Le premier (le comit excutif) regroupe les personnes responsables
de la direction du groupe : le Prsident-Directeur Gnral, le directeur financier et
trois directeurs gnraux adjoints. Le second (le conseil d'administration) dcide de la
politique du groupe.
Ensuite, au niveau rgional, les comptences sont rparties de la faon suivante :
14/104
L'organigramme - L'organigramme
Illustration 3 : Organigramme au sein d'Altran Ouest
Les consultants sont les personnes qui effectuent la ralisation des projets. Ils
ont le profil ingnieur. On retrouve deux types de comptences : les experts et
les chefs de projet. Les experts sont spcialiss dans un domaine particulier.
Les chefs de projet se situent la frontire 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 rles souvent plus
transversaux : ils interviennent pour rpondre aux appels d'offres publics, ils
organisent les fonctions lis la Qualit...
Les managers ont trois rles principaux : le recrutement, le management d'une
quipe et la relation commerciale. Ainsi, ils dmarchent les clients pour trouver
des projets raliser. En fonction des demandes des clients, ils recherchent les
comptences parmi les personnes disponibles au sein d'Altran. Ils se mettent
gnralement en rapport avec les consultants pour bnficier de l'avis
technique de ces derniers lors de la phase de dcision des projets. Ils
participent aux ngociations 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 oprationnel oriente la politique du groupe au niveau rgional. Il
sollicite les managers en leurs donnant une direction commerciale. C'est
gnralement lui que revient la dcision de lancer la ralisation d'un projet.
2.3. Les secteurs d'activits d'Altran Ouest

Dans la rgion Ouest, les activits sont partages dans cinq secteurs mtiers . En
effet, au niveau rgional, Altran se tourne vers ses clients. Son activit est donc
mene selon les secteurs :
AIT : Automotive Infrastructure & Transportation
Altran met son expertise la disposition de ses clients pour amliorer leurs
efficacit, la qualit et le processus de leurs produits. Les consultants
interviennent sur les tches de Bureaux d'tude et R&D, de phase
15/104
d'industrialisation, de production, logistique, de Qualit...

Cette branche regroupe plus de 80 consultants dans l'Ouest.
ASD : Aronautique, Spatial, Dfense
Altran Ouest officie essentiellement sur deux grands domaines, dans la rgion :
les sciences et techniques de la mer, l'aronautique et la dfense. Le premier
est un domaine spcifique d'Altran Ouest. Il fait appel des comptences
telles que l'acoustique sous-marine, la gophysique... Le second domaine
ncessite plutt des personnes travaillant dans les domaines de l'lectronique,
des systmes embarqus, de la mcanique...
Actuellement, on compte 65 consultants dans l'Ouest.
CIS : Conseil & Systmes d'Information
Cette branche d'activit a pour but la performance des entreprises en
amliorant leurs organisation et leurs systmes d'informations. Le groupe est
capable de mettre en place des projets de conseils et d'expertise, de faire de la
matrise d'uvre et de la matrise d'ouvrage, de l'ingnierie systme et
intgration...
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 cosmtique). Elle aide ses clients sur les
problmatiques d'hygine, de scurit et d'environnement.
Dsormais, 15 consultants sont rattachs ce domaine.
TEM : Telecoms & Media
On peut considrer que c'est la branche historique d'Altran Ouest. Le groupe
revendique une exprience de plus de 20 ans dans les domaines de la
tlphonie mobile & TV numrique, les rseaux & tlcommunications,
l'lectronique.
Plus de 120 consultants font partie de cette branche.
2.4. Les comptences de la branche TEM

La branche TEM propose des comptences dans trois grands domaines :
la tlphonie et la tlvision numrique
Dans ce domaine, les comptences proposs sont celles lies au matriel, la
cration de codecs vido et audio, la connaissance des spcificits des bandes
de diffusion, l'application des protocoles de communication (GSM,
MPEGx, ...).
l'lectronique
Au sein de ce domaine, on compte des comptences telles que : la
connaissance de plates-formes matrielles spcifiques ou le design de cartes.
Dans cette spcialit, au niveau systme, le groupe la capacit de proposer la
16/104
Les comptences de la branche TEM - Les comptences de la branche TEM
conception et la ralisation de drivers, l'intgration et la connaissance de

systmes embarqus et temps-rel.
les rseaux et les tlcommunications
Les comptences dans ce domaine permettent de proposer au client des
solutions sur ses problmes de conception et de scurisation des rseaux, sur
l'interoprabilit, etc Altran peut apporter son expertise sur des techniques
telles que la VoIP, le WiFi, le WiMax.
3. eLiSe : embedded Linux Services

Le centre eLiSe est une particularit de la branche TEM dans l'Ouest. Les comptences
des personnes rattaches ce groupe concernent les systmes embarqus 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
dvelopper leurs comptences ou d'explorer un sujet parmi le domaine des systmes
embarqus.
3.1. Les comptences

Les comptences dployes au sein du centre de service touchent tous les domaines
des systmes embarqus, autant au niveau du matriel que du code source. L'tendue
de ces comptences permet de garantir une totale matrise des systmes dvelopps
dans le centre. Il en rsulte une meilleure qualit de ceux-ci.
Illustration 4 : Un systme GNU/Linux intgr au dessus

d'une plateforme matrielle
17/104
3.1.1. Dveloppement et personnalisation noyau

Le dveloppement noyau comporte la mise au point du BSP. Les portions de code
spcifique dveloppes pour une plateforme matrielle donne sont gnralement
minimales. ct du support de la carte, il faut parfois dvelopper des drivers
spcifiques pour les priphriques. En plus de tout cela, l'expertise du centre permet
de choisir les sous-systmes les plus performants pour une application donne ; par
exemple, le choix d'un systme de fichier parmi les variantes ext, jffs2.... Par rapport
au schma 4, les comptences explicites prcdemment se situent au niveau du
noyau, de ses drivers et de ses modules.
3.1.2. Environnement de bas niveau

Dans cette section, le travail porte sur la mise en place des librairies (librairie GNU C,
par exemple). Il peut aussi porter sur l'intgration des applications standards pour
utiliser une machine (un interprteur de commandes, les applications ls, cat...). Il
pourra y avoir parfois a effectuer le dveloppement d'outils spcifiques pour
l'initialisation du systme, le management du matriel... Le travail se situe donc au
dessus du noyau Linux, vis--vis des librairies et des applications GNU (voir le schma
4).
3.1.3. Intgration d'applications

Il faut garantir au client final le bon fonctionnement d'une application embarque.
Donc, il faut s'assurer que le logiciel fonctionnera bien sur la machine, que ce soit en
terme de trace mmoire, de consommation d'nergie ou de rapidit d'excution. On
peut aussi faire de l'analyse statique de code pour le rduire et/ou l'amliorer (avec la
possibilit que l'impact mmoire soit rduit).
3.1.4. Environnements de dveloppement

Le centre propose parfois de mettre en place des chanes de compilation finement
adaptes un matriel. Des chanes de compilation adaptes permettent d'amliorer
grandement le code excutable des applications. Le centre met en avant sa
comptence pour installer des environnements de dveloppements avec des outils
issus du monde du logiciel libre (par exemple, le logiciel de suivi de version git, le
logiciel de dboguage gdb...).
3.2. Les plateformes d'tudes
3.2.1. Veille technologique

Le centre de service rpond des besoins clients spcifiques mais il se place aussi en
amont de la demande, en grant des tudes en interne. Ces tudes permettent
d'anticiper les problmes clients. Cela permet d'acqurir des comptences et
d'entretenir la collaboration au sein des communauts 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 VIPER

La carte Arcom VIPER est une carte industrielle, typique des
applications automatises et/ou des rseaux embarqus.
Le travail ralis 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
cration d'applications viss multimdia (bibliothque graphique Qt, application
vido VLC). Pour ma part, j'ai effectu le portage de l'environnement temps-rel
Xenomai sur cette carte.
3.2.3. Le tlphone Android

Le tlphone HTC G1 permet de faire fonctionner le systme
d'exploitation Android. Le systme Android est un systme
d'exploitation (ayant une base Linux et utilisant majoritairement
le langage Java pour ses applications) destination des
tlphones et des appareils mobiles. L'effort de dveloppement
de cette plateforme est soutenu par Google. Le tlphone HTC
G1 est appel couramment le Google phone ou Android ,
en rapport avec son systme d'exploitation.
Actuellement, le systme Android semble se dessiner comme
une alternative intressante pour les appareils mobiles connects (smart-phones,
MID, net-books...). La socit HTC a t la premire commercialiser un tlphone
utilisant ce systme, 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 systme 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 ralis visant
porter le dcodeur h.264 SVC sur la plateforme. Ce format de compression (h.264
SVC) permet l'adaptation de la taille d'un flux vido en fonction de la disponibilit du
rseau. Les prochains lecteurs vido tlphoniques, intgrant ce format de
compression, devraient apporter une meilleure exprience aux utilisateurs en
fournissant de la vido sans interruptions.
3.2.4. Le tlphone OpenMoko

Le tlphone Neo FreeRunner permet de faire
fonctionner le systme d'exploitation OpenMoko.
Ce tlphone est un vritable smart-phone
utilisant le GSM, le WiFi, le GPRS, un cran
tactile...
L'intrt de ce tlphone repose sur l'entire ouverture de ses spcificits, depuis les
composants matriels jusqu'aux briques logicielles qui composent le systme. La
communaut qui est l'initiative de ce tlphone 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 tlphone.
19/104
3.3. Les services

Les services du centre se positionnent tout au long du cycle de vie d'une application.
3.3.1. Audit et expertise

Les personnes qui appartiennent au centre sont capables de proposer des valuations
aux clients. Ils peuvent mettre en avant les contraintes de compatibilits matrielles
et logicielles. Ils savent estimer la faisabilit d'un portage d'une application sur une
plateforme donne.
L'expertise de ces mmes personnes leurs permet de proposer l'optimisation
d'applications pour que celles-ci fonctionnent parfaitement sur un matriel donn.
L'optimisation peut porter sur la vitesse d'excution, l'empreinte mmoire 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 matriel et de logiciel qui rpondent un besoin
client. En effet, il existe des cas o le matriel impose des contraintes, ou apporte des
spcificits, qui influent sur les performances d'un systme.
Le centre se propose d'aider ses clients migrer d'un environnement propritaire un
environnement Linux selon une mthode guid, pas--pas. Cette migration se fait en
conservant l'isolation du code propritaire et du code source issu de la communaut
Open-source. Par exemple, cela vite la pollution des portions de codes rgies par
une licence GPL.
3.3.3. Dveloppement et support

Le dveloppement est un terme gnrique pour indiquer que le centre de service peut
proposer des conseils sur le dveloppement d'un BSP, la ralisation de celui-ci
(portage, dveloppement de drivers...) et le maintien de ce BSP. Il est aussi capable
de proposer du management d'applications. Ce terme inclut le dveloppement de
modules spcifiques, le maintien d'applications... Cela permet de satisfaire les
contraintes sur la dure de vie d'un produit, et donc de la rentabilit sur le long terme.
Lors du dveloppement d'un solution Linux embarqu, le centre de services produit
des conseils vis vis de l'architecture du systme, des tests raliser et propose une
dmarche d'assurance qualit. Les personnes du centre peuvent tre amenes
dispenser des sessions de formation aux clients sur les spcificits du monde
embarqu.
20/104
Les systmes temps-rels
Les solutions temps-rels de type Linux
1. Introduction aux systmes temps-rels

Les systmes temps-rels se caractrisent par des contraintes sur l'excution de leurs
processus. Ils visent gnralement la tenue de certaines chances. Pour cela, ils
cherchent diminuer les temps de latences et autoriser la premption du systme.
Les systmes temps-rels sont traditionnellement utiliss dans certains domaines. Ces
domaines imposent plus ou moins de contraintes vis--vis des chances ; ce qui
caractrise deux types de temps-rel : le temps-rel dur et le temps-rel 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 systmes
temps-rels part entire, fonctionnant ct du noyau.
La premire approche repose sur la modification du code source du noyau Linux. L'un
des points les plus marquant est la possibilit de prempter l'excution du noyau. De
plus, des mcanismes spcifiques sont introduit grce au patch, ainsi qu'une nouvelle
gestion du temps.
La deuxime approche a aboutit la cration du projet Xenomai. Cette solution
repose sur l'utilisation d'un autre projet : Adeos. Cela induit une architecture
particulire pour la gestion du temps-rel et la proposition d'une API spcifique pour
le temps-rel.
2. Contraintes du temps rel
2.1. Les chances

La contrainte d'un systme temps rel est le fait que le bon fonctionnement de ce
systme ne dpend pas seulement de la russite des oprations menes, mais aussi
de la russite de ces oprations dans un temps donn. Si les limites de temps sont
dpasss, on dit alors que le systme chou.
Ainsi, les systmes temps rels ne sont pas ncessairement rapides. Un systme
temps rel peu fonctionner sur une plateforme matrielle lente et bas cot. Par
contre, il est ncessaire que la ralisation des oprations, dans les limites de temps
imparties, soient garanties par un systme d'exploitation spcifique.
On parle gnralement de dterminisme. Il faut que l'on soit assur que l'opration
mene soit termine avant l'chance.
2.2. Les latences

La latence est le temps qui peut exister entre le moment o un vnement est notifi
et celui o il est effectivement trait.
En s'appuyant sur le schma Erreur : source de la rfrence non trouve, on peut
imaginer l'exemple d'un programme qui, au cours de son excution, fait la demande
d'une donne issue d'un priphrique. Lorsqu'il fait appel cette donne, cette
information n'est pas ncessairement disponible immdiatement. Il est donc mis en
sommeil de faon ce qu'un autre programme utilise l'unit de calcul, en
22/104
Les latences - Les latences
attendant que la donne soit disponible. Lorsque le signal d'interruption indique que la
donne est disponible, il existe un certain temps entre cette notification et la poursuite
du traitement du premier programme. Ce dlai est appel une latence d'excution
suite une interruption.
Illustration 5 : Latences d'excution suite un interruption
La latence d'excution (6) peut tre explique en dtail :

1. Latence l'excution de la routine d'interruption
Il existe un certain temps entre le moment o le signal lectrique (issu du
priphrique) signale l'interruption et le moment o la routine d'interruption
correspondante commence tre excute. Cela s'explique par le fait que le
processeur doit d'abord terminer l'excution de l'instruction en cours. En effet
les interruptions matrielles sont, par nature, asynchrones et les instructions
complexes prennent gnralement plusieurs cycles s'excuter entirement.
Avant d'excuter la routine d'interruption, le systme doit commencer par
sauver le contexte d'excution du processus actuel. Finalement, il prpare le
contexte d'excution de l'interruption (lecture de la position du vecteur
d'interruption dans une table, mise en place de la pile...).
2. Temps d'excution de la routine d'interruption
Il faut ajouter le temps d'excution de cette routine d'interruption.
3. Latence l'excution de l'ordonnanceur
Une fois cette routine d'interruption excute, il peut y avoir un appel
l'ordonnanceur. L encore, il existe un dlai entre le moment o l'ordonnanceur
est appel et le moment o il commence s'excuter. Ce temps s'explique de la
mme faon que pour la routine d'interruption : le noyau peut avoir effectuer
d'autres oprations avant d'excuter l'ordonnanceur (enlever un masque
d'interruption...).
4. Temps d'excution de l'ordonnanceur
De mme, il faut compter le temps d'excution du code de l'ordonnanceur.
5. Restauration du contexte d'excution
Enfin, il faut rtablir le contexte d'excution du processus qui avait t mis en
sommeil. Il faut commencer par rtablir les valeurs des registres d'excution du
processeur. Ainsi, le processus reprend sont excution au point o il en tait
rendu, de faon transparente.
23/104
Au total, il faut comprendre que l'on doit attendre la somme de toutes ces dures
avant qu'un programme ne ragisse un vnement donn.
2.3. La premption
La premption est la capacit d'interrompre l'excution d'une tche en faveur de
l'excution d'une autre tche.
Pour donner l'impression que plusieurs processus ont accs en mme temps l'unit
de calcul, les systmes multi-tches mettent un place le mcanisme
d'ordonnancement des tches. Ce concept (partage du temps d'utilisation du
processeur) repose sur la capacit du systme prempter l'excution du processus
en cours. Dans les systmes multi-tches, la premption du processus en cours se fait
au profit de l'ordonnanceur. L'ordonnanceur mne un arbitrage pour dcider quel
processus doit s'excuter.
Dans un systme temps-rel, il parat logique que les tches qui sont les plus critiques
gagnent le droit d'utiliser le processeur lorsqu'elles ont besoin de s'excuter. Ainsi,
toute section de code excutable 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 premption 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 rgis par la mise en place, dans les systmes temps-rels,
d'ordonnancements spcifiques : ordonnancement rapide (type Round-Robin ),
ordonnancement hritage de priorits...
3. Utilisations typiques
Les systmes temps-rels ne reposent pas que sur l'aboutissement des traitements,
ils font apparatre des contraintes sur les chances. Selon la gravit de la non tenue
des chances, on dfinit la duret du temps rel.
Illustration 6 : Rpartition des applications en fonction de leurs contraintes
24/104
Utilisations typiques - Utilisations typiques
En fonction de l'importance de la tenue des chances pour la ralisation des

oprations, on dfinit deux grandes catgories de temps-rel : le temps-rel dur et le
temps-rel mou.
3.1. Temps rel dur

On distingue les applications dites de temps rel dur, pour lesquelles, le non respect
des chances peut entrainer des graves problmes de scurit ou le non respect de
la qualit du service rendu. Dans ce cas, les exigences se prsentent sous une forme
imprative. Par exemple, la tche doit tre termine en, au maximum, 3ms.
Parmi les secteurs ncessitant des systmes temps rel dur, on retrouve
l'aronautique, la robotique ou l'industrie de contrle/supervision.
3.2. Temps rel mou

Les applications de temps rel mou peuvent se permettre de voir, bien que trs
rarement, des chances non respectes. Les exigences de temps se prsentent sous
la forme d'un ou plusieurs intervalles ainsi qu'un ratio de russite associ. Par
exemple, on voudra que la tche soit termine en moins de 3ms dans 80% des cas et
en moins de 5ms dans 99,9% des cas. La mesure de cette probabilit dfinie la
Qualit de Service.
On voit apparatre des applications de temps rel mou dans les domaines de la finance
et du multimdia.
Le premier domaine (la finance), bien que fonctionnant avec des intervalles de
dcompte de l'ordre de la milli-seconde, impose que les chances soient tenues.
C'est ce qui a suscit la mise en application de systmes temps-rel dans ce domaine.
Par exemple, l'indicateur des cents plus grosses capitalisations boursires du
Royaume-Uni, le FTSE1 100 Index , est calcul et diffus toutes les quinze
secondes, en temps-rel.
Le second domaine (le multimdia) illustre le fait que l'on puisse parfois accepter que
des chances ne soient pas vrifies. L'exemple typique est celui de la vido. Un
utilisateur courant accepte gnralement que le dcodage d'une vido ou d'une
musique soit brivement manqu lorsque son ordinateur est soumis une forte
charge.
4. Patch-RT
Depuis plusieurs annes, plusieurs personnes ont eu la volont de modifier le noyau
Linux pour qu'il soit capable de rpondre aux contraintes du temps-rel, 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 vritable systme temps rel. Le
mainteneur actuel de ce patch est Ingo Molnar, un ingnieur de la socit Red Hat.
Les programmes qui utilisent ce noyau modifi n'utilisent pas
d'API particulire, 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 dfini un
certain nombre d'appels systmes pour rsoudre les contraintes de temps-rel
(management de l'ordonnancement, signaux temps-rels, mthodes de cration de
threads ...). Prsents sous la forme d'amendements pour la version IEEE Std
1003.1-1990, ils ont t incorpors comme des options la norme, lors de sa rvision
en 2001.
4.1. Modifications structurelles
4.1.1. Les chemins d'excutions

Le chemin d'excution d'un processus est un indicateur macroscopique du
droulement des oprations raliss par ce processus. C'est une manire unifie et
linaire de se reprsenter le droulement des oprations du programme. En ralit, le
chemin d'excution d'un processus n'est pas linaire : de par la faon dont sont
excutes les instructions par le processeur, de par la faon dont a t optimis le
code la compilation...
On distingue gnralement les portions o le processus fait appel au noyau (via des
appels systmes) pour que celui-ci effectue des tches particulires : on dit que le
processus s'excute dans l'espace noyau. l'inverse, lorsque le processus n'effectue
pas de tches critiques, on dit qu'il s'excute dans l'espace utilisateur.
4.1.2. La premption du noyau

Gnralement, le noyau est la partie de code la plus critique du systme. C'est dans le
contexte du noyau que sont manipuls des structures de donnes sensibles : la table
des processus, la table des pages mmoires... C'est pour cela qu'il n'est gnralement
pas possible de prempter l'excution du noyau. Pourtant, si le noyau prempte un
processus et met longtemps complter son chemin d'excution, cela introduit des
latences d'excutions. L'excution du noyau peut empcher l'excution de processus
de hautes priorits.
La premire solution est de modifier la structure du noyau pour raccourcir les chemins
d'excution. En plus de cette premire approche, on peut dcider que le noyau puisse
tre prempt.
2 La norme POSIX (Portable Operating System Interface) est issu de la ncessit pour les
diffrents systmes 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 premption du noyau - La premption du noyau
Illustration 7 : Premption du noyau
Si un processus demande un service au noyau (suite un appel systme, par

exemple), on considre que son chemin d'excution passe en mode noyau. Dans le
schma 7, le chemin d'excution du processus 1 peut tre compris comme la trace
verte. La premption du noyau intervient lorsqu'une tche de plus haute importance a
aussi besoin de s'excuter dans l'espace noyau. Dans le schma prcdent, le
processus 2 prempte l'excution du processus 1, qui est en mode noyau, au profit de
sa propre excution. Ainsi, la tche de plus haute importance n'est pas oblige
d'attendre la fin du chemin d'excution 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 empcher
que deux processus modifient les mmes donnes lorsqu'ils ont un accs concurrent
au noyau. Le patch-RT met en place, autour des portions de code critique, des
structures spcifiques ( mutex3 , par exemple) qui empchent l'accs simultan de
ces portions. On protge ainsi l'accs aux structures sensibles et l'on assure la
cohrence des donnes contenues.
4.1.3. La gestion des interruptions

Dans un noyau standard, et pour un driver correctement construit, le traitement des
interruptions se dcoupe en : une routine d'interruption (trs courte) et une
softirq (ou tasklet ). La routine d'interruption essaye de faire uniquement le
travail le plus important (copier les donnes depuis le buffer du priphrique vers
un emplacement mmoire, modifier un bit d'acquittement sur le matriel...). Elle
laisse le reste des traitements la tche de la softirq .
Les composants qui grent une interruption (ISR4 et softirq) premptent les processus
pour s'excuter, quels que soit leurs priorits. Ce mcanisme peut-tre pnalisant
dans un systme temps-rel : si le traitement de l'interruption est long, il empche le
processus de s'excuter et apporte une latence dans le systme. Il peut aussi y avoir
un flot soudain d'interruptions. Dans un noyau classique, cela ncessite l'excution de
nombreuses routines d'interruptions la suite. Pendant que les routines
d'interruptions occupent le processeur, les processus ne peuvent pas s'excuter.
Dans les systmes temps-rel, il faut pouvoir dcider que certaines interruptions
soient retardes si leurs importance est moindre, compar l'excution et
3 MUTEX : MUTual Exclusion (exclusion mutuelle)
4 ISR : Interrupt Service Routine
27/104
l'aboutissement du traitement men par un processus.

Bien sr, on ne peut empcher 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 crer un fil d'excution noyau (un
thread noyau ). Il ne fait que cette opration avant de retourner l'excution du
processus prcdent : crer et complter la structure contenant les informations du fil
d'excution. Le fil d'excution contiendra le corps de la routine d'interruption.
L'avantage de cette configuration est que les fils d'excution peuvent tre
ordonnancs au mme 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'excution des routines d'interruption. La gestion du temps-
rel sur le systme repose ensuite sur la capacit de l'administrateur chelonner
correctement les priorits 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'amnent pas la perte de donnes. Il faut aussi rflchir ce que
n'apparaisse pas une situation d'inter-blocage ( deadlock ).
4.2. Modifications comportementales
4.2.1. Les modes de configuration

Le patch-RT propose plusieurs configurations possibles pour la modification des
sources. Une fois que le patch est appliqu, de nouvelles entres 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 premption (PREEMPT_NONE)
Lorsque le premire option est choisie, le noyau Linux fonctionne comme il le
faisait dans les versions antrieures 2.4. Lorsque du code s'excute en mode
noyau, il est impossible de le prempter. Ce mode est avantageux dans le sens
o il y a moins de changements de contextes et donc moins de charge pour
systme ( overhead li l'ordonnancement, par exemple). De plus, le cache
est moins souvent renouvel et donc mieux utilis.
premption volontaire du noyau (PREEMPT_VOLUNTARY)
La deuxime option repose sur le fait que le code du noyau contient des appels
une fonction utilise des fin de dboguage : la fonction might_sleep.
Traditionnellement, cette fonction vrifie si l'ordonnancement peut tre effectu
sans problmes et affiche un message indiquant le rsultat de ses tests. La
deuxime configuration du patch-RT utilise cette fonction pour effectuer un
appel l'ordonnanceur. Ainsi, chaque endroit o la fonction apparat devient un
point de premption possible. Cette option est scurisante et amliore la
ractivit d'un systme. Elle prsente le dsavantage de restreindre la
premption des zones bien dtermines du noyau.
premption du noyau (PREEMPT_DESKTOP)
La premption 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 mthode, un

processus qui bloque sur un verrou se met excuter une boucle infinie en
attendant que le verrou ne se libre. La mthode trouve sa meilleure
application sur les systmes multi-processeurs.
Il y a tout de mme certains dfauts majeurs pour cette implmentation.
En gnral, le code qui est protg 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
protge. Cela va l'encontre du dterminisme : on ne peut savoir l'avance
quel processus (et donc, quel longueur de code) va tre la cause du blocage.
Si un processus dtient un verrou, il empche tout les autres processus de le
prempter, mme s'ils ne souhaitent pas accder la portion de code
actuellement utilise.
Dans le cas d'un systme mono-processeur, l'attente active consiste continuer
d'autoriser l'accs au processeur pour une tche 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.
premption complte (PREEMPT_RT)
La stratgie qui est mise en place dans la configuration prcdente ne rsout
pas compltement le problme. Il faudrait que chaque portion de code
critique soit protge par son propre systme de verrou. Pour cela, dans la
configuration premption complte , la majorit des verrous qui taient
implments dans la configuration prcdente sont transforms 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
ordonnancs. Le mcanisme mis en place permet de diminuer le temps de
raction des processus temps-rel. Les latences sont largement rduites.
4.2.2. L'hritage de priorit

Il existe un problme rcurrent dans la thorie d'ordonnancement des tches. Ce
problme est connu sous la dnomination : inversion de priorit .
On prsente gnralement un exemple avec trois processus, de priorits croissantes.
29/104
Illustration 8 : Exemple d'inversion de priorit
Le processus 1, de plus faible priorit, s'excute et protge un accs une donne

sensible l'aide d'un mcanisme de type mutex . Un processus de plus haute
priorit (processus 3) est dmarr. Il prempte l'excution du premier processus
puisqu'il possde une priorit plus leve. Si le processus souhaite avoir accs la
mme donne que le processus de faible priorit, selon les mcanisme de mutex, il
est mis en sommeil. Il va devoir attende que le processus de plus faible priorit
termine sont traitement. Le problme apparat si un processus de priorit
intermdiaire (processus 2) est dmarr car il prempte l'excution du processus
de plus faible priorit. Il retarde donc d'autant le redmarrage du processus de plus
haute priorit (qui est toujours en attente de la libration de la ressource par le
processus de plus faible priorit).
La solution est de faire hriter la priorit lev du processus qui fait la demande de
ressource, au processus qui la dtient. Le processus qui dtient la ressource est donc
ordonnanc prioritairement. Il libre donc la ressource plus rapidement. Une fois qu'il
libre la ressource, il retrouve sa priorit originelle, et se fait prempter par le
processus de plus haute priorit qui faisait une demande concurrente. Le temps
d'attente est donc rduit.
Si ce problme apparat dans l'excution de fils d'excution noyau, cela peut avoir des
effets dsastreux (un processus de priorit lev peut se retrouver bloqu quasi
infiniment). C'est pour cela que le patch-RT met en place l'hritage de priorit sur les
mcanismes de protection du noyau.
Thomas Gleixner, Ingo Molnar et d'autres contributeurs ont implments un
mcanisme de protection, base de mutex, rapide et robuste appel robust futex .
Ce mcanisme a t implment partir des mutex lgers (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 suprieure.
4.3. Compteurs haute rsolution

Pour que le noyau soit capable de rpondre l'arrive d'un vnement, il faut qu'il
30/104
Compteurs haute rsolution - Compteurs haute rsolution
soit capable de distinguer l'arrive de cet vnement dans le temps. La plus petite
unit que le noyau est capable de rsoudre est le jiffy . La frquence (en Hertz)
des jiffies est essentiellement calcule partir d'une variable nomme HZ.
La diminution de cette unit de temps minimale permet d'augmenter la rsolution
temporelle du systme. Mais, la mise jour du compteur de jiffies ncessite
l'excution d'une routine d'interruption li l'horloge. Donc, il y a le risque de
surcharger le systme (avec le traitement de cette interruption) lorsque l'on
augmente la rsolution du systme.
L'implmentation originale des compteurs fait apparatre des latences importantes.
L'implmentation des compteurs haute rsolution temporelle a t ajoute pour
l'architecture x86 depuis la version 2.6.20. L'architecture de base avait t rajoute
dans le noyau Linux depuis la version 2.6.18. On peut rendre fonctionnel ce systme
depuis le menu de configuration de la compilation du noyau. Le travail de
dveloppement continu d'tre fait dans le patch-RT.
5. Xenomai
Pour implmenter le temps rel avec des systmes de type GNU/Linux, on peut faire
fonctionner deux noyaux cte--cte (on parle de systmes co-noyaux). L'approche
consiste ajouter un noyau (ou micro-noyau ) ct d'un noyau Linux classique.
C'est l'approche qui est faite par Xenomai. Le micro-noyau s'occupe de la gestion des
interruptions matrielles, fait fonctionner des tches temps-relles, apporte des
fonctionnalits de gestion du temps...
5.1. Historique
On situe gnralement 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-rels propritaires vers une solution Open Source (systme de type
GNU/Linux). Un des points critiques de la migration est de continuer garantir la
bonne tenue des chances (contrainte typique des systmes temps-rels).
C'est en 2002 que Xenomai a t port sur Adeos. Ceci a permis d'affranchir Xenomai
des dpendances lis aux diffrents systmes d'exploitations existants et d'amliorer
la prdiction 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-rel libre. Le code source de RTAI et la partie
spcifique Xenomai (qui s'appelait alors RTAI/fusion) sont rests relativement
indpendants. C'est aprs ce regroupement, et au cours des dveloppements qui ont
suivi, que le projet Xenomai a gagn sa capacit d'tre port sur diffrentes
architectures matrielles.
En 2005, le projet Xenomai s'est spar du projet RTAI et a repris son indpendance.
cette date, le projet Xenomai a pris son nom actuel.
5 Adaptive Domain Environment for Operating Systems , dans la Bibliographie
31/104
5.2. Adeos
Adeos ( 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'accs une mme ressource physique pour plusieurs
systmes.
5.2.1. Les domaines

L'une des applications courantes de cette couche est le fonctionnement de deux
noyaux cte cte sur le mme matriel.
Pour rendre cela possible, Adeos introduit le concept de domaine . Gnralement,
un systme 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 comptition pour traiter des vnements externes (interruptions matrielles) ou
internes (exceptions, interruptions logicielles).
Un systme, cantonn dans un domaine , se dfinit un espace d'adressage priv et
des abstractions telles que les processus, les adresses virtuelles... Entre parenthses,
un tel systme n'est pas restreint son domaine s'il est capable de dtecter Adeos et
de l'utiliser comme intermdiaire. L'utilisation d'Adeos par un systme donn lui
permet de partager des ressources avec d'autres systmes.
Illustration 9 : Adeos et les domaines
1. Dans l'usage gnral, le systme contenu dans le domaine accde au matriel

sans aucune restriction. Tout se passe comme si Adeos n'tait pas prsent.
2. Adeos reoit le contrle du matriel lorsqu'une interruption matrielle ou
logicielle surgit. Le systme Adeos peut aussi accder au matriel pour ses
propres besoins.
3. Lorsque le systme d'exploitation n'a pas conscience de la prsence d'Adeos,
Adeos doit prparer l'environnement de traitement des interruptions pour le
systme sus-jacent. En particulier, il prsente la pile de faon ce que le
32/104
Les domaines - Les domaines
gestionnaire d'interruption du systme agisse correctement.

4. Lorsque le systme a connaissance de la prsence d'Adeos, il peut alors
demander avoir accs aux ressources des autres domaines, demander
changer la priorit sur son accs aux interruptions... La communication entre
Adeos et le systme devient bi-directionnelle.
5.2.2. Le pipeline d'interruption

Adeos supervise l'accs aux ressources par les diffrents domaines. Par exemple,
Adeos hirarchise l'accs aux interruptions en les distribuant travers une file
d'interruption .
Illustration 10 : Pipeline d'interruption et disposition des domaines
La notification d'une interruption est poste l'entre du pipeline. Elle parcourt

ensuite le pipeline. Les diffrents domaines sont placs les uns la suite des autres,
en fonction des priorits qui leurs ont t attribues. Le domaine ayant la plus haute
priorit reoit la notification en premier.
Chaque domaine dcide d'une action :
accepter l'interruption (accept)
L'interruption est vue par le systme contenu dans le domaine et elle est
traite.
ignorer l'interruption pour le moment (stall)
L'interruption n'est pas traite immdiatement par le domaine. Par exemple, le
domaine se protge de l'irruption d'interruptions pendant qu'il effectue un
traitement particulier.
se dfausser de l'interruption (discard)
L'interruption passe au domaine suivant comme si le systme n'en avait pas eu
connaissance.
terminer une interruption (terminate)
L'interruption n'est plus propage 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 contrle du CPU et donc, de faire les traitements
33/104
ncessaires.
Il a t voqu la possibilit que le systme soit dans l'incapacit de recevoir une
interruption. Pour viter que les notifications d'interruptions soient perdues pour le
domaine, elles sont enregistres dans une zone qui servent de tampon pour le
domaine. Cette zone est appele log d'interruption. Une fois que le systme 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-rel
5.3.1. L'utilisation d'Adeos

Xenomai repose sur le systme Adeos. Lors du patch du noyau, il est dfinit par
dfaut quatre domaines pour Adeos. Dans le premier domaine, le systme temps-rel
prend place (Xenomai utilise la dnomination de nucleus ). Dans le second
domaine, un systme de type GNU/Linux fonctionne. Les deux autres domaines ne
sont pas utiliss.
Le noyau Linux est de type GPOS6. Il est pratique d'avoir un tel noyau car il bnficie
d'un support matriel important (nombre de pilotes de priphriques). De plus, il
permet de faire fonctionner des tches Linux courantes. On a le bnfice d'un systme
polyvalent (GNU/Linux), utilis avec un systme spcifique pour le temps-rel
(Xenomai).
Illustration 11 : Xenomai et le noyau Linux
6 GPOS : General Purpose Operating System
34/104
L'utilisation d'Adeos - L'utilisation d'Adeos
Le schma 11 illustre les deux domaines (contenant respectivement Linux et

Xenomai), fonctionnant au dessus d'Adeos. On peut donc utiliser des applications
spcifiques pour chacun des domaines. Puisque le systme Adeos utilise une couche
d'abstraction matrielle, il est relativement indpendant du matriel qui est sous-
jacent.
Grce au mcanisme de pipeline d'interruption (dcrit au paragraphe 5.2.2.), Xenomai
(qui est dans le domaine primaire) reoit tout les vnements avant le noyau Linux
(qui se trouve dans le domaine secondaire). Xenomai peut donc traiter les
interruptions immdiatement, quel que soit l'tat du noyau Linux (mme si, par
exemple, le noyau utilise le mcanisme de masque du processeur pour cacher les
interruptions).
Xenomai peut aussi privilgier le contrle de ses fils d'excution, quels que soit le
domaine o ils rsident. Ceci permet de garantir des temps de latence infrieurs la
micro-seconde, quel que soit la tche mene par le noyau Linux.
Dans la figure 11, on observera que Adeos doit se situer entre la couche d'abstraction
matrielle et Xenomai. La majorit des requtes que doit traiter Adeos viennent donc
de cette couche. En pratique, les services ont t implments dans des fichiers qui
sont ajouts aux sources du noyau Linux au cours du patch7.
Les fonctions spcifiques qui sont implmentes commencent gnralement par le
prfixe rthal_ . Dans le cas des systmes de type ARM, il faut explorer les fichiers
kernel/xenomai/arch/generic/hal.c et arch/arm/xenomai/hal.c des sources
patches du noyau Linux.
5.3.2. L'architecture de Xenomai

Le micro-noyau de Xenomai ( nucleus ) est en fait une abstraction de noyau temps-
rel (RTOS) reposant sur :
des structures de donnes
des services (des mthodes)
des flags
Parmi les structures de donnes qui sont manipules par Xenomai, on peut retenir :
xnthread_t qui est l'abstraction de tche temps-rel, xnsynch_t qui est un
objet gnrique permettant de synchroniser des tches, xntimer_t qui est un
implmentation gnrique de compteur temporel.
Parmi les diffrents services qui sont proposs par Xenomai, il faut comprendre au
moins le pod et le regsitre .
Le pod (dnomm xnpod dans l'implmentation) est l'abstraction qui s'occupe du
management des tches temps-rel. C'est cette abstraction qui est responsable de la
cration et de la suppression des tches (des structures xnthread_t ), du
changement de la politique d'ordonnancement, de l'appel l'ordonnanceur... C'est un
des lments central du noyau temps-rel.
Le registre est un moyen de partager facilement les descripteurs d'objets. Lorsqu'un
7 En effet, Adeos (et donc, le systme Xenomai) repose sur l'application d'un patch sur les
sources du noyau Linux.
35/104
objet est cr, simultanment, une entre est cre dans un registre. Ensuite, tout
autre service qui veut utiliser l'objet utilise le nom symbolique (de l'objet) pour
retrouver l'entre correspondante dans le registre. Le nom de l'objet sert de cl
pour retrouver l'entre 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 donnes.
5.3.3. Les modes d'excution

Il est gnralement fait tat du mode d'excution primaire et secondaire. Le premier
traduit le fait que les fils d'excution s'excutent au dessus du domaine de plus forte
priorit (le domaine contenant Xenomai). Le second traduit le fait que les fils
d'excution s'excutent dans l'espace utilisateur courant (le domaine Linux).
5.3.3.1. La migration des fils d'excution

Xenomai drive ses threads (xnthread) de la structure de thread (task_struct)
implmente dans Linux. En fait, un processus se voit attacher une structure
particulire (appele real-time shadow ) lorsqu'elle fonctionne dans le domaine
primaire.
Une telle architecture permet une tche temps-rel d'tre ordonnance
indiffremment par l'un ou l'autre des domaines. C'est ce qui autorise la migration
des tches entre les domaines. Une tche temps-rel qui fait un appel systme ne
pouvant pas tre trait par Xenomai est migre dans le domaine Linux pour
rpondre sa demande. Elle reste dans le domaine correspondant pour le reste de
son excution (pour ne pas pnaliser la latence du systme par la charge apporte
lors de la migration de la tche) tant qu'elle ne fait pas un appel temps-rel.
Lorsqu'une tche temps-rel du domaine Xenomai s'excute au dessus du domaine
Linux, elle reste considre comme telle. En effet, les priorits des tches temps-rel
de Xenomai s'chelonnent entre 1 et 99. Dans le systme Linux, les tches peuvent
avoir une priorit s'chelonnant entre 1 et 139. Sachant que les tches courantes ont
une priorit comprise entre 100 et 139 et que les tches dont la priorit est infrieure
100 sont considres comme temps-rel. Cela permet d'avoir une correspondance
des priorits et garantie l'ordonnancement prioritaire. Toutefois, cela peut les
pnaliser puisqu'elles sont soumises aux latences du systme Linux.
Un autre des avantages de la rutilisation de la structure de thread Linux apparat lors
de la priode de dveloppement d'une l'application. Un processus temps-rel peut
continuer tre trac l'aide d'une application de dboguage, quel que soit le
domaine o il s'excute.
5.3.3.2. Le temps-rel dans le mode secondaire

Si une tche est considre comme temps-rel, il faut que sa priorit soit renforc
quel que soit son domaine d'excution. Par exemple, une tche s'excutant dans le
domaine primaire (donc, temps-rel) doit pouvoir tre prempt par une tche de
plus haute priorit s'excutant dans le domaine secondaire. Par contre, lors d'une
tentative d'accs au CPU, une tche non temps-rel (donc, pas connue par Xenomai)
doit toujours tre prempte au profit d'une tche temps-rel du premier domaine.
36/104
Le temps-rel dans le mode secondaire - Le temps-rel dans le mode secondaire
Toutefois, lorsque le second domaine ordonnance ses processus et dcide de celui qu'il
va excuter, toutes les tches (temps-rel ou non temps-rel) rentrent en
comptition. Il faut comprendre qu'une tche temps-rel dans le second domaine,
bien qu'ayant une priorit plus leve qu'une tche quelconque, devra rgulirement
laisser sa place pour l'excution d'autres tches. Le systme Linux conserve son
caractre de systme multi-tches.
Les tches doivent tre prservs des problmes d'inversion de priorit. Xenomai le
fait nativement, mais seul le noyau Linux patch avec PREEMPT_RT permet cette
protection. Il faut donc continuer vrifier les diffrents cas si l'on utilise un systme
Xenomai bas sur la branche principale du noyau Linux.
5.4. API temps-rel
5.4.1. Les Skins

Les applications industrielles embarqus ont gnralement demandes un effort de
dboguage et d'optimisation important avant d'atteindre leurs formes stables. Au sein
d'une entreprise, les personnes comptentes dans le domaine du temps-rel ne
peuvent pas forcment tre employes dans un processus de portage long et
contraignant. Les quipes de dveloppement ne sont pas prtes changer la base de
leurs applications : le changement d'API reprsente une charge de travail trop
importante (changement de nombreux appels de fonctions, modifications des objets
manipuls...).
Pourtant, bien que prsentant des diffrences subtiles, les objets ou les concepts qui
sont utiliss dans les API propritaires sont sensiblement quivalents (mutex, appels
systmes, tches de synchronisation, ordonnancement). Il a donc t cre des objets
gnriques dans l'environnement de Xenomai et des couches sont rajoutes qui
implmentent la grammaire ou les mcanismes spcifiques de chaque API. Ces
couches sont appeles skins et miment le comportement d'un certain nombre
d'APIs temps-rels (POSIX 1003.1b, pSOS+, RTAI, uITRON, VRTX, VxWorks).
Les skins se prsentent comme des modules noyau qui peuvent tre chargs au
besoin. On peut aussi dcider que ces fonctionnalits soient intgres dans le noyau
au moment de la compilation plutt que d'avoir des modules.
5.4.2. L'API native temps-rel

Xenomai propose sa propre API pour la ralisation d'applications temps-rel. Cette API
se veut relativement succincte et laisse au programmeur le choix d'agencer les
fonctionnalits de bases pour crer des mcanismes volus.
37/104
Illustration 12 : Appels systmes temps-rels depuis l'espace utilisateur et

l'espace noyau
Les appels systmes invoqus par les applications temps-rels dans l'espace
utilisateur sont redirigs vers le noyau depuis l'espace utilisateur grce une librairie
spcifique de Xenomai : libnative.so.
On peut crer des modules temps-rels qui font appels aux services du micro-noyau.
Cette approche, qui ressemble celle prconise par d'autres systme temps-rel
(RTAI, notamment), n'est pas privilgier. Il est prfrable d'avoir des applications
temps-rels, vitant ainsi que le noyau ne soit compltement bloqu (et impose un
redmarrage du systme) cause d'une erreur d'excution du module temps-rel.
Dans cette API, on fait appel aux services apports par le noyau temps-rel l'aide
d'appels systmes spcifiques. Parmi ces appels, on retrouve :
le management des tches temps-rel
Il existe un certain nombre d'appels systmes pour crer ou dtruire des
descripteurs de tches temps-rels. La cration et le dmarrage des tches est
indpendant ( 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 dtruire. Le lancement des traitements est alors
clairement indiqu l'endroit o l'opration doit tre effectue.
Il est possible d'introduire des mcanismes d'attentes entre les tches. On peut
aussi explicitement dclarer une tche comme tant priodique, ou lui imposer
un dlai d'attente. Il est possible qu'une tche fasse des appels
l'ordonnanceur, pour elle mme ou pour une autre tche. On peut donc
imaginer un modle o une tche principale coordonne l'activit de toutes les
38/104
L'API native temps-rel - L'API native temps-rel
autres.
la gestion du temps
Les principaux mcanismes consistent grer 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 systme compte
le temps en ticks ou en unit de temps (nano-seconde, par exemple). L'API
propose alors des mthodes de conversions.
Le fait de ne compter qu'en ticks systme permet de rduire la charge en
ce qui concerne la conversion des donnes brutes en units comprhensibles
un niveau macroscopique. Par contre, il faut valuer l'effet des masquages
d'interruptions et l'irrgularit apporte la base de mesure.
la synchronisation entre tches
Dans cette section, il faut prendre en compte les mthodes qui permettent
d'utiliser des mutexs , des smaphores . Ce sont essentiellement les
appels pour crer l'objet, le retrouver depuis son nom symbolique, le dtruire et
effectuer les oprations de bases de cet objet (acqurir ou librer, dans le cas
des mutex ).
la communication entre tches
La communication entre les tches peut se faire par le biais de files de
messages, de tubes inter-processus (IPC) ou de portions de mmoire
partages.
Le premier mcanisme est gnralement utilis au sein d'un mme programme
qui est multi-thread. Le second est utilise entre deux (ou plus) processus
indpendant qui ne se connaissent pas ncessairement au moment du
dmarrage.
5.4.3. Real-Time Driver Model

RTDM est un skin spcifique pour la gestion des entres/sorties sur priphriques.
Par exemple, il permet de crer des modules ou des drivers de priphriques ayant
des contraintes temps-rel qui sont portables. En effet; les modules implments
utilisent une API commune.
39/104
40/104
Travail ralis
Portage et valuation de Xenomai sur une plateforme PC/104
1. Environnement de dveloppement
Parce que le matriel et les performances du systme embarqu ne sont pas
suffisantes pour dvelopper les logiciels ncessaires (car, pas destines cet usage),
on choisit gnralement de dporter le dveloppement sur un ordinateur plus
puissant. Le choix au sein du centre de service eLiSe est de faire le dveloppement
sur un ordinateur de type PC. Ce systme hte, sur lequel j'ai effectu le
dveloppement du systme (rcupration des sources, paramtrage, compilation...),
fait fonctionner la version la plus jour de la distribution Ubuntu. De cette faon, il n'y
a pas de diffrences entre le type du systme hte et du systme cible (tout deux de
type Linux).
Pour effectuer le portage de Xenomai, j'ai du commencer par organiser mon
environnement de dveloppement. Ensuite, j'ai du apprendre utiliser des outils
spcifiques au dveloppement. Enfin, j'ai install les outils de compilation croise.
1.1. L'arborescence de travail

J'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'intrieur 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 compresses des fichiers
sources que j'ai utilis. Par exemple, on y retrouve l'archive du compilateur
croise. Ainsi, on conserve une trace des ressources utilises pour de futurs
dveloppements.
build/ l'intrieur 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 mmes commandes d'une fois sur l'autre, j'ai
fait un certains nombres de scripts Bash. J'ai dcid de les placer dans ce
dossier.
debug/ Pour le test de l'environnement de Xenomai, j'ai eu besoin de faire la
compilation croise de quelques applications de dboguage. J'ai donc plac les
excutables correspondants dans ce dossier.
images/ La compilation du noyau gnre beaucoup d'objets mais tous ne sont
pas utiles dans l'utilisation finale du systme. 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 systme de fichier selon la
norme du FHS et les fichiers utiles tous les types de systmes. On y retrouve,
par exemple, le fichier /etc/fstab, les fichiers de la libc, les fichiers de
priphriques).
sysapps/ Ce dossier contient les sources des applications intgres dans le
8 Voir dans la Bibliographie
42/104
L'arborescence de travail - L'arborescence de travail
systme. 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-rels.
tmp/ Traditionnellement, ce dossier contient des fichiers temporaires (tentatives
ou essais de compilations, dveloppements...).
Dans un premier temps, j'avais dcid 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 lies Xenomai ou leurs
versions standards ).
En fait, j'ai t amen faire plusieurs compilations d'un mme type de systme avec
des paramtres de compilation diffrents. J'ai donc chang de pratique. J'ai insr
trois sous-dossiers : Branches/, Tags/, Trunk/. Ces trois sous-dossiers sont
habituellement rencontrs dans les projets de dveloppement. Le dossier Branches/
me permettait de conserver plusieurs versions diffrentes. Le dossier Trunk/ du
dossier rootfs/ contenait une version du systme de fichier dont j'avais la certitude
que ses lments taient fonctionnels. Le dossier Trunk/ du dossier build/ contenait
les lments de la compilation actuellement mene.
1.2. Les outils
1.2.1. Logiciel de suivi de version : git

De faon mettre en place un dveloppement bas sur les dernires versions des
sources, il a t dcid d'utiliser le logiciel de suivi de version git 9. Ce logiciel permet
de faire une copie locale des fichiers depuis un dpt. En plus de copier l'arborescence
de fichiers du projet que l'on rcupre, 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 rgulirement, j'ai pu personnellement
crer des branches de dveloppement sur le PC hte.
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 apportes aux fichiers
sources, j'ai choisit de les suivre grce la fonction correspondante du
logiciel git.
Enfin, j'ai cr une branche spcifique depuis la version des sources Linux
2.6.28 pour appliquer une version de Xenomai patche. Ces patchs m'ont t
proposs au cours d'un change avec la mailing-list d'entraide de Xenomai.
1.2.2. Le systme d'information du centre de service

Dans le centre de service eLiSe, au sein duquel j'ai travaill, chaque personne dispose
9 Une prsentation dtaille 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
rseau et peuvent accder des ressources communes, disponibles sur un serveur. Le
serveur est appel gforge .
En plus de pouvoir rcuprer les donnes depuis le serveur (en faisant de la copie
tunnele par SSH), il a t mis en place un systme de montage de dossier par NFS.
Ainsi chaque ordinateur peut accder un dossier nomm partage dont le contenu
est sur le serveur.
1.2.3. Portail de collaboration : Trac

Trac est un outil de gestion de projet. Il comprend :
un wiki
Ce composant est utilis pour que tout le consultants crent une base de
connaissance. Ils remplissent les pages de faon collaborative. J'ai cr des
pages sur le Wiki, dans la section rserve Xenomai, dcrivant la marche
suivre pour mettre en place l'environnement de compilation, par exemple.
une systme 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 lments sans avoir les tlcharger sur la machine
de dveloppement.
un systme de billets
Trac un outil accessible de faon dcentralis. Bien que les donnes et le logiciel qui
servent de base l'architecture soient contenus sur le serveur gforge , les postes
du centre de service peuvent accder au portail grce un navigateur Internet.
44/104
Portail de collaboration : Trac - Portail de collaboration : Trac
Illustration 13 : Page d'accueil du portail Trac dans le navigateur Firefox
L'outil tant accessible depuis Internet, il comprend un systme d'authentification

avec mot de passe. Il est ainsi possible pour des clients de suivre l'avancement d'un
projet, depuis ce portail, de faon scurise.
La combinaison du Wiki et du logiciel de suivi de version est trs utile car elle permet
de conserver un historique des tches menes sur une plateforme donne. Au cours
des premiers mois, j'ai souvent utilis cet deux composants pour voir les oprations
qui avaient t menes sur la carte Viper. Je me suis souvent inspir des mthodes
utilises par le pass (pour la mise en place des outils de compilation croise, pour la
modification du script de dmarrage de la carte...).
1.3. Les outils de compilation croise
1.3.1. Contraintes
La compilation vers la carte Viper ncessite des outils capables de fonctionner sur le
PC hte, et capables de produire des binaires compatibles avec le matriel prsent sur
la carte : ce sont les outils de compilation croise (compilateur, diteur de liens...).
On notera que le compilateur doit tre assez rcent pour pouvoir supporter les options
de compilation lies au standard EABI. C'est au cours de la premire compilation de
Xenomai que ce point a t soulev. J'avais commenc par installer et utiliser les
outils fournis sur les Cds livrs avec la carte. Mais la version de cette chane de
compilation tait trop vieille et ne supportais pas les options lies EABI. Il a fallu
45/104
trouver la raison de l'chec de la compilation dans les messages de compilation, puis

faire une recherche et rcuprer 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
spcifique de Xenomai. Le fait d'activer cette fonctionnalit a, de nouveau, soulev
des problmes de compilation.
L'un des mainteneurs du projet Xenomai m'a indiqu que le problme tait d la
chane de compilation. Cette fois-ci, la version du compilateur tait trop rcente et
tait sensible certains paramtres. J'ai donc dcid de changer nouveau d'outils et
d'utiliser ceux qu'il me garantissait comme fonctionnels.
1.3.2. Dpaquetage
L'installation des outils est trs 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'environnement

Les logiciels sont dsormais prsents dans le dossier /usr/local/arm/arm-
2008q1/bin/. Pour pouvoir facilement les utiliser, j'ai modifi une variable
d'environnement du systme. Pour que tout les utilisateurs puissent avoir un accs
ces excutables, il faut modifier la variable PATH dans le fichier /etc/environment de
la faon suivante :
PATH="/usr/local/arm/arm-2008q1/bin:/usr/local/bin[...]"
J'ai rajout le chemin vers les fichiers excutables de la chane de compilation au

dbut de la variable PATH.
1.3.4. Tests de l'environnement

Si l'on veut vrifier la prise en compte de ces manipulations (aprs redmarrage du
systme), dans un terminal, on tape :
arm-none-linux-gnueabi-gcc --version
Cette ligne de commande doit normalement donner un aperu 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
excutable 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 excutables (noyau Linux, BusyBox) fonctionnent correctement permet
de valider le bon fonctionnement du compilateur, du bon droulement de l'dition de
lien sur la librairie C... On peut considrer qu'un excutable 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'amorage : RedBoot

Le chargeur d'amorage (ou bootloader ) est un logiciel de taille gnralement
faible qui se charge de vrifier le matriel prsent sur la carte et d'effectuer des
oprations simples de management. Il est aussi responsable du chargement du noyau,
et de fait, du systme. L'utilisation de bootloader est courante dans les systmes
embarqus. En effet, les plus petits systmes ne disposent gnralement pas de
BIOS. De plus, les chargeurs d'amorage sont gnralement configurables, plus
facilement qu'un BIOS.
Le chargeur d'amorage de la carte Viper (appel RedBoot) dispose de ces
fonctionnalits de base. Il possde aussi un ventail de fonctions plus volues
accessible depuis une invite de commande (management de la mmoire, gestion de
l'horloge...). Par exemple, RedBoot utilise un script pour effectuer le dmarrage du
systme. Ce script est ditable et personnalisable volont. Pour modifier le script de
dmarrage, on tape la commande dans l'invite de RedBoot :
RedBoot>fconfig
J'ai du apprendre utiliser cette fonctionnalit essentielle pour autoriser la

conservation des lments du systme (noyau et systme de fichier) de faon
dporte. Pour mieux apprhender cette fonctionnalit, j'ai fait des essais de
configurations mixtes (noyau dans la mmoire Flash, systme de fichier dport sur le
PC de dveloppement...) ; notamment, avec le prcdent noyau Linux qui avait t
port sur la carte.
Au cours de ces manipulations, j'ai appris que RedBoot, en commandant le dmarrage
du niyau, est responsable de certains comportements du systme GNU/Linux (choix
du priphrique servant de console, vitesses de transferts des donnes...).
Le chargeur d'amorage RedBoot est driv 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 Viper

La carte Viper ne possde pas d'cran ou de clavier puisque c'est un systme qui est
cens fonctionner en autonomie lorsqu'il est dploy dans un contexte industriel.
2.2.1. Liaison srie avec C-Kermit

La mthode de connexion habituelle est le raccordement du PC de dveloppement et
de la carte Viper par un cble srie spcifique dit : null-modem cable . Dans ce
cble, la pin d'envoi des donnes, l'une des extrmits, est relie la pin de
rception des donnes l'autre extrmit. Il permet deux ordinateurs de pouvoir
s'changer des donnes sans avoir besoin d'un modem entre ceux-ci. On peut vrifier
le cble avec un simple voltmtre.
Pour communiquer avec la carte, on dmarre 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 srie du logiciel RedBoot. La
communication par la liaison srie permet indiffremment :
de se connecter sur la console de RedBoot
d'obtenir les informations de la console de dmarrage du noyau Linux
de se connecter la carte Viper lorsqu'un terminal fonctionne sur l'un des ports
srie de celle-ci
L'avantage de cette connexion est la possibilit d'envoyer des caractres d'interruption
(du type Ctrl+C ). Entre parenthses, c'est ce caractre qui permet de notifier
l'interruption du script de dmarrage RedBoot et d'accder son invite de
commande.
J'ai malheureusement eu des problmes avec cette connexion. En effet, lorsque la
carte reste trop longtemps sous tension, il devenait impossible d'avoir des donnes
comprhensibles. Parfois, le logiciel C-Kermit n'affichait plus du tout de donnes en
provenance du port srie.
Pour trouver la cause de ce problme, j'ai adopt une approche top-down . J'ai
commenc par vrifier que les paramtres du programme (fonctionnant sur le PC)
taient bon : choix du port srie, format des donnes... L'apparition d'un flot de
caractres non comprhensibles m'a fait supposer un problmes de synchronisation ;
j'ai donc particulirement vrifi la vitesse de transmission des donnes. J'ai ensuite
vrifi l'tat du cble reliant les deux machines. Puis, tout les lments prcdents
tant corrects, j'ai observ ce port srie avec un oscilloscope. Je me suis auparavant
document pour comprendre comment les octets de donnes sont envoys sur une
liaison srie. J'ai dcouvert que la ligne de communication tombait quasiment au
mme niveau que la masse aprs 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 contrleur srie de la carte est endommag.
2.2.2. Liaison Ethernet et console Telnet

tant donn les problmes que j'ai pu avoir avec le port srie, j'ai dcid d'utiliser un
client Telnet depuis le PC hte, 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 contrleur Ethernet de la carte au lieu du contrleur de la

liaison srie. De plus, j'ai dcouvert qu'il tait aussi possible d'avoir accs la console
du chargeur d'amorage par cette mthode.
J'ai utilis deux configurations pour relier le PC la carte :
un cble Ethernet crois qui relie directement les cartes rseaux des deux
machines. Cette configuration ne dpend pas d'un matriel supplmentaire.
un concentrateur plac entre le PC et la carte ; les deux machines tant relies
cet appareil central par des cbles Ethernet droits.
Lorsque le systme ne dmarre pas (pas de noyau prsent, par exemple...), le
chargeur d'amorage reste en fonction et prsente son invite de commande. Il est
possible d'avoir cette invite de commande autrement que par la liaison srie. En effet,
le chargeur d'amorage se place en coute sur le port Ethernet. Je pouvais alors m'y
connecter depuis le PC de dveloppement 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 systme d'exploitation de la carte est dmarr, si un serveur Telnet

fonctionne il est possible de s'y connecter par la liaison Ethernet. Si ce serveur a t
configur par dfaut, 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 dveloppement :
telnet 192.168.0.118
La connexion par Ethernet prsente un dfaut majeur : on ne peut pas avoir accs
aux informations de la console noyau au cours du dmarrage. En effet, le noyau est
capable d'afficher les informations de dmarrage sur un port srie car il charge un
minimum de support pour une liaison de ce type. La mme chose ne peut tre faite
avec le port Ethernet, ce qui ncessiterait de charger toute la pile rseau au pralable.
Entre le moment o RedBoot passe la main au dmarrage du noyau et le moment o
le systme est pleinement oprationnel, il n'y a aucun programme en coute sur le
port Ethernet.
2.3. Configuration de dmarrage
2.3.1. Le chargement du noyau par TFTP

Plutt que de flasher la mmoire de la carte chaque nouvelle compilation du noyau,
j'ai dcid d'utiliser la capacit du chargeur d'amorage rcuprer des fichiers
depuis un poste distant par le protocole TFTP. On gagne ainsi le temps ncessaire la
49/104
procdure de copie sur la mmoire Flash de la machine. De plus, la mmoire Flash est
limite en terme de nombre de recopies. On vite donc d'user prmaturment la puce
mmoire.
J'ai choisi de le recopier en grande partie le script de dmarrage qui tait prsent
l'origine sur la carte Viper. J'ai modifi deux lignes de faon rendre la procdure
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 premire ligne permet au chargeur d'amorage de paramtrer les connexions

rseaux. Le fait d'attribuer une adresse IP la carte permet RedBoot de dduire le
rseau associ et le masque de sous-rseau. Une fois la configuration rseau
effective, il peut aller tlcharger (avec la directive load ) le fichier spcifi sur le
serveur TFTP se situant sur la machine dont l'adresse IP est donne. Il place les
donnes l'adresse mmoire indiqu dans l'alias FREEMEMLO .
2.3.2. Le montage du systme de fichier par NFS

Pour les mmes raisons (rapidit de mise jour du systme de fichier sur la cible...),
j'ai dcid de conserver l'image du systme de fichier sur la machine hte et de
monter ce systme de fichier grce au protocole NFS.
Il existe un autre avantage li la conservation du systme de fichier sur la machine
de dveloppement : il y a la possibilit de modifier les fichiers en cours de
fonctionnement. J'ai utilis cette fonctionnalit pendant le dveloppement des
applications. Je menais la compilation sur le PC hte puis je plaais le code compil
dans l'image du systme de fichier pendant son fonctionnement. Cela le rendait
immdiatement disponible au systme Linux fonctionnant sur la Viper, sans que je
sois oblig de flasher la mmoire et de redmarrer le systme.
Pour commencer, j'ai du vrifier que la capacit de montage du systme de fichier par
NFS tait active dans la configuration du noyau Linux. Ensuite, j'ai modifi le script
de dmarrage de RedBoot. Pour simplifier la modification du script en lui-mme, j'ai
dfinis un alias qui comporte la ligne de paramtres 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 reoit cette ligne de paramtres lorsque le script de
dmarrage excute la commande :
RedBoot>exec -c %{cmdlinenfs}
J'ai construit la chane de paramtres en me basant sur une prcdente chane de

paramtres dfinie dans RedBoot. J'ai aussi directement regard les explications qui
sont donnes dans le fichier kernel-parameters.txt, fournis avec le noyau Linux.
50/104
Cration du systme de fichier - Cration du systme de fichier
3. Cration du systme de fichier
3.1. Motivations
Au cours des premiers tests, je devais normalement rutiliser un systme de fichier
existant. Malheureusement, ce systme de fichier a t cr de faon autoriser
seulement des sessions utilisateurs avec mot de passe. Les mots de passe n'taient
pas ceux traditionnellement utiliss au sein du centre eLiSe ou fixs par le
constructeur de la carte.
Pour contourner ce problme, j'ai tent de passer des arguments au noyau. Pour cela,
j'ai modifi la chane de paramtres passe au noyau dans le script de dmarrage de
RedBoot. Par exemple, j'ai tent de passer l'argument -S pour faire initialiser le
systme en mode utilisateur unique. J'ai dcouvert que cette option ne permet pas de
dbloquer le systme. En effet, le systme de fichier tait issus d'un distribution
Debian modifie. Dans les distributions de ce type, le fait de passer l'argument -S
sous-entend que l'utilisateur unique est l'administrateur du systme ; il est tout de
mme demand le mot de passe de ce super-utilisateur.
J'ai aussi tent de donner directement le chemin de la premire application lancer
grce au paramtre init . J'avais donc un alias du type :
RedBoot>alias cmdline="init=/bin/sh"
Dans ce cas, l'application doit effectivement dmarrer mais elle ne se place pas en
attente sur le port srie. Il n'est donc pas possible d'avoir un environnement de travail
depuis l'interprteur de commande.
Enfin, j'ai tent de faire dmarre l'application getty de la mme faon que
prcdemment (en donnant le chemin vers cet excutable). Cette application sert
d'intermdiaire : elle se place en coute sur le port srie et est cens dmarrer un
interprteur de commande quand elle dtecte une connexion. En fait, il est d'abord
fait appel sulogin (qui se charge de grer l'authentification de l'utilisateur) avant
de dmarrer un interprteur de commande.
J'ai dcouvert 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 russi passer outre cette protection par mot de passe. En accord
avec mon encadrant, il a t dcid de crer entirement un systme de fichier. Ce
choix a t fait pour contrer le problme mais il se rvle, dans le cadre de ma
formation, que c'est une dmarche instructive pour la comprhension globale d'un
systme. De plus, dans le cadre des systmes embarqus, le fait de crer soi-mme
le systme de fichier permet de s'assurer que l'on garde des proportions acceptables
en terme de taille mmoire. J'ai fait cela en suivant diffrentes dmarches dcrites
dans Building Embedded Linux Systems ou dans Linux From Scratch 10 (LFS).
10 Voir dans la Bibliographie
51/104
Une autre raison qui conforte dans la cration d'une nouvelle arborescence de fichier
est la capacit maintenir et finement adapter le systme 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 FHS

Selon les directives du Filesystem Hierarchy Standard , un certain nombre de
dossiers doivent tre prsent dans un systme 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 systme en ayant
le mme type de pr-supposs.
Pour les personnes qui connaissent les systmes de type GNU/Linux, on retrouve
l'arborescence de base de ces systmes. Dans la liste suivante, j'ai dtaill les dossier
que j'ai du peupler et dont l'architecture des sous-dossiers et des fichiers a t
particulirement travaill au cours du stage.
bin/ est le dossier qui contient les commandes essentielles au systme. 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
prsents. J'ai essentiellement vrifi la prsence 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 ncessaires au
dmarrage. 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 systme en totale autonomie sur la carte Viper.
dev/ est le dossier qui contient les fichiers de priphriques. Je l'ai peupl de
faon statique (sans utilisation du logiciel udev) pour qu'il contienne les fichiers
de priphriques usuels et ceux dont j'avais besoin pour accder au matriel
prsent sur la carte Viper.
etc/, ce dossier contient les fichier de configuration du systme et des
applications. J'y ai mis les diffrents scripts qui composent le systme de
dmarrage 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 systme. 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 croises.
root/ est le dossier personnel de l'administrateur systme. C'est un dossier
optionnel selon les directives du FHS mais que j'ai rajout puisque j'ai cr ce
compte unique dans le systme.
sbin/ est le dossier qui contient les applications ncessaires au systme et/ou
utilises pas l'administrateur du systme. Il est ncessaire de crer ce dossier
(au mme 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 utilises par les utilisateurs courant. J'y ai
plac certaines des applications que j'ai compil pour la Viper ; en particulier les
applications de dboguage (gdbserver et strace).
var/, c'est dans ce dossier que prennent place des fichiers susceptibles d'tre
modifis par le fonctionnement des applications. En particulier, j'y trouvais le
fichier qui sert de log d'erreur pour le systme.
Les dossiers media/, mnt/, opt/ et srv/ ne sont pas dcrit car je ne les ai pas utiliss
au cours de l'tude.
Puisque j'utilisais un noyau Linux, il a t ncessaire de rajouter deux dossiers. Ces
dossiers sont des points de montage pour des systmes de fichiers virtuels. Ils
permettent de faire l'interface entre les programmes (ou les utilisateurs) et le noyau.
Ce sont :
proc/ Ce systme de fichier virtuel recense les informations du systme
(numro de version du noyau, matriel, accs aux descripteurs de tches...)
sys/ Ce systme de fichier virtuel a sensiblement le mme rle que le
prcdent. Toutefois, il possde une prsentation du matriel de faon
hirarchique qui est plus comprhensible.
3.2.2. Les fichiers de priphriques

Le livre Building Embedded Systems rappelle qu'un certain nombre de nuds
doivent tre prsents dans le systme de fichier. L'ouvrage rappelle aussi que les
numros majeurs et mineurs ncessaires pour la cration des fichiers de
priphriques 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
priphriques suivant :
console : interface d'affichage des informations du noyau
mem : interface avec la mmoire du systme
null : priphrique virtuel dont l'criture est toujours possible
random : priphrique de gnration de valeur alatoire
zero : priphrique virtuel dont la lecture est toujours possible
Parmi les fichiers basiques, j'ai d ajouter ceux utiliss par les consoles (dnomms
tty*). En plus des consoles, puisque la communication avec la carte s'est faite dans
un premier temps par la liaison srie, j'ai cr les fichiers correspondants aux consoles
sries (dnomms ttyS*). tant donn que la commande pour crer ces fichiers est
quasi identique, j'ai dcid d'automatiser ce processus et de crer 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 numros mineurs au sein de la boucle for . Selon que le
numro mineur est infrieur (pour les terminaux) ou suprieur (pour les terminaux
srie) 64, je modifie l'indice qui apparat la suite de la chane de caractres
tty .
J'ai du aussi crer un dossier /dev/pts/ qui est mont au cours du dmarrage. Il
permet de crer des pseudo-terminaux. Les pseudo-terminaux tant des programmes
qui simulent le fait que l'on se connecte un terminal. Il tait ncessaire de crer et
de monter ce dossier au dmarrage, en particulier pour pouvoir utiliser Telnet.
Enfin, j'ai cr quatres liens symboliques dans le dossier /dev/. Un programme, au
cours de son excution, doit pouvoir accder son entre standard et ses sorties
(standard et erreur). Ainsi, j'ai d'abord commenc par crer /dev/fd qui est un lien
symbolique vers /proc/self/fd, puis j'ai rajout les liens vers les descripteurs de
fichiers usuels : entre standard (stdin), sortie standard (stdout), sortie d'erreur
(stderr). J'ai rajout ces oprations dans le script prcdent 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. Applications
Un certain nombre d'applications sont absolument ncessaires pour faire fonctionner
un systme GNU/Linux.
3.3.1. SysVinit
Les systmes de type GNU/Linux utilisent gnralement le systme de dmarrage dit
SysVinit (comprendre System V init , en rapport avec l'apparition de ce
systme dans la version 5 de Unix distribue par AT&T). Particulirement, la
procdure de dmarrage ncessite la prsence de l'application (init). D'autres outils
sont aussi utiliss pour grer l'extinction du systme.
54/104
SysVinit - SysVinit
J'ai commenc par rcuprer les sources de ce systme. Puis, j'ai effectu la
compilation croise de toutes les applications composant le systme 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 systme embarqu, je n'ai pas install la
documentation associe aux programmes. Pour cela, j'ai parcouru le fichier Makefile
pour trouver les oprations correspondant l'installation des pages du manuel et les
commenter pour qu'elles ne soient pas excutes. Ceci est possible car le fichier a
vraisemblablement t rdig la main (il n'est pas issu d'une gnration
automatique). Il reste clair et comprhensible. 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 commentes, j'ai install les programmes dans le futur systme de
fichier de la carte (grce l'option ROOT). J'ai donn en paramtres le numro
d'identifiant et le numro du groupe de rfrence de mon identit sur le PC de
dveloppement. 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
dveloppement.
make BIN_OWNER="$(id -un)" BIN_GROUP="$(id -gn)" \

>ROOT=~/xenomai/rootfs install
3.3.2. BusyBox
Les systmes embarqus disposent gnralement de peu de mmoire ; que ce soit de
la mmoire vive (utile au cours du fonctionnement) ou de la mmoire Flash (pour la
sauvegarde des donnes lorsque le systme est hors tension). Pour donner un ordre
d'ide, la carte que j'ai utilis au cours de mon stage possde 64Mo de SRAM et 32Mo
de Flash11.
Pour rpondre ces contraintes, il a t dvelopp le logiciel BusyBox. Il regroupe
dans un seul excutable une grande majorit des commandes usuelles (cat, rm, ls...)
qui composent la suite de logiciels appele GNU Core Utilities.
Plutt que de compiler le paquet coreutils, il a t choisit d'utiliser cette application.
11 Un prsentation dtaille la carte Viper est faite en page 80, en Annexe
55/104
C'est pour cela que j'ai rcupr les sources de ce logiciel avec git :
cd ~/xenomai/sysapps
git clone git://busybox.net/busybox.git
Il faut introduire le fait que BusyBox implmente une version simplifi de init.
Malheureusement, dans une premire version de mon systme de fichier, je n'ai pas
russit faire fonctionner cette implmentation de faon ce que les scripts de
dmarrage soient excuts. Des recherches sur Internet ont souleves que ce
problme tait courant : l'application BusyBox semble n'utiliser que le fichier
/etc/inittab et n'excute pas les scripts qui peuvent apparatre dans ce fichier.
Hors, suite au problme de connexion srie12, j'avais besoin que le processus init soit
capable de configurer les interfaces rseau et de dmarrer un serveur Telnet, ce qu'il
ne faisait pas.
J'ai donc dcid d'utiliser SysVinit pour le dmarrage et BusyBox pour les autres
applications. J'ai donc d prter attention la configuration de compilation de
BusyBox. J'ai commenc par appliquer la configuration par dfaut. Ensuite, j'ai
recens les applications prsentes dans SysVinit. Finalement, j'ai configur BusyBox
de faon ce que les diffrents liens qui auraient pu entrer en conflit ne soient pas
crs.
Pour appliquer la configuration par dfaut, il faut donner la cible defconfig
make. Le reste de modifications se fait de manire 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 faon ce que les
objets compils soient installs dans le squelette de l'arborescence de fichier systme
(grce l'option CONFIG_PREFIX) :
make CROSS_COMPILE=gnu-none-linux-gnueabi- ARCH=arm \

>CONFIG_PREFIX=~/xenomai/rootfs install
Une fois ces oprations termins, j'ai pu vrifier qu'il n'a t cr qu'un seul
excutable (qui a t plac dans le dossier /bin/). Toutes les autres commandes sont
en fait des liens symboliques vers cet excutable :
12 Voir 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. Dmarrage
3.4.1. Le choix du systme rc

La procdure de dmarrage des systmes GNU/Linux repose sur le programme init
et une architecture de scripts de dmarrage. Le programme init est le premier
programme tre invoqu par le noyau. Ce programme va lire le fichier de dmarrage
/etc/inittab dans lequel apparat diffrentes rgles. Ces rgles rgissent le
lancement d'applications ou l'excution de scripts.
Il existe essentiellement deux systmes de dmarrage. Le premier, dit SysVinit, se
retrouve dans les distributions Linux courantes (Ubuntu, Debian, Fedora, OpenSuse)
avec plus ou moins de variations. Le deuxime est dit systme rc est plutt
originaire des systmes de type BSD13 .
J'ai tent plusieurs fois de mettre en place un systme de dmarrage du premier type,
parce que je pensais utiliser la distribution Ubuntu sur laquelle je travaillais. Je
pensais copier systme existant et le simplifier pour qu'il rponde 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 dmarrage diffrents de la norme SysVinit et pour lequel il est difficile
d'avoir des informations sur Internet.
J'ai donc pens crer entirement le systme pour la carte en simplement en copiant
l'esprit du dmarrage de SysVinit. Je me suis bas sur des distributions qui taient
plus respectueuses de la norme : OpenSuse ou Fedora, par exemple. Le problme de
ces distributions est la complexit inhrente l'accumulation des annes de
dveloppement. J'avais donc du mal faire ressortir les commandes ncessaires de
celles plus optionnelles. Pour illustrer le degr de complexit des architectures de
dmarrage, il faut savoir que les distributions cites prcdemment proposent
gnralement un logiciel pour manager les scripts de dmarrage.
J'ai finalement opt pour le deuxime systme de dmarrage qui est plus compact et
plus simple. Je me suis bas sur les informations donnes dans le manuel de
prsentation de la distribution Slackware. En effet, cette distribution Linux implmente
un systme de dmarrage 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
13 BSD : Berkeley Software Distribution. Distribution historique dveloppe au sein de

l'universit de Berkeley depuis le systme UNIX
14 LFS : Linux From Scratch. Distribution minimale dvelopper soi-mme.
57/104
crer les diffrents scripts.
3.4.2. Les sessions utilisateurs

Bien que les systmes embraqus ne soient pas des systmes interactifs avec des
utilisateurs, j'ai trouv qu'il serait intressant de configurer au moins un compte : le
compte du super-utilisateur. De cette manire, l'ouverture de session, un mot de
passe est demand et protge l'accs au systme.
La mise en place des sessions utilisateurs repose sur la prsence 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 dveloppement. J'ai supprim de nombreux
comptes et groupes qui n'taient pas utiles pour le systme que je mettais en place.
Par exemple, sur les distributions Ubuntu, il est dfinit un groupe ayant la possibilit
de crer des tches priodiques (dmarres priodiquement par le dmon cron ).
De cette faon, seuls les utilisateurs qui appartiennent ce groupe peuvent ajouter
des tches priodiques dans le pool du dmon. Toutefois, cette fonctionnalit
n'tant pas prsente et pas utile sur le systme, 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 dmarr le systme sans le systme de comptes utilisateurs
3. j'ai ajout le mot de passe de l'administrateur en utilisant la commande passwd
3.4.3. Le serveur inetd

Le serveur inetd est couramment appel le super-serveur . Il permet de remplacer
l'coute de tous les serveurs sur un systme disposant de peu de ressources. En effet,
il se place en coute sur tout les ports de la machine. C'est seulement lorsqu'une
requte arrive sur l'un des ports qu'il dmarre le serveur correspondant pour rpondre
la demande.
Dans la logique d'un systme embarqu (donc, disposant de peu de ressources), j'ai
dcid de mettre en place une telle architecture. Pour cela, j'ai utilis l'implmentation
du serveur inetd par BusyBox.
Le serveur inetd ne dmarre en fait que les serveurs spcifis dans un fichier de
configuration appel inetd.conf. Dans ce fichier, il est prcis :
le type de service (ce qui va dclarer le numro du port d'coute par dfaut)
le type de donnes changs
le protocole de communication utilis
la manire dont doit se comporter le serveur la rception d'une requte
le chemin vers l'excutable du serveur
la ligne de paramtre 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 chane de paramtre 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 faon suivante : il dcide de mimer l'excution du programme dont il
reoit le nom comme premier argument. Donc, selon la rdaction que j'ai faite du
fichier, la ligne de commande suivante est excute (aprs remplacement du lien par
l'excutable point) et prend tout son sens :
busybox telnetd -i
3.4.4. Le serveur Telnet

L'implmentation simplifie du serveur Telnet par BusyBox ncessite :
la prsence du dossier /dev/pts/ (comme indiqu au point 3.2.2.)
le montage des pseudo-terminaux dans ce dossier
le fichier de priphrique /dev/ptmx
Ces ncessits n'apparaissent ni dans les pages du manuel de cette application ni
dans dans celles de BusyBox. Au dpart, je n'avais cr aucun de ces lments et je
n'arrivais donc pas faire fonctionner le serveur Telnet. J'ai du chercher sur Internet
quel tait le problme. En fait, j'ai trouv la solution indirectement, en cherchant une
explication sur la notion de pseudo-terminal.
Illustration 14 : Pseudo-terminal lors d'une connexion

Telnet entre de deux machines
Lorsqu'un client Telnet envoi une requte un serveur Telnet, la communication se

fait par un rseau de type Ethernet. Le serveur possde 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
Telnet lance le programme responsable de cette tche. Le programme qui initie les
sessions utilisateurs (identification, puis lancement d'un interprteur de commande)
s'appelle getty. Lorsque cet outil dmarre, il s'attache une interface lui donnant
l'impression qu'il est raccord un terminal srie. En l'occurrence, il tente d'ouvrir le
priphrique raccord au fichier /dev/ptmx.
Comme le montre le schma 14, la notion de pseudo-terminal apparat dans le
mcanisme qui relie le priphrique ouvert par le programme getty (/dev/ptmx) au
descripteur de fichier dtenu 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 rseau Ethernet.
Une fois que j'ai dcouvert cette ncessit, j'ai rajout le dossier et le fichier dans le
dossier /dev/. J'ai aussi rajout, dans l'un des scripts de dmarrage que j'ai crit, une
opration analogue :
mount -t devpts devpts /dev/pts
l'instar du montage du systme de fichier /proc/, j'ai dcouvert que le paramtre

indiquant le priphrique source (dans ce cas, le deuxime devpts ) est ignor par
la commande mount. Toutefois, il est plus intressant de donner le nom devpts
plutt que none , s'il la commande se termine en erreur et qu'un message est
affich dans la console du systme.
4. Portage de Xenomai
4.1. Manipulations sur le noyau Linux
4.1.1. Patch du noyau

Xenomai se prsente sous la forme d'un patch de noyau Linux. Dans ce sens, j'ai
excut le script de prparation sur le dossier contenant les sources du noyau Linux.
Cette opration est dtaille dans un fichier (README.INSTALL) la base de l'arbre des
sources de Xenomai. J'ai adapt la commande de faon ce que l'architecture du
systme 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 paramtres :

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 prparatoire, 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 appliqus depuis cette
version introduisent trop de diffrences dans les fichiers sources, et l'application du
patch se termine en erreur.
On notera que le patch se prsente comme un fichier texte qui rpertorie 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 rptition du symbole
@ . Les lignes qui sont ajoutes sont prcdes du symbole + tandis que celles
qui sont enleves sont prcdes du symbole - . Les autres lignes de codes sont la
pour fournir un contexte.
Une bonne pratique pour vrifier l'application du patch tait de choisir un fichier
modifi et de cibler une modification effectue dans celui-ci. Il me suffisait ensuite de
regarder dans le fichier, la position indique, et de vrifier que les modifications
taient effectives.
4.1.2. Configuration du noyau

Avant 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 matrielle choisie, la manire d'une liste de paramtres. Cette opration
se fait avec la commande :
make viper_defconfig
Des fichiers par dfaut, pour les architectures ARM supportes par la communaut de
dveloppement du noyau Linux, se trouvent dans le dossier arch/arm/configs/ des
sources. Le prcdent responsable du centre eLiSe avait effectu le portage du noyau
Linux sur la carte Viper. Il avait donc cr le fichier de configuration par dfaut de la
carte et l'avait soumis la communaut.
J'ai du adapter la configuration du noyau ( partir de cette configuration par dfaut)
pour rpondre 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 frquence du processeur en fonction de la charge et la
mise hors tension des priphriques lorsqu'ils sont inactifs. Ces deux options sont
susceptibles d'induire des variations dans la frquence de rafraichissement des
horloges du systmes et donc, peuvent crer des latences non dsires. Ce point
particulier est soulev dans le fichier TROUBLESHOOTING, prsent dans les sources de
Xenomai.
4.1.3. Compilation du noyau

Le processus de compilation du noyau est une tche complexe, qui ncessite de
compiler de nombreux systmes (gestion de la mmoire, gestion du rseau...), eux-
mmes constitus de nombreux fichiers sources. Pour automatiser la compilation, une
arborescence de fichiers Makefile a t dvelopp au cours des annes. Ce systme
61/104
(couramment dnomm kbuild ) propose aussi un certains nombre de cibles (par

l'intermdiaire des Makefile ) pour aider le dveloppement du noyau. J'ai utilis
les fonctionnalits de ce systme au cours du processus de portage de Xenomai.
Par exemple, pour garder les sources du noyau aussi propres que possible au cours
des diffrentes compilations, j'ai systmatiquement pass une option make. Cette
option indique que les rsultats de compilation doivent mis dans un autre dossier que
le dossier contenant les sources. Ainsi, j'vitais que des objets issus d'une prcdente
compilation ne viennent poser des problmes 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 mene, j'utilisais l'une des cibles
du Makefile pour installer les modules dans le dossier contenant les objets compils.
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 systme de fichier
4.2.1. Mise en place du noyau

Une fois que la compilation est termine, il faudrait copier le noyau et les fichiers
importants sur le systme de fichier de la carte Viper. En fait, dans l'environnement de
dveloppement que j'ai utilis (o les objets taient conservs sur le PC hte), le
noyau tait disponible par le serveur TFTP et le systme de fichier par le serveur NFS.
Je m'occupais de copier les lments aux bons emplacements avant de lancer toute
opration sur la carte.
Dans un premier temps, je commenais par archiver les donnes dans un dossier
spcifique : le dossier images/. J'ai cr un script qui se chargeait de ces oprations.
Le script se prsentait de la manire 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 lments et suffixais (ou prfixais) les noms de faon ce qu'ils
soient rapidement reconnaissables. Le prfixe contenait le type de configuration
( dbg pour les versions d'valuation, patch pour les versions modifies,
trace lorsque le traceur du pipeline d'interruption tait activ) et la date
laquelle la compilation avait t mene.
Une fois que ces informations taient archives, je pouvait copier le dossier contenant
les modules dans le systme de fichier l'aide de la commande :
cp -a ~/xenomai/images/modules-2.6.28-xeno/* ~/xenomai/rootfs
Il faut noter la prsence 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,
particulirement pour les liens. Si un objet est utilis plusieurs endroits, il n'y a
gnralement pas de duplication de l'objet ; mais la cration de plusieurs liens
pointant vers cet unique objet.
4.2.2. Compilation des librairies

Le lancement d'un script configure depuis le dossier contenant les sources est un
processus typique de compilation d'applications. L'excution de ce script aboutit la
cration d'un fichier Makefile. C'est cette procdure qui est utilise pour compiler les
bibliothques de Xenomai. Le script accepte un certain nombre de paramtres. 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 paramtre --host sert de prfixe la recherche du

compilateur crois. Autrement dis, le script vrifie s'il existe des outils de compilation
croise 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 prsence de cette option. En effet, en explorant le script configure , j'ai vrifi
que la version de l'architecture est donne par dfaut.
Pour autoriser le dboguage des applications qui utilisent les librairies dynamiques, j'ai
souvent rajout le paramtre --enable-debug . Cette option conserve les
symboles de dboguage lors de la compilation des librairies. Elle me permettait
d'utiliser le dbogueur au sein des librairies lorsque l'application avait t li
dynamiquement ces librairies. Grce cette option, je pouvais faire du dboguage
pas--pas mme dans les fonctions des librairies.
Une fois que le Makefile a t gnr, 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 prcdente. En effet, l'option indique le dossier dans
lequel les lments seront installs dans le systme de fichier. L'option DESTDIR ,
dans la commande de make, indique le dossier de copie des lments. Dans notre
cas, c'est en modifiant ce paramtre que l'on pointe vers la racine du systme de
fichier de la carte Viper. Au final, les lments sont installs dans
$DESTDIR/usr/xenomai.
Pour une utilisation finale, sur un systme 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 console

Dans tout dveloppement d'applications, et en particulier dans le domaine des
systmes embarqus, il est important d'avoir un retour d'informations sur ce qui se
passe dans le systme au travers de la console. J'ai donc du m'assurer des points
suivant :
Prsence des fichiers de terminaux dans le systme de fichier (/dev/ttyS*)
64/104
Visualisation de la console - Visualisation de la console
Comportement de la console en fonction de la chane de paramtre passe au

noyau par dfaut (CONFIG_CMDLINE)
Comportement de la console en fonction de la chane de paramtre du script de
dmarrage de RedBoot (qui rcrit la chane de caractre prcdente)
Le visionnage des informations de la console est utile lors de la phase de dmarrage.
Il permet de suivre la dcouverte du matriel et le bon dmarrage 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 auprs d'Adeos, que le micro-noyau tait
charg, puis que les diffrents skins taient activs.
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 dernires instructions qui ont t excutes 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 dernires instructions
indiquait que les applications tentaient d'utiliser des instructions de calcul flottant
alors que le processeur XScale de la carte Viper ne possde pas d'unit de calcul de ce
type.
5.2. Critres d'valuations

Les connaissance acquises par la lecture des ouvrages ou des articles sur Xenomai et
les systmes temps-rels m'ont permis de mettre en avant des facteurs valuer.
5.2.1. Les situations propices aux latences

Pour crer des situations propices aux latences, il faut identifier les causes communes
de latences dans un systme. Les latences sont gnralement dues aux:
nombreuses interruptions matrielles et aux traitements associs
On peut crer ce genre de situation sur notre carte de test en la soumettant
une srie de ping depuis le PC de dveloppement.
65/104
nombreuses interruptions logicielles (exceptions)

On peut crer une charge factice qui gnre beaucoup d'accs mmoires (et
donc gnre des appels systmes dfaillants) en tapant une commande en
tche de fond, de la forme :
dd if=/dev/zero of=/dev/null
5.2.2. La mesure de la gigue

On peut valuer la gigue du systme par des solutions logicielles.
Elle repose sur des mesures faites par une tche priodique. Si une tche est dclare
priodique (de priode donne), alors deux mesures de temps devraient tre faites
avec un cart gal cette priode. Si la diffrence entre les deux valeurs mesurs par
les horloges est diffrente de la priode indique, il y a de la gigue dans le systme.
C'est la mthode qui est employe dans certains programmes de la suite de test
(dtaills dans la partie suivante).
5.3. La suite de tests

Parmi les lments qui sont installs 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 intrt de
lancer les applications depuis les scripts rside dans le lancement d'une commande
introduisant de la charge sur le systme, en plus de l'application. ventuellement, on
peut utiliser directement les binaires des applications depuis le dossier.
Voici un tableau rsumant les diffrentes applications :
Application Statut Description

clocktest fonctionnel Test des horloges systmes
cyclic fonctionnel Test des timers
irqbench non fonctionnel Environnement de mesure des latences
matrielles 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 frquence maximale de
migration entre domaines
switchtest fonctionnel valuation de la frquence maximale de
migration entre domaines en fonction de la
charge du systme
Les informations sur le fonctionnement des applications (dans les pages de manuel)
sont trs 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'intrt de chacune.
5.3.1. Clocktest
Dans un systme, il existe gnralement plusieurs compteurs qui servent d'horloge.
En particulier dans les systmes multi-processeurs, chaque CPU possde sa propre
horloge. Chaque horloge qui est redfinie doit rester synchronise avec une horloge
de rfrence. L'application clocktest permet de mesure l'cart une horloge et
l'horloge de rfrence, ainsi que l'cart entre les horloges de diffrents CPUs.
Cette application repose sur un thread qui est lanc de faon cyclique. D'une fois sur
l'autre, la priode de mesure est alatoire (comprise entre 1 et 1,1ms). Au cours
d'une priode, le thread relve diffrents couples de valeurs depuis l'horloge de
rfrence et l'horloge teste. En comparant la diffrence des valeurs fournies par ces
deux horloges, il se dfinit un instant de rfrence pour la priode de mesure. Cet
instant de rfrence est le moment o la phase (la diffrence) entre les deux horloges
est minimale.
Le programme dfinit alors :
le dcalage ( offset ) comme la diffrence entre les deux valeurs obtenues
(depuis l'horloge de rfrence et l'horloge teste) 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 dbut du

test mesur selon l'horloge de rfrence et celui mesur par l'horloge teste
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 diffrence entre les valeurs de deux horloges de

CPU diffrents
Le programme permet de tester deux types de compteurs :
CLOCK_REALTIME qui est un compteur donnant le temps depuis une rfrence
67/104
fixe. Cette rfrence est communment appele Epoch.

CLOCK_MONOTONIC qui est un compteur arbitraire que chaque application peut
dfinir et configurer.
5.3.2. Cyclic
Une demande d'ordonnancement priodique de threads repose sur des compteurs (les
timers , en anglais). Le but de ce programme est de mesurer les latences lis ces
timers .
Pour cela, le programme cre un certain nombre de threads qui sont ordonnancs par
Xenomai. Une fois que ces threads sont dmarrs, la tche main se contente
d'afficher les statistiques des threads au minimum toutes les 10000s (il y a un appel
la fonction usleep).
Chacun des threads, lorsqu'il est cr, utilise la mme routine. Cette routine repose
principalement sur une boucle. Pendant la priode o le main est en sommeil, les
threads ont le temps d'effectuer plusieurs boucles. Pendant ces boucles, ils font la
diffrence entre une mesure du compteur et une mesure prcdente du compteur.
Une fois cette mesure collecte, ils mettent jour leurs statistiques : la latence
minimale, actuelle, moyenne et maximale.
L'application donne une ligne d'en-tte. Cet en-tte 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 (prt
tre excutes), moyenns sur 1, 5 et 15 minutes. Le quatrime champ reprsente le
nombre d'entits (processus ou thread) dans l'tat RUNNING ou UNINTERRUPTIBLE,
rapport sur le nombre d'entits prsent dans le systme. Le dernier champ est le PID
du dernier processus dmarr.
Le programme prsente pour chacun des threads un certain nombre
d'informations : le numro du thread dans l'application (ainsi que son TID15, au niveau
systme), la priorit pour le systme Xenomai, le compteur interne de la boucle active
et la latence minimale, actuelle, moyenne et maximale.
5.3.3. Klatency
Pour faire fonctionner cette application, il est gnralement ncessaire de charger un
module noyau spcifique (la ncessit d'insrer le module dpend du choix qui a t
fait la compilation). On insre le module en utilisant la commande modprobe :
modprobe xeno_klat
Pour vrifier 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 dpendances des modules. En effet, les lignes de ce fichier
donnent (entre autres informations) le nom du module (le premier champ), le nom du
15 TID : Thread ID. Dans un programme non multi-thread, le TID est identique au PID. Dans
le cas inverse, chaque thread d'une mme application possde un identifiant unique (TID) et
partagent le PID de l'application.
68/104
Klatency - Klatency
module dont il dpend (le quatrime champ) et l'tat (l'avant dernier champ).
Le principe de ce test est de mesurer les latences pour une tche priodique de 100s
fonctionnant en mode noyau.
5.3.4. Latency
Ce programme est crit en utilisant l'API native Xenomai. Il a pour but de mesurer les
latences d'excution de faon logicielle.
Le programme main a pour seule fonction de crer et de dmarrer deux tches. La
premire s'occupe de la mesure des latences et ne fait pas d'appels des fonctions de
la libc standard. Ainsi, elle reste continuellement ordonnance par Xenomai. La
seconde qui s'occupe de l'affichage voit ncessairement ses contraintes de priodicit
relches.
Puisque la tche d'affichage n'a pas de priodicit, mais effectue ses activits en
synchronisation avec la tche de mesure grce un smaphore, la tche de mesure
peut effectuer plusieurs mesures lors d'une priode d'affichage. Donc, les lignes
commenant par RTD (Real Time Data) affichent :
la gigue minimale sur une priode d'affichage
la gigue maximale sur une priode d'affichage
la gigue minimale sur la dure du test
la gigue maximale sur la dure du test
la gigue moyenne sur la dure du test
Le programme insre parfois une ligne commenant par RTT (Real Time Task) donnant
un rappel de l'activit en cours. Cette ligne comprend une indication du temps
d'excution de la tche depuis le dbut du test.
La tche de mesure est cens faire des mesures avec la priodicit indiqu, pendant
une seconde. Lorsque la seconde est passe, 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 smaphore prvient la tche d'affichage. Le cycle recommence
par la r-initialisation des valeurs minimale et maximale de gigue et le nombre de
dpassements.
Si la tche met plus que la dure de la priode pour complter sa mesure, elle
manque un (ou plusieurs) point de libration priodique. Le nombre de points de
librations manqus peut tre comptabilis (grce l'appel rt_task_wait_period).
Lorsque ce cas se prsente, le nombre de cycles manqus est comptabilis et la tche
tente de se recaler avec le prochain point de libration.
5.4. Rsultats
5.4.1. Commentaires critique

J'ai finalement dcid de ne pas utiliser tout les tests qui sont prsents dans la suite.
Par exemple, je n'ai pas utilis l'application cyclic . Le code de cette application est
69/104
issus d'une prcdente application qui permettait le test des compteurs haute
rsolution. 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 opration : elle se charge aussi de faire plusieurs traitements sur les
donnes. De plus, l'introduction d'une diffrence entre les priodes des threads pose
question. Il serait plus logique d'avoir des threads de priorits diffrentes. Une
situation de concurrence de l'accs au processeur devrait tre pris en charge par
l'ordonnanceur et ne pas tre vite dans l'implmentation du test.
5.4.2. Analyse des mesures de clocktest

L'affichage des rsultats se prsente de la faon 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 -5s et -6,5s.
Dans le cas du test de l'horloge CLOCK_MONOTONIC, j'ai obtenu des offset oscillant
entre 11646669,0s et 11646670,5s.
Pour les deux cas, l'cart entre les deux mesures est de 1,5s. On a donc pas de
diffrence perceptible, une chelle macroscopique, de la mise jour des compteurs
et du dcalage des valeurs qui doit tre fait, au niveau noyau, pour ensuite les
prsenter 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 priode de la tche. La diminution de la priode de la tche fait, dans
un premier temps, diminuer la latence maximale rencontre. On notera avec le
deuxime et le troisime listing que la diminution de la latence minimale atteint un
palier lorsque la priode de la tche devient petite.
16 Les rsultats que je prsente 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 dpassements, on peut imaginer que la diffrence entre la dure
de la priode et la latence maximale constitue le temps restant pour l'excution de la
tche, de la manire suivante :
Illustration 15 : Latence maximale et temps d'excution
En ralit, cette premire impression est fausse : les dpassements de "release point"
interviennent mme lorsque l'on prsente un priode plus grande que le temps
restant valu (comme le montre le dernier listing).
La priorit de la tche n'a pas d'influence sur les latences rencontres. Dans le cas
prsent, cela s'explique par le fait que la tche s'excute sans aucune autre charge
pour le systme (la tche d'affichage tant bascul dans le domaine Linux).
5.5. Le traceur du pipeline

Pour comprendre la raison de certains blocages du systmes, j'ai compil Xenomai de
faon ce que le traceur du pipeline d'interruption soit prsent. 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. Dveloppement sous Xenomai
6.1. Ralisations
6.1.1. Les comptences acquises

J'ai choisis de dvelopper des applications utilisant l'API Xenomai. J'ai fais ce choix
pour crer et tudier des situations typiques des temps-rels sur le systme Xenomai
(ordonnancement concurrent, accs aux donnes de faon concurrentes...). Cela m'a
aussi permis de me perfectionner dans la matrise du langage de programmation C et
dans les outils de dveloppement. De cette manire, mon projet d'tude ne s'est pas
restreint simplement la comprhension du code mais bien une dmarche de
comprhension et de rsolutions de problmes lis au temps-rel.
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 problmes spcifiques :
problmes de synchronisation des tches dans une application
Les appels systmes spcifiques Xenomai permettent de grer la cration et
71/104
la synchronisation des tches.

accs et protection des ressources communes
identification des portions de code qui sont susceptibles de gnrer des
problmes de latence
...
Il a fallut que j'adopte une dmarche de test, d'analyse et de rsolution de ces
problmes.
6.1.2. Les outils

Je me suis familiaris avec les outils de dveloppement logiciels :
vi
Un diteur de texte performant pour le codage mais qui demande un temps
d'apprentissage non ngligeable. J'ai appris les commandes usuelles d'dition et
aussi quelques mthodes 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 dbogueur gdb est couramment utilis dans le monde Libre. J'ai du
apprendre la manire dont s'utilise ce logiciel (mise en place des points
d'arrts, excution pas pas...). En plus de l'utilisation normale de ce
logiciel, j'ai du apprendre l'utiliser pour faire du dboguage distance.
l'utilisation du traage du pipeline d'interruption (I-pipe tracer)
Pour comprendre la succession d'excution des diffrents domaines, j'ai choisit
d'activer cette option dans le patch Xenomai. L'utilisation de ce systme a
ncessit que je cherche quelles taient les informations prsentes dans la
trace et que je comprenne les mcanismes du systme Adeos.
strace
Permet de faire le traage des appels systmes 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. Dvelopper 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-rels.
6.2.1. Le management des tches

Les appels systmes qui font appels la cration des tches ont leur pendant pour la
72/104
Le management des tches - Le management des tches
suppression des ressources. Il est important de bien faire appel la paire d'appels :
rt_task_create()
rt_task_delete()
De cette faon, on fait appel explicitement la destruction de la tche.

La gestion de la mmoire est un point critique dans tout dveloppement d'application.
C'est un point particulirement important dans les systmes embarqus o il y a
gnralement peu de mmoire vive disponible. En effet, si il y des fuites mmoires
importantes, alors il y a des zones qui sont consommes inutilement et qui ne sont
pas accessibles. Ce point est encore renforc dans les systmes temps-rel : ces
zones sont susceptibles de crer des fautes de pages et donc d'aggraver le risque de
latences.
6.2.2. L'accs aux donnes

Si l'on fait des variables globales et qu'il y a la possibilit qu'elles soient accdes en
mme temps, il faut songer utiliser des mcanismes spcifiques.
Lorsque l'une des tches produit des donnes avec des contraintes temps-rel tandis
que les autres tches ne font que disposer de ces donnes, on peut envisager de
mettre en place le mcanisme des queues de messages. On utilise les appels
suivant :
RT_QUEUE queue;
rt_queue_create()
rt_queue_delete()
La tche temps-rel peut mettre ses donnes dans la file les uns la suite des autres
(dans le cas d'une FIFO17) sans ncessairement se proccuper de la frquence
laquelle les autres tches vident la file.
Lorsqu'une donne sert d'change entre plusieurs tches, il est prfrable de dclarer
un mutex . Grce une structure de ce type, on protge la donne en restreignant
la portion de code o l'on fait des modifications. Si l'on veut conserver le temps-rel
dans le systme (ne pas bloquer les activits de trop de tches, trop longtemps), cela
sous-entend que les oprations apports sur la donne soient brves. Il y a donc des
rgles qui surgissent :
on n'utilise gnralement pas des appels systmes Linux dans ces portions
protgs (pas d'affichage avec printf, par exemple) pour limiter les
changements de domaines.
on dporte les traitements sur la variable dans les portions non protges (par
contre, on protge une lecture ou une assignation de la valeur)
17 FIFO : First In, First Out (Premier entr, premier sorti)
73/104
6.3. Le dboguage des applications
6.3.1. Dboguage symbolique

Puisque les applications sont compiles pour l'architecture ARM , il n'est pas possible
de les faire fonctionner directement sur le PC de dveloppement. De plus, gdb, le
dbogueur est un logiciel particulirement volumineux (4MB environ, mme aprs
l'opration de strip ). Il faut donc faire du dboguage distance. On utilise un petit
programme (gdbserver) sur la machine cible, qui excute les commandes envoyes
depuis le dbogueur (gdb).sur le PC hte.
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 mene terme (l'option
--prefix).
Une fois que le serveur a t compil, j'ai pu le copier dans le systme de fichier de la
carte Viper. On lance le serveur sur la machine en spcifiant le programme que l'on va
faire fonctionner, l'adresse IP de la machine qui fait fonctionner le dbogueur et le port
sur lequel le serveur se place en coute.
gdbserver 192.168.0.118:2345 application
Sur la machine hte, il faut lancer le dbogueur avec une copie de l'application,
compile avec les symboles de dboguage. Ensuite, dans l'invite de commande de
gdb, on indique que la cible se trouve sur une autre machine (on prcise 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 dbogueur doit tre compil en
indiquant le type d'application qui sera dbogu. Il faudrait donc utiliser les outils de
compilation croise. En fait, je n'ai pas eu besoin de mener cette tape parce que
l'environnement de compilation croise que j'ai mis en place comportait dj un
dbogueur pour les applications fonctionnant sur ARM.
74/104
Le traage des appels systmes - Le traage des appels systmes
6.3.2. Le traage des appels systmes

On peut lister les appels systmes qu'effectue une application au cours de son
fonctionnement en utilisant l'outil strace. Cet outil, utilise son tour l'appel ptrace
dfinit par le noyau Linux.
Pour commencer, il a fallu que je compile cette application pour qu'elle puisse
fonctionner sur la carte Viper. Cette opration est facilement ralise 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-tte 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 prcise le dossier o sera install l'excutable et les document relatifs
(~/xenomai/debug/build_strace/) grce l'option prefix. On notera que le
dossier indiqu est diffrent de celui qui contient les sources
(~/xenomai/sysapps/strace-4.5.18/) et du dossier o se droule la
compilation (~/xenomai/debug/strace/). Ainsi, on conserve une distinction
nette entre les fichiers de chaque tape.
on prcise le type de la machine cible avec l'option host. En plus de prciser le
type de machine, le script utilise cette chane de caractres comme prfixe des
outils de compilation croise.
J'ai rencontr un problme lors des premires tentatives de compilation : une erreur
tait indiqu dans un fichier dfinissant les appels systmes. Ce problme est
spcifique au architectures ARM qui utilisent l'interface ABI. On trouve rapidement
sur Internet un patch qui permet de lever ce problme, 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 spcifier le fichier de patch sur
l'entre standard de la commande et la valeur de l'option -p. Cette dernire option
75/104
permet de supprimer la premire partie des chemins vers les fichiers modifier,
indiqus 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 systme de fichier de la carte Viper, son
utilisation permet de gnrer des fichiers textes donnant la liste des appels systmes
passs par l'application. J'ai parfois d aller voir l'implmentation des appels dans les
sources de Xenomai pour trouver o dbute et o commence vritablement l'appel
systme.
Il est possible de suivre les appels systmes des diffrentes tches d'une
application en faisant :
strace -ff nom_de_application
Le logiciel strace cre alors un fichier par fil d'excution.

Lorsque les latences d'excution taient longues et que j'ai suppos que cela tait d
un appel systme, j'utiliseais strace avec l'option :
strace -c nom_de_application
Dans cette configuration, la sortie prsentais un rsum des appels systmes, le

nombre de fois o ils avaient t excuts et le temps qu'ils avaient mis pour
s'excuter. En conjonction avec un prcdent passage de l'application, on peut
dterminer o se situent les portions critiques d'une application.
76/104
Conclusion
L'tude du portage de Xenomai sur la carte Viper a mis en avant la faisabilit de cette
opration. Elle est cens illustrer les performances de la carte.
Il pourrait tre envisag d'utiliser cet environnement dans le cadre du dveloppement
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 systmes Linux,
sur les spcificits des systmes embarqus, sur les systmes temps-rels. D'un point
de vue plus pratique, j'ai appris utiliser un nombre important d'applications servant
au dveloppement d'applications, et pas seulement pour l'intgration de systme.
J'espre pouvoir mettre en avant cette exprience lors de ma recherche d'emploi et
ainsi, continuer travailler dans ce domaine.
77/104
Ouverture
Suite des problmes 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'espre donc avoir le temps d'approfondir encore quelques points. En
particulier, j'espre pouvoir utiliser compltement le traceur du pipeline d'interruption
et ainsi mettre jour les causes de latences. J'espre aussi pouvoir explorer le code
de l'application klatency et donner quelques rsultats sur l'impact du contexte
d'excution sur les latences.
78/104
Annexes
A. Caractristiques de la carte Viper
Illustration 16 : Vue d'ensemble de la carte Arcom Viper, mettant en

vidence la connectique
A.1. Processeur
La carte Viper est quipe 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 numro de version spcifient que ce processeur est capable
d'utiliser un jeu d'instruction spcifique de taille rduite (dnomm Thumb , d'o le
T ) et qu'il est adoss un DSP pour effectuer les tches multimdia (le E
provient de la dsignation Enhanced ).
Il possde deux caches (un pour les donnes et un autre pour les instructions) de
32ko chacun. En plus de ces deux caches, il possde un cache plus petit de 2ko pour
les donnes pour les donnes sous forme de flux.
Le processeur reoit une mesure du temps depuis trois circuits.
L'horloge principale du systme est bas sur un oscillateur 3,6864 MHz.
L'oscillateur peut tre contrl par un cristal externe de mme frquence. C'est
la configuration qui a t retenue sur la carte Viper. Au final, c'est cette horloge
qui est utilise par le noyau Linux pour gnrer l'interruption 0 et maintenir la
valeur du PIT.
80/104
Annexes - Caractristiques de la carte Viper
Un circuit spcifique appel Real Time Clock dlivre un dcompte la

frquence de 32,768 kHz. Il permet de conserver la trace de la date et de
l'heure mme lorsque le systme est mis hors tension, grce une pile de
sauvegarde.
Un troisime circuit dlivre plusieurs horloges des frquences entre 1,8432
MHz et 25 MHz.
A.2. Mmoire
Sur la carte Viper, on trouve quatre types de mmoire :
4. 32Mo d'Intel StrataFLASH pour contenir des donnes (systme de fichier, par
exemple)
5. 1Mo de Flash de type EPROM pour contenir le chargeur d'amorage (RedBoot).
C'est cette mmoire qui est accde par le processeur au moment de sa mise
sous tension.
6. 256Ko de SRAM
7. 64Mo de SDRAM pour la mmoire principale du systme. On a accs 16Mo de
mots de 32bits. En fait, il y a deux puces mmoires contenant chacune quatre
banques de mmoires de 4Mo, de mots de 16bits.
La mmoire principale est accde par le bus principal, cadenc 100MHz.
A.3. Connecteurs srie

La carte comporte cinq connecteurs srie de type UART. Les quatre premiers d'entre
eux sont compatibles RS232. Dans la configuration srie, il faut distinguer le
contrleur srie, qui est intgr dans le processeur, du transmetteur, qui est une puce
externe proche du connecteur.
A.4. Fonctionnalits rseau

On trouve un contrleur Ethernet 10/100BaseTX sur la carte avec le connecteur
associ. Les informations de configuration et l'adresse MAC de cette interface sont
stockes dans une mmoire de type EEPROM spcifique. La prsence de cette
mmoire permet notamment au chargeur d'amorage de faire une configuration
basique de la liaison Ethernet et donc, d'initialiser une communication par le rseau de
type Ethernet.
Un connecteur de type RJ45 permet de connecter les interfaces.
81/104
B. Rsultats du programme latency
B.1. Mesures releves (n1)

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 - Rsultats 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 - Rsultats 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 : git

Le 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 dvelopp par Linus Torvalds
pour le dveloppement du noyau Linux.
C.1. Concepts
L'historique est contenu dans des fichiers rfrencs par des object name . Un nom
est le hach (en utilisant la mthode SHA1) du contenu de ce fichier. Il est donc
reprsent par une chane de 40 caractres du type :
6ff87c4664981e4397625791c8ea3bbb5f2279a3.
Avec cette mthode, il est virtuellement impossible d'avoir deux objets diffrents avec
le mme nom.
C.1.1. Les objets

Le fonctionnement de git repose sur 4 types d'objets : blob , tree , commit
et tag .
C.1.1.1. Blob
Un blob retient un contenu binaire quelconque. C'est gnralement 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 lments qui auraient
le mme contenu dans une arborescence d'un projet auraient le mme blob .
C.1.1.2. Tree
Un tree retient un ensemble de pointeurs vers des blobs ou des trees . Il
reprsente souvent un dossier ou un sous-dossier.
C.1.1.3. Commit
Un commit lie l'tat d'un arbre la faon dont on est arriv cet tat. Il retient le
nom de diffrents commits prcdemment effectus qui dfinissent cet tat
prcdent. Ce sont les parents du de ce clich .
C.1.1.4. Tag
Un 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 travail

Le 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
mta-donnes. Il est gnralement plac la racine du projet et porte le nom

.git . Il existe un seul dossier git par projet, la diffrence 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 gnralement modifis ou dplacs par git lorsque l'on passe d'une branche de
dveloppement un autre.
C.1.3. Branches
Les instantanes (les commits ) ne sont pas ncessairement aligns les uns la
suite des autres, du plus ancien au plus rcent. Le travail peut tre men de faon
parallle selon des dveloppement parallles (plusieurs dveloppeurs qui travaillent
ensemble sur un mme projet, par exemple). On parle de branches de dveloppement
; celles-ci pouvant diverger ou converger.
Le suivi d'une branche se fait en conservant la tte de cette ligne de projet (qui
correspond au dernier commit de la branche). Ce point particulier est repr par le
mot cl HEAD .
C.2. Utilisation
C.2.1. Suivi d'un projet existant

On peut cloner un dpt en utilisant la commande :
git clone git://git.kernel.org/pub/scm/stable/linux-2.6.28.y.git
A moins de spcifier un nom pour le dossier que l'on veut se crer dans son
environnement de travail, il porte le nom du dossier d'origine. Si l'on se dplace dans
ce dossier, on observe une copie des fichiers. Cette arborescence constitue le dossier
de travail.
C.2.2. Travail collaboratif

Lorsque l'on veut rcuprer les dernires modifications d'un dpt 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 dpt.
C.2.3. Initialisation d'un suivi de projet

On commence par se dplacer 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
spcifie les noms des fichiers avec la commande add . Dans le cas d'un premier
ajout, on peut vouloir ajouter tout les fichiers de faon rcursive. On tape alors la
commande :
git add .
Avant de faire le premier commit , on peut avoir un rsum des fichiers qui ont t
ajouts ou modifis depuis le dernier commit en faisant :
git status
Enfin, on peut demander enregistrer les diffrences dans l'index en faisant :
git commit
L'enregistrement de ces modifications se fait essentiellement de faon interactive. On

peut indiquer un message qui indique un rsum des changements.
C.2.4. Branches et convergences

On a dit qu'un projet peut contenir plusieurs branches de dveloppement. Pour crer
une nouvelle branche de dveloppement, 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
prcde d'une astrisque. Si l'on veut se positionner sur la nouvelle branche de
dveloppement :
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 crer des fichiers puis demander les
ajouter au suivi de la branche. Bien sr, 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 prsent, il faut l'indiquer lors de la cration 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 dveloppement, on utilisera la commande :
git merge other_branch
Lorsque les changements ne crent 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 pralables voir les
diffrences au sein des fichiers en faisant :
git diff
C.3. Autres commandes

Lorsque l'on veut observer les diffrents commits qui ont t effectus, il faut
utiliser la commande :
git log
On peut visualiser une version graphique ( l'aide de caractres ASCII 18) de la liste en
ajoutant l'option --graph .
Cette commande liste les commits dans l'ordre du plus rcent au plus ancien.
Lorsque l'on se base sur une branche qui continu d'tre dvelopp mais o l'on veut
travailler un instant donn plus ancien, elle permet de vrifier que l'on a bien
dplac le pointeur de tte au bon endroit.
Le logiciel git conserve une trace seulement des documents qu'il rpertorie. Par
exemple, si l'on mne 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 effectus sur l'autre branche
ont t appliqus sur la branche actuelle. Pour forcer le comportement et ne pas tenir
compte des changements appliqus sur la branche parallle, on remplace le -d par
-D .
18 ASCII : 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 prcdent, 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 prcdent.
90/104
Annexes - Logiciel de suivi de version : svn
D. Logiciel de suivi de version : svn

Le logiciel Subversion
(abrg svn en rapport
avec le nom de la commande
utiliser) est un logiciel de
suivi de version dvelopp 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'administration

Chaque dossier de l'arborescence du projet contient un dossier spcifique. Ce dossier
spcifique 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 rvisions

Lorsque l'on effectue des modifications sur plusieurs fichiers, chaque fois que l'on
propose une nouvelle version du travail, toutes ces oprations sont comprises comme
une seule opration (dite opration atomique ).
chaque fois que le dpt accepte une nouvelle version du projet, il est cr une
nouvelle rvision . La rvision correspond l'tat de l'arbre un moment donn.
Les rvisions se voient assigner un entier naturel qui augmente chaque nouvelle
version. La premire rvision (note 0) correspond la cration du dossier qui sert de
racine au projet et qui est encore vide de tout fichier.
Le numro de version est global tout les fichiers. chaque nouvelle rvision, le
numro de version de chaque fichier est modifi, mme pour les fichiers qui n'ont pas
subis de changement. Parler de l'tat de rvision d'un fichier, c'est parler de l'tat
dans lequel il se trouvait quand le projet en tait la version donne.
D.1.3. L'architecture du dossier projet

Il 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 dveloppement du
projet.
branches/ qui peut contenir plusieurs autres dossiers. Les sous-dossiers sont
des copies de la branche principale. Ils servent aux dveloppements en
parallle ou en amont du projet. Ils portent gnralement un nom diffrent qui
explicite l'orientation du dveloppement.
tags/ qui contient des instantans du projet. Ils peuvent tre ensuite
supprims ou archivs, mais qui ne sont pas appels tre modifis.
91/104
Bien que le point prsent dans la partie prcdente ne soit pas une ncessit 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 ncessaires et de conserver un historique des changements
effectus. Ce mcanisme est masqu l'utilisateur qui, lui, voit une copie complte
des arbres. C'est l'utilisateur qui ajoute ces branches le concept de branche de
dveloppement .
D.2. Utilisation
D.2.1. Suivi d'un projet existant

On peut cloner un projet situ sur un dpt distant en utilisant la commande :
svn checkout http://svn.example.com:3894/repository/project
La commande de Subversion permet de rcuprer le contenu du dossier project

du dpt repository qui se situe sur la machine svn . Les documents sont
rcuprs via le protocole HTTP. A moins de spcifier un nom pour le dossier que l'on
veut se crer, il porte le nom du dossier d'origine. Si l'on se dplace dans le dossier
cr, on observe une copie conforme des fichiers.
Le serveur Subversion distant peut utiliser un protocole spcifique au logiciel de suivi
de version pour la transmission des donnes. 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 faon 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 collaboratif

Lorsque l'on veut rcuprer les dernires modifications du dpt distant que l'on a
copi, on utilise la commande :
svn update
Il n'y a pas besoin de redonner l'URL du dpt car le logiciel Subversion retient la
location du dpt au moment du clonage .
D.2.3. Initialisation d'un suivi de projet

Tout commence par la cration d'un dpt. Tout les documents qui seront prsents
92/104
dans ce dpt bnficieront du suivi de projet.
svnadmin create path_to_repos
Une fois le dpt cr, on peut commencer le peupler. Pour cela, on peu copier un
dossier contenant le travail qui a dj t commenc. Le fait de copier les donnes
pour la premire fois amne Subversion faire un premier commit . Un
commit est le fait de proposer des modifications ; cela fait aussi avancer la
rvision du projet. On peut joindre le texte dcrivant brivement 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 spcifie un fichier (avec le prfixe
file: ) contenu sur la machine, en local. Dans toute URL, le premier champ aprs 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'accs au fichier (qui lui-mme commence avec une barre
oblique), d'o la prsence, au final, de trois barres la suite. C'est aussi ce moment
l qu'il est conseill de crer un squelette de type TTB ( Trunk, Tags, Branches ).
On peut avoir un rsum des fichiers qui ont t ajouts, supprims ou modifis
depuis le dernier commit en faisant :
svn status
Enfin, pour propager les diffrences sur le dpt, on fait :
svn commit
L'enregistrement de ces modifications se fait essentiellement de faon interactive. Par

exemple, on peut indiquer un message qui indique un rsum des changements.
D.2.4. Branches et convergences

On a dit qu'un projet peut contenir plusieurs branches de dveloppement. Pour crer
une nouvelle branche de dveloppement, dans le dpt, on cr un nouveau dossier.
On place ce dossier o l'on veut (gnralement 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'opration 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 donnes 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 dveloppement, 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 effectus sur ses documents (par un commit ). Sinon, on prend le
risque de rcrire par dessus ces documents.
Pour faire la jonction de la branche de dveloppement avec la branche principale, il
faut faire quelques oprations supplmentaires :
On prend soin de faire une mise jour du travail termin sur sa branche sur le
serveur ( commit depuis sa branche de dveloppement).
On se dplace 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 dveloppement :
svn merge --reintegrate \

>http://svn.example.com/repository/project/branches/personnal
Lorsque les changements ne crent pas de conflits, il reste peu de choses faire.
Sinon, il faut diter les fichiers avant de faire le dernier commit . On peut au
pralables voir les diffrences au sein des fichiers en faisant :
svn diff
Cette commande prsente les diffrences 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 commandes

Pour voir ce que contient un dossier spcifique 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

dplace 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 dpt, l'URL
du dossier de travail, la rvision...
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. Installation
Dans le cadre de mon projet, en utilisant une distribution Ubuntu sur le PC hte, le
serveur est rcuprable directement depuis les dpts. Il suffit donc d'utiliser le
gestionnaire de paquets :
sudo apt-get install tftpd tftp xinetd
On rcupre le serveur (tftpd), le client (tftp) TFTP et l'on installe le super serveur
Internet (xinetd) s'il n'est pas dj install.
E.2. Configuration
On commence par crer un dossier dans lequel les informations mises la disposition
des machines distantes seront dposes. Le dossier correspondant est cr la base
de l'arborescence systme, dans le dossier /srv/. Ce dernier dossier est celui, dans le
cas des systmes de type Linux, abrite les donnes 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 crer le dossier, on change les priorits de ce dossier et le propritaire 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 pntrer 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 paramtre server_args corresponde au

dossier dans lequel sont placs les documents partager.
Un fois ces opration ralises, on redmarre le serveur xinetd :
sudo /etc/init.d/xinetd restart
E.3. Vrification de la configuration

On peut tenter de faire une copie d'un fichier localement mais en utilisant le serveur.
Puisque nous tions plusieurs tre sur le mme rseau, j'ai aussi demand l'un de
mes collgues de faire l'opration depuis son poste.
97/104
F. Mise en place d'un serveur NFS
F.1. Installation
Dans le cadre de mon projet, en utilisant une distribution Ubuntu sur le PC hte, le
serveur est rcuprable directement depuis les dpts. Il suffit donc d'utiliser le
gestionnaire de paquets :
sudo apt-get install nfs-kernel-server
F.2. Configuration
J'ai dcid de crer un dossier dans lequel les informations mises la disposition de la
carte seront dposes. Le dossier correspondant est cr la base de l'arborescence
systme, dans le dossier /srv/. Pour rappel, ce dernier dossier est celui qui, dans le
cas des systmes de type Linux, abrite les donnes des serveurs fonctionnant sur la
machine.
sudo mkdir /srv/nfsboot
Les fichiers partager, les personnes autorises et les permissions sont dfinies dans
un fichier spcifique : /etc/exports. Les fichiers et les permissions sont de la forme :
<dossier partag> <hte>(<options>) <hte2>(<options>) ...
Dans mon cas, il prend la forme suivante :
/srv/nfsboot viper(rw,no_root_squash) montevideo(rw)
98/104
Annexes - Dboguage symbolique : gdb
G. Dboguage symbolique : gdb
G.1. Procdure de dboguage distance
G.1.1. Les paramtres spcifiques

Une application est gnralement lie dynamiquement un certain nombre de
librairies.
Au dpart, le dbogueur (sur la machine hte) 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 systme hte, qui ne correspondent pas celles
qui sont utiliss par l'application sur la machine cible. Comme gnralement, il existe
une copie du systme de fichier de la machine cible sur la machine hte, on peut
ajouter un prfixe 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 session

On commence par faire dmarrer 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 ct, sur la machine hte, on dmarre le dbogueur gdb avec la version de
notre programme contenant les symboles de dboguage :
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 usuelles

Beaucoup d'informations peuvent tre obtenues partir de la commande info de
gdb.
G.2.1. Le lien avec les librairies dynamiques

Pour voir quelles sont les librairies qui sont lies 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 vrifier que le lien
avec les librairies dynamiques s'est bien pass. Pour cela, on peut demander au
dbogueur de s'arrter au moment de la cration du lien :
(gdb) set stop-on-solib-events 1
G.2.2. Le dboguage des applications threades

Lorsqu'une application possde plusieurs fils d'excution, on peut visualiser ces
diffrents 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 spcifier au dbogueur de s'attacher un thread en particulier, plutt que le

thread principal, on utilise :
(gdb) thread x
La commande frame permet de visualiser les diffrents contextes d'excution du

processus. On utilise ensuite la mme commande en spcifiant le numro du contexte
100/104
Annexes - Dboguage symbolique : gdb
d'excution que l'on choisit, pour changer de thread :
(gdb) frame x
101/104
Bibliographie
Sites Internet
www.pc104.org Consortium du standard PC/104.
www.xenomai.org Site du projet Xenomai avec un accs 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 dveloppement d'un systme GNU/Linux
complet
www.slackware.com Site de la distribution Linux Slackware
lttng.org Environnement de traage du noyau
www.pathname.com/fhs Document du Filesystem Hierarchy Standard
www.linuxfoundation.org Fondation Linux (hbergeant le comit LSB)
Livres
The C Programming Language, 2nd Edition
Brian W. Kernighan, Dennis M. Ritchie.
Prentice Hall PTR, 1988 - 274 p.
Building Embedded Linux Systems, 2nd Edition

Karim Yaghmour, Jon Masters, Gilad Ben-Yossef, Philippe Gerum.
O'Reilly Media Inc, 2008 462 p.
Embedded Linux Primer

A practical Real-World Approach
Christopher Hallinan.
Prentice Hall PTR, 2007 - 537 p.
Understanding Linux Kernel, 3rd Edition

Daniel Bovet, Marco Cesati.
Programmation systme en C sous Linux, 2nd dition

Signaux, processus, threads, IPC et sockets
Christophe Blaess.
Eyrolles, 2005 964 p.
102/104
Linux Device Drivers, 3rd Edition
Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman.
Linux Kernel in a Nutshell, 1st Edition

Greg Kroah-Hartman.
Running Linux, 5th Edition

Matthias Kalle Dalheimer, Matt Welsh.
Learning the vi and Vim Editors, 7th Edition

Arnold Robbins, Elbert Hannab & Linda Lamb.
Articles
Documentation/CodingStyle and Beyond
Greg Kroah-Hartman, 8 p.
www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_paper/codingstyle.ps
Adaptive Domain Environment for Operating Systems

Karim Yaghmour, 2001 7 p.
www.opersys.com/ftp/pub/Adeos/adeos.pdf
Xenomai, 1st Edition

Implementing a RTOS emulation framework on GNU/Linux
Philippe Gerum, 2004 12 p.
http://www.xenomai.org/documentation/branches/v2.3.x/pdf/xenomai.pdf
Life with Adeos, rev B

www.xenomai.org/documentation/branches/v2.3.x/pdf/Life-with-Adeos-rev-B.pdf
A tour of the native API, rev C

www.xenomai.org/documentation/branches/v2.3.x/pdf/Native-API-Tour-rev-C.pdf
Proceedings of Linux Symposium, Volume two

23 au 26 juillet 2008, Ottawa, Ontario, CANADA
'Real Time' vs. 'Real Fast': How to Choose?
Paul E. McKenney
www.linuxsymposium.org/2008/ols-2008-Proceedings-V2.pdf
An advanced course on PC/104

Jim Blazer,
PC/104 and smallformfactors (PC1042289),
2007 3 p.
www.smallformfactors.com/pdfs/RTD.Win07.pdf
Choosing the appropriate PC/104 format
103/104
Kristin Allen,
PC/104 and smallformfactors (PC1042115), Resource Guide 2007
2007 2 p.
www.smallformfactors.com/pdfs/KristinAllenMktg.RG07.pdf
104/104

Rapport Berruer

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rapport Berruer

Uploaded by

Copyright:

Available Formats

ENSPS

Ple API Parc d'innovation

Rapport de projet de fin d'tude

4.3.Compteurs haute rsolution...............................................................30

Illustration 1 : Implantations d'Altran dans le monde

Le nombre important d'implantations sur le continent Europen permet au groupe de

1.2. Les domaines d'activits

Illustration 2 : Les trois "Business Lines" et le

Les trois domaines, constituant le cur du diagramme ci-dessus, sont :

1.3. Les chiffres cls

Illustration 3 : Organigramme au sein d'Altran Ouest

2.3. Les secteurs d'activits d'Altran Ouest

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

2.4. Les comptences de la branche TEM

conception et la ralisation de drivers, l'intgration et la connaissance de

3. eLiSe : embedded Linux Services

3.1. Les comptences

Illustration 4 : Un systme GNU/Linux intgr au dessus

3.1.1. Dveloppement et personnalisation noyau

3.1.2. Environnement de bas niveau

3.1.3. Intgration d'applications

3.1.4. Environnements de dveloppement

3.2. Les plateformes d'tudes

3.2.1. Veille technologique

3.2.2. La carte industrielle Arcom VIPER

3.2.3. Le tlphone Android

3.2.4. Le tlphone OpenMoko

3.3. Les services

3.3.1. Audit et expertise

3.3.2. tudes et avis de faisabilit

3.3.3. Dveloppement et support

1. Introduction aux systmes temps-rels

2. Contraintes du temps rel

2.1. Les chances

2.2. Les latences

Illustration 5 : Latences d'excution suite un interruption

La latence d'excution (6) peut tre explique en dtail :

Illustration 6 : Rpartition des applications en fonction de leurs contraintes

En fonction de l'importance de la tenue des chances pour la ralisation des

3.1. Temps rel dur

3.2. Temps rel mou

1 FTSE : Financial Times Stock Exchange

4.1. Modifications structurelles

4.1.1. Les chemins d'excutions

4.1.2. La premption du noyau

Illustration 7 : Premption du noyau

Si un processus demande un service au noyau (suite un appel systme, par

4.1.3. La gestion des interruptions

l'aboutissement du traitement men par un processus.

4.2. Modifications comportementales

4.2.1. Les modes de configuration

( spin-lock ) autour des sections de code critique. Dans cette mthode, un

4.2.2. L'hritage de priorit

Illustration 8 : Exemple d'inversion de priorit

Le processus 1, de plus faible priorit, s'excute et protge un accs une donne

4.3. Compteurs haute rsolution

5 Adaptive Domain Environment for Operating Systems , dans la Bibliographie

5.2.1. Les domaines

Illustration 9 : Adeos et les domaines

1. Dans l'usage gnral, le systme contenu dans le domaine accde au matriel

gestionnaire d'interruption du systme agisse correctement.

5.2.2. Le pipeline d'interruption

Illustration 10 : Pipeline d'interruption et disposition des domaines

La notification d'une interruption est poste l'entre du pipeline. Elle parcourt