Rapport de projet de fin d'étude

Dimension: px
Commencer à balayer dès la page:

Download "Rapport de projet de fin d'étude"

Transcription

1 ENSPS Pôle API Parc d'innovation Bd Sébastien Brant BP ILLKIRCH CEDEX Tél : Fax : Portage et évaluation de Xenomai sur une plateforme PC/104 Sébastien BERRUER Tel : Option ISAV Promotion 2009 Altran Ouest Centre d'affaires Alphasis Espace Performance Bâtiments J&K St Grégoire Tel : Fax :

2 Remerciements Je tiens à remercier Mme Alexandra Poirier, responsable des Ressources Humaines, et Mr Christophe Ducolone, Directeur Opérationnel, pour m'avoir donné la chance de faire ce stage au sein d'altran Ouest. Je voudrais remercier Mr Jean-Michel Hautbois, mon maître de stage. Il m'a prodigué de nombreux conseils et avis techniques au cours du projet. Il m'a offert la possibilité d'avoir une vision sur la fonction de chef de projet et sur la gestion de projet en général. Il a su me mettre en confiance et me motiver tout au long de la période. Je souhaite remercier Mrs Stéphane Davy et Jean-Philippe Foures. Ces personnes ont travaillé dans le même contexte que moi et m'ont apporté leurs avis sur certains problèmes techniques. Ils ont aussi apporté une ambiance de travail studieuse mais décontractée. Finalement, je remercie toutes les personnes que j'ai pu rencontrer au sein d'altran Ouest pour leurs gentillesse et leur accueil. 2/104

3 Résumé J'ai effectué mon stage de troisième année au sein du centre de service elise. Ce centre de service est spécialisé dans le domaine des systèmes Linux embarqués. C'est une spécificité du groupe d'altran Ouest. Le groupe Altran Ouest est un groupe implanté mondialement qui fait du conseil en innovation. Au cours de ce stage, j'ai étudié le système temps-réel Xenomai. Cela m'a permis de comprendre les caractéristiques des systèmes temps-réels et de découvrir les domaines d'applications courants pour ces systèmes. J'ai aussi abordé les différences qu'apporte le patch-rt sur le noyau Linux. En regard de cette solution, j'ai profondément étudié le système Xenomai : son utilisation d'adeos, la façon dont il gère le temps-réel et l'utilisation de ce système à travers son API. J'ai effectué plusieurs tâches au cours de ces 5 mois. J'ai commencé par mettre en place mon environnement de travail. J'ai du me familiariser avec la carte Viper et les méthodes de communications avec cette carte. Suite à un problème de disponibilité de ressources, j'ai créé le système de fichier utilisé au cours de l'étude. Enfin, j'ai pu réaliser le portage de Xenomai sur la carte PC/104 et étudier les performances du système. 3/104

4 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

5 Table des matières Remerciements...2 Résumé...3 Summary...4 Liste des abréviations...9 Introduction...10 Présentation de l'entreprise Groupe Altran L'implantation Les domaines d'activités Les chiffres clés Altran Ouest L'implantation L'organigramme Les secteurs d'activités d'altran Ouest Les compétences de la branche TEM eLiSe : embedded Linux Services Les compétences Développement et personnalisation noyau Environnement de bas niveau Intégration d'applications Environnements de développement Les plateformes d'études Veille technologique La carte industrielle Arcom VIPER Le téléphone «Android» Le téléphone «OpenMoko» Les services Audit et expertise Études et avis de faisabilité Développement et support...20 Les systèmes temps-réels Introduction aux systèmes temps-réels Contraintes du temps réel Les échéances Les latences La préemption Utilisations typiques Temps réel dur Temps réel mou Patch-RT Modifications structurelles Les chemins d'exécutions La préemption du noyau La gestion des interruptions Modifications comportementales Les modes de configuration L'héritage de priorité /104

6 4.3.Compteurs à haute résolution Xenomai Historique Adeos Les domaines Le pipeline d'interruption Gestion du temps-réel L'utilisation d'adeos L'architecture de Xenomai Les modes d'exécution La migration des fils d'exécution Le temps-réel dans le mode secondaire API temps-réel Les «Skins» L'API native temps-réel Real-Time Driver Model...39 Travail réalisé Environnement de développement L'arborescence de travail Les outils Logiciel de suivi de version : git Le système d'information du centre de service Portail de collaboration : Trac Les outils de compilation croisée Contraintes Dépaquetage Modification des variables d'environnement Tests de l'environnement Prise en main de la carte Viper Le chargeur d'amorçage : RedBoot Communication avec la carte Viper Liaison série avec C-Kermit Liaison Ethernet et console Telnet Configuration de démarrage Le chargement du noyau par TFTP Le montage du système de fichier par NFS Création du système de fichier Motivations Squelette de base Les directives du FHS Les fichiers de périphériques Applications SysVinit BusyBox Démarrage Le choix du système rc Les sessions utilisateurs Le serveur inetd Le serveur Telnet Portage de Xenomai /104

7 4.1.Manipulations sur le noyau Linux Patch du noyau Configuration du noyau Compilation du noyau Installation sur le système de fichier Mise en place du noyau Compilation des librairies Évaluation de Xenomai Visualisation de la console Critères d'évaluations Les situations propices aux latences La mesure de la gigue La suite de tests Clocktest Cyclic Klatency Latency Résultats Commentaires critique Analyse des mesures de «clocktest» Analyse des mesures de «latency» Le traceur du pipeline Développement sous Xenomai Réalisations Les compétences acquises Les outils Développer des «bonnes pratiques» Le management des tâches L'accès aux données Le déboguage des applications Déboguage symbolique Le traçage des appels systèmes...74 Conclusion...76 Ouverture...76 Annexes...77 A.Caractéristiques de la carte Viper...78 A.1.Processeur...78 A.2.Mémoire...79 A.3.Connecteurs série...79 A.4.Fonctionnalités réseau...79 B.Résultats du programme «latency»...80 B.1.Mesures relevées (n 1)...80 B.2.Mesures relevées (n 2)...81 B.3.Mesures relevées (n 3)...82 B.4.Mesures relevées (n 4)...83 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 /104

8 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.Vérification de la configuration...95 F.Mise en place d'un serveur NFS...96 F.1.Installation...96 F.2.Configuration...96 G.Déboguage symbolique : gdb...97 G.1.Procédure de déboguage à distance...97 G.2.Les commandes usuelles...98 Bibliographie Sites Internet Livres Articles /104

9 Liste des abréviations 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

10 Introduction J'ai effectué mon stage de troisième année dans le centre elise du groupe Altran, à Rennes. Ce centre est spécialisé dans les systèmes Linux Embarqués. Dans le cadre du développement de l'activité de cette branche, j'avais pour mission de porter l'environnement temps-réel Xenomai sur une carte industrielle et d'en évaluer les performances. Cette carte industrielle avait la particularité d'être conforme au format PC/104 et d'embarquer un processeur de type ARM. Dans le présent de ce rapport de stage, je commence par présente le groupe Altran. J'y détaille l'activité du groupe et je donne quelques chiffres clés. Je présente ensuite l'organisation du groupe au niveau de Rennes ainsi que les activités d'altran Ouest dans la région. Enfin, je présente le centre de service elise. Je joint dans le rapport un «compte-rendu» de mes recherches sur les systèmes temps-réels de type Linux. Je décris les spécificités des systèmes temps-réels, les distinctions qui peuvent exister dans ce domaine ainsi que les principaux utilisateurs de tels systèmes. Au cours des recherches sur Xenomai, j'ai souvent rencontré des références au patch-rt pour le noyau Linux ; je présente donc un rapide aperçu des modifications qu'il apporte au noyau Linux. Enfin, après un rapide historique du projet Xenomai, j'explique le système Adeos et la façon dont Xenomai l'utilise pour gérer le temps-réel. Je termine la présentation de Xenomai en faisant une description des mécanismes introduit au niveau utilisateur (utilisation des API). Le corps du rapport est constitué par la présentation des activités que j'ai mené au cours de ces 5 mois. Je présente donc : la mise en place de l'environnement de développement, la prise en main de la carte Viper et le processus de création du système de fichier. Une fois ces étapes réalisées, j'ai pu procéder au portage de l'environnement Xenomai sur la carte. Mon stage consistait aussi à faire une évaluation des performances du système. Dans cette optique, j'ai développé quelques applications utilisant l'api temps-réelle de Xenomai. 10/104

11 Présentation de l'entreprise Altran Ouest

12 1. Groupe Altran 1.1. L'implantation Le groupe Altran a été fondé en Il est implanté dans 26 pays dans le monde. Illustration 1 : Implantations d'altran dans le monde En Amérique : Brésil Canada États-Unis d'amérique En Asie : Chine Corée du Sud Inde Japon Malaisie Singapour En Europe : Allemagne Autriche Belgique Espagne France Irlande Italie Luxembourg Pays-Bas Pologne Portugal République Tchèque Roumanie Royaume-Uni Slovaquie Suède Suisse Le nombre important d'implantations sur le continent Européen permet au groupe de se positionner aujourd'hui comme le leader européen dans le domaine du conseil en innovation Les domaines d'activités Le groupe fédère des entreprises qui officient dans trois domaines d'activités différents (appelés «Business Lines»). 12/104

13 Les domaines d'activités - Les domaines d'activités Illustration 2 : Les trois "Business Lines" et le cycle d'innovation Les trois domaines, constituant le «cœur» du diagramme ci-dessus, sont : le conseil en technologies et R&D C'est la capacité de mettre en œuvre le savoir-faire, les méthodes techniques et scientifiques des consultants ingénieurs pour mener à bien des projets innovants. le conseil en organisation et systèmes d'information Il permet de fournir aux entreprises la capacité de rester compétitif face aux contraintes de croissance d'entreprise, de rentabilité et de législation. Les entreprises qui font appel à Altran sur ce point cherchent à faciliter leurs prises de décisions, et leurs agilité organisationnelle. le conseil en stratégie et management Il permet aux entreprises de maîtriser leurs environnement et d'anticiper les évolutions du secteur dans lesquelles elles travaillent. Cela leurs permettent d'augmenter leurs potentiel de succès sur le long terme. Comme le présente la «couronne» sur le schéma 2, le positionnement des trois domaines d'activités permet de couvrir totalement un cycle de produit Les chiffres clés Pour l'année 2008, le chiffre d'affaire s'est élevé à 1650,1 million d'euros. Il a été réalisé à 57% hors de France. La génération du CA étant : 13/104

14 près de la moitié du chiffre d'affaire est réalisé par les activités de la branche «conseil en technologies et R&D» un tiers du chiffre d'affaire provient des activités de la branche «conseil en organisation et systèmes d'information» environ 15% du chiffre d'affaire est produit par la branche «conseil en stratégie et management» Les consultants du groupes étaient en décembre Il y a eu 1020 recrutements nets au cours de l'année Altran Ouest 2.1. L'implantation Au niveau Français, une réorganisation a été menée pour fusionner une multitude de sociétés. Il a donc été délimité six zones, en plus de Paris : la région Ouest, la région Est, la région Nord, la région Sud-ouest, la région Rhône-Alpes et la région Méditerranée. L'implantation du groupe Altran dans l'ouest date de Les trois plus gros pôles de l'ouest sont, dans l'ordre : Rennes, Brest et Nantes. Dans l'ouest, le groupe se veut centré autour des clients, tout en s'appuyant sur sa force à l'international. Cette implantation historique permet de compter aujourd'hui 425 ingénieurs répartis sur les régions Bretagne, Pays de Loire et Poitou-Charentes. Pour mieux cerner la répartition, on compte 230 consultants à Rennes, 85 à Brest et 110 à Nantes L'organigramme Le groupe Altran est gouverné grâce à un comité exécutif et un conseil d'administration. Le premier (le comité exécutif) regroupe les personnes responsables de la direction du groupe : le Président-Directeur Général, le directeur financier et trois directeurs généraux adjoints. Le second (le conseil d'administration) décide de la politique du groupe. Ensuite, au niveau régional, les compétences sont réparties de la façon suivante : 14/104

15 L'organigramme - L'organigramme Illustration 3 : Organigramme au sein d'altran Ouest Les consultants sont les personnes qui effectuent la réalisation des projets. Ils ont le profil ingénieur. On retrouve deux types de compétences : les experts et les chefs de projet. Les experts sont spécialisés dans un domaine particulier. Les chefs de projet se situent à la frontière du management et de la technique. Au cours d'un projet, ils coordonnent le travail de plusieurs autres consultants. Ils peuvent demander l'accompagnement de consultants experts dans un domaine. Les consultants de la direction des offres ont des rôles souvent plus transversaux : ils interviennent pour répondre aux appels d'offres publics, ils organisent les fonctions liés à la Qualité... Les managers ont trois rôles principaux : le recrutement, le management d'une équipe et la relation commerciale. Ainsi, ils démarchent les clients pour trouver des projets à réaliser. En fonction des demandes des clients, ils recherchent les compétences parmi les personnes disponibles au sein d'altran. Ils se mettent généralement en rapport avec les consultants pour bénéficier de l'avis technique de ces derniers lors de la phase de décision des projets. Ils participent aux négociations et aux chiffrages financiers des projets. Les équipes administratives et la direction des Ressources Humaines apportent leur support à tout les niveaux de l'organisation. Le directeur opérationnel oriente la politique du groupe au niveau régional. Il sollicite les managers en leurs donnant une direction commerciale. C'est généralement à lui que revient la décision de lancer la réalisation d'un projet Les secteurs d'activités d'altran Ouest Dans la région Ouest, les activités sont partagées dans cinq secteurs «métiers». En effet, au niveau régional, Altran se tourne vers ses clients. Son activité est donc menée selon les secteurs : AIT : Automotive Infrastructure & Transportation Altran met son expertise à la disposition de ses clients pour améliorer leurs efficacité, la qualité et le processus de leurs produits. Les consultants interviennent sur les tâches de Bureaux d'étude et R&D, de phase 15/104

16 d'industrialisation, de production, logistique, de Qualité... Cette branche regroupe plus de 80 consultants dans l'ouest. ASD : Aéronautique, Spatial, Défense Altran Ouest officie essentiellement sur deux grands domaines, dans la région : les sciences et techniques de la mer, l'aéronautique et la défense. Le premier est un domaine spécifique à d'altran Ouest. Il fait appel à des compétences telles que l'acoustique sous-marine, la géophysique... Le second domaine nécessite plutôt des personnes travaillant dans les domaines de l'électronique, des systèmes embarqués, de la mécanique... Actuellement, on compte 65 consultants dans l'ouest. CIS : Conseil & Systèmes d'information Cette branche d'activité a pour but la performance des entreprises en améliorant leurs organisation et leurs systèmes d'informations. Le groupe est capable de mettre en place des projets de conseils et d'expertise, de faire de la maîtrise d'œuvre et de la maîtrise d'ouvrage, de l'ingénierie système et intégration... Cette branche regroupe 120 consultants. EILIS : Energy, Industry & Life Sciences À travers cette ligne d'activité, Altran Ouest vise : les industries de production d'énergie, les industries chimiques, les industries agro-alimentaires et les industries de la santé (pharmacie et cosmétique). Elle aide ses clients sur les problématiques d'hygiène, de sécurité et d'environnement. Désormais, 15 consultants sont rattachés à ce domaine. TEM : Telecoms & Media On peut considérer que c'est la branche historique d'altran Ouest. Le groupe revendique une expérience de plus de 20 ans dans les domaines de la téléphonie mobile & TV numérique, les réseaux & télécommunications, l'électronique. Plus de 120 consultants font partie de cette branche Les compétences de la branche TEM La branche TEM propose des compétences dans trois grands domaines : la téléphonie et la télévision numérique Dans ce domaine, les compétences proposés sont celles liées au matériel, à la création de codecs vidéo et audio, à la connaissance des spécificités des bandes de diffusion, à l'application des protocoles de communication (GSM, MPEGx,...). l'électronique Au sein de ce domaine, on compte des compétences telles que : la connaissance de plates-formes matérielles spécifiques ou le design de cartes. Dans cette spécialité, au niveau système, le groupe à la capacité de proposer la 16/104

17 Les compétences de la branche TEM - Les compétences de la branche TEM conception et la réalisation de drivers, l'intégration et la connaissance de systèmes embarqués et temps-réel. les réseaux et les télécommunications Les compétences dans ce domaine permettent de proposer au client des solutions sur ses problèmes de conception et de sécurisation des réseaux, sur l'interopérabilité, etc Altran peut apporter son expertise sur des techniques telles que la VoIP, le WiFi, le WiMax. 3. elise : embedded Linux Services Le centre elise est une particularité de la branche TEM dans l'ouest. Les compétences des personnes rattachées à ce groupe concernent les systèmes embarqués de type Linux. Le centre est capable de proposer ses services sur une large partie d'un cycle de vie d'un produit. C'est aussi une plateforme permettant aux consultants de développer leurs compétences ou d'explorer un sujet parmi le domaine des systèmes embarqués Les compétences Les compétences déployées au sein du centre de service touchent tous les domaines des systèmes embarqués, autant au niveau du matériel que du code source. L'étendue de ces compétences permet de garantir une totale maîtrise des systèmes développés dans le centre. Il en résulte une meilleure qualité de ceux-ci. Illustration 4 : Un système GNU/Linux intégré au dessus d'une plateforme matérielle 17/104

18 Développement et personnalisation noyau Le développement noyau comporte la mise au point du BSP. Les portions de code spécifique développées pour une plateforme matérielle donnée sont généralement minimales. À côté du support de la carte, il faut parfois développer des drivers spécifiques pour les périphériques. En plus de tout cela, l'expertise du centre permet de choisir les sous-systèmes les plus performants pour une application donnée ; par exemple, le choix d'un système de fichier parmi les variantes ext, jffs2... Par rapport au schéma 4, les compétences explicitées précédemment se situent au niveau du noyau, de ses drivers et de ses modules 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'intégration des applications standards pour utiliser une machine (un interpréteur de commandes, les applications ls, cat...). Il pourra y avoir parfois a effectuer le développement d'outils spécifiques pour l'initialisation du système, le management du matériel... Le travail se situe donc au dessus du noyau Linux, vis-à-vis des librairies et des applications GNU (voir le schéma 4) Intégration d'applications Il faut garantir au client final le bon fonctionnement d'une application embarquée. Donc, il faut s'assurer que le logiciel fonctionnera bien sur la machine, que ce soit en terme de trace mémoire, de consommation d'énergie ou de rapidité d'exécution. On peut aussi faire de l'analyse statique de code pour le réduire et/ou l'améliorer (avec la possibilité que l'impact mémoire soit réduit) Environnements de développement Le centre propose parfois de mettre en place des chaînes de compilation finement adaptées à un matériel. Des chaînes de compilation adaptées permettent d'améliorer grandement le code exécutable des applications. Le centre met en avant sa compétence pour installer des environnements de développements avec des outils issus du monde du logiciel libre (par exemple, le logiciel de suivi de version git, le logiciel de déboguage gdb...) Les plateformes d'études Veille technologique Le centre de service répond à des besoins clients spécifiques mais il se place aussi en amont de la demande, en gérant des études en interne. Ces études permettent d'anticiper les problèmes clients. Cela permet d'acquérir des compétences et d'entretenir la collaboration au sein des communautés Open Source, ce qui peut-être mis en avant face aux clients. 18/104

19 La carte industrielle Arcom VIPER - La carte industrielle Arcom VIPER La carte industrielle Arcom VIPER La carte Arcom VIPER est une carte industrielle, typique des applications automatisées et/ou des réseaux embarqués. Le travail réalisé pour cette plateforme a, en premier lieu, été le portage de la version du noyau Linux. Il a continué avec le portage et la création d'applications à visés multimédia (bibliothèque graphique Qt, application vidéo VLC). Pour ma part, j'ai effectué le portage de l'environnement temps-réel Xenomai sur cette carte Le téléphone «Android» Le téléphone HTC G1 permet de faire fonctionner le système d'exploitation Android. Le système Android est un système d'exploitation (ayant une base Linux et utilisant majoritairement le langage Java pour ses applications) à destination des téléphones et des appareils mobiles. L'effort de développement de cette plateforme est soutenu par Google. Le téléphone HTC G1 est appelé couramment le «Google phone» ou «Android», en rapport avec son système d'exploitation. Actuellement, le système Android semble se dessiner comme une alternative intéressante pour les appareils mobiles connectés (smart-phones, MID, net-books...). La société HTC a été la première à commercialiser un téléphone utilisant ce système, mais elle a été suivi cet été par Samsung. Un certain nombre de rumeurs envisagent que des constructeurs de net-books (Dell, par exemple) se mettent aussi à proposer des appareils fonctionnant avec ce système d'exploitation. Dans ce contexte, le groupe Altran se positionne en avance de phase en formant des personnes sur cette plateforme. Au cours de l'été, un travail a été réalisé visant à porter le décodeur h.264 SVC sur la plateforme. Ce format de compression (h.264 SVC) permet l'adaptation de la taille d'un flux vidéo en fonction de la disponibilité du réseau. Les prochains lecteurs vidéo téléphoniques, intégrant ce format de compression, devraient apporter une meilleure expérience aux utilisateurs en fournissant de la vidéo sans interruptions Le téléphone «OpenMoko» Le téléphone Neo FreeRunner permet de faire fonctionner le système d'exploitation OpenMoko. Ce téléphone est un véritable smart-phone utilisant le GSM, le WiFi, le GPRS, un écran tactile... L'intérêt de ce téléphone repose sur l'entière ouverture de ses spécificités, depuis composants matériels jusqu'aux briques logicielles qui composent le système. communauté qui est à l'initiative de ce téléphone a publié absolument tout documents de conception. Par exemple, il est possible d'aller jusqu'à étudier masques de fabrication de la carte du téléphone. les La les les 19/104

20 3.3. Les services Les services du centre se positionnent tout au long du cycle de vie d'une application 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 compatibilités matérielles et logicielles. Ils savent estimer la faisabilité d'un portage d'une application sur une plateforme donnée. L'expertise de ces mêmes personnes leurs permet de proposer l'optimisation d'applications pour que celles-ci fonctionnent parfaitement sur un matériel donné. L'optimisation peut porter sur la vitesse d'exécution, l'empreinte mémoire ou la consommation Études et avis de faisabilité Le centre de service se positionne sur les études de faisabilité de produits. Il est capable de faire des propositions de matériel et de logiciel qui répondent à un besoin client. En effet, il existe des cas où le matériel impose des contraintes, ou apporte des spécificités, qui influent sur les performances d'un système. Le centre se propose d'aider ses clients à migrer d'un environnement propriétaire à un environnement Linux selon une méthode guidé, pas-à-pas. Cette migration se fait en conservant l'isolation du code propriétaire et du code source issu de la communauté Open-source. Par exemple, cela évite la «pollution» des portions de codes régies par une licence GPL Développement et support Le développement est un terme générique pour indiquer que le centre de service peut proposer des conseils sur le développement d'un BSP, la réalisation de celui-ci (portage, développement de drivers...) et le maintien de ce BSP. Il est aussi capable de proposer du management d'applications. Ce terme inclut le développement de modules spécifiques, le maintien d'applications... Cela permet de satisfaire les contraintes sur la durée de vie d'un produit, et donc de la rentabilité sur le long terme. Lors du développement d'un solution Linux embarqué, le centre de services produit des conseils vis à vis de l'architecture du système, des tests à réaliser et propose une démarche d'assurance qualité. Les personnes du centre peuvent être amenées à dispenser des sessions de formation aux clients sur les spécificités du monde embarqué. 20/104

21 Les systèmes temps-réels Les solutions temps-réels de type Linux

22 1. Introduction aux systèmes temps-réels Les systèmes temps-réels se caractérisent par des contraintes sur l'exécution de leurs processus. Ils visent généralement à la tenue de certaines échéances. Pour cela, ils cherchent à diminuer les temps de latences et à autoriser la préemption du système. Les systèmes temps-réels sont traditionnellement utilisés dans certains domaines. Ces domaines imposent plus ou moins de contraintes vis-à-vis des échéances ; ce qui caractérise deux types de temps-réel : le temps-réel dur et le temps-réel mou. Au fil du temps, plusieurs approches ont été suivies pour satisfaire ces contraintes en utilisant le noyau Linux : la modification du noyau existant ou l'utilisation de systèmes temps-réels à part entière, fonctionnant à côté du noyau. La première approche repose sur la modification du code source du noyau Linux. L'un des points les plus marquant est la possibilité de préempter l'exécution du noyau. De plus, des mécanismes spécifiques sont introduit grâce au patch, ainsi qu'une nouvelle gestion du temps. La deuxième approche a aboutit à la création du projet Xenomai. Cette solution repose sur l'utilisation d'un autre projet : Adeos. Cela induit une architecture particulière pour la gestion du temps-réel et la proposition d'une API spécifique pour le temps-réel. 2. Contraintes du temps réel 2.1. Les échéances La contrainte d'un système temps réel est le fait que le bon fonctionnement de ce système ne dépend pas seulement de la réussite des opérations menées, mais aussi de la réussite de ces opérations dans un temps donné. Si les limites de temps sont dépassés, on dit alors que le système à échoué. Ainsi, les systèmes temps réels ne sont pas nécessairement rapides. Un système temps réel peu fonctionner sur une plateforme matérielle lente et à bas coût. Par contre, il est nécessaire que la réalisation des opérations, dans les limites de temps imparties, soient garanties par un système d'exploitation spécifique. On parle généralement de déterminisme. Il faut que l'on soit assuré que l'opération menée soit terminée avant l'échéance Les latences La latence est le temps qui peut exister entre le moment où un événement est notifié et celui où il est effectivement traité. En s'appuyant sur le schéma Erreur : source de la référence non trouvée, on peut imaginer l'exemple d'un programme qui, au cours de son exécution, fait la demande d'une donnée issue d'un périphérique. Lorsqu'il fait appel à cette donnée, cette information n'est pas nécessairement disponible immédiatement. Il est donc mis en «sommeil» de façon à ce qu'un autre programme utilise l'unité de calcul, en 22/104

23 Les latences - Les latences attendant que la donnée soit disponible. Lorsque le signal d'interruption indique que la donnée est disponible, il existe un certain temps entre cette notification et la poursuite du traitement du premier programme. Ce délai est appelé une latence d'exécution suite à une interruption. Illustration 5 : Latences d'exécution suite à un interruption La latence d'exécution (6) peut être expliquée en détail : 1. Latence à l'exécution de la routine d'interruption Il existe un certain temps entre le moment où le signal électrique (issu du périphérique) signale l'interruption et le moment où la routine d'interruption correspondante commence à être exécutée. Cela s'explique par le fait que le processeur doit d'abord terminer l'exécution de l'instruction en cours. En effet les interruptions matérielles sont, par nature, asynchrones et les instructions complexes prennent généralement plusieurs cycles à s'exécuter entièrement. Avant d'exécuter la routine d'interruption, le système doit commencer par sauver le contexte d'exécution du processus actuel. Finalement, il prépare le contexte d'exécution de l'interruption (lecture de la position du vecteur d'interruption dans une table, mise en place de la pile...). 2. Temps d'exécution de la routine d'interruption Il faut ajouter le temps d'exécution de cette routine d'interruption. 3. Latence à l'exécution de l'ordonnanceur Une fois cette routine d'interruption exécutée, il peut y avoir un appel à l'ordonnanceur. Là encore, il existe un délai entre le moment où l'ordonnanceur est appelé et le moment où il commence à s'exécuter. Ce temps s'explique de la même façon que pour la routine d'interruption : le noyau peut avoir à effectuer d'autres opérations avant d'exécuter l'ordonnanceur (enlever un masque d'interruption...). 4. Temps d'exécution de l'ordonnanceur De même, il faut compter le temps d'exécution du code de l'ordonnanceur. 5. Restauration du contexte d'exécution Enfin, il faut rétablir le contexte d'exécution du processus qui avait été mis en sommeil. Il faut commencer par rétablir les valeurs des registres d'exécution du processeur. Ainsi, le processus reprend sont exécution au point où il en était rendu, de façon transparente. 23/104

24 Au total, il faut comprendre que l'on doit attendre la somme de toutes ces durées avant qu'un programme ne réagisse à un événement donné La préemption La préemption est la capacité d'interrompre l'exécution d'une tâche en faveur de l'exécution d'une autre tâche. Pour donner l'impression que plusieurs processus ont accès en même temps à l'unité de calcul, les systèmes multi-tâches mettent un place le mécanisme d'ordonnancement des tâches. Ce concept (partage du temps d'utilisation du processeur) repose sur la capacité du système à préempter l'exécution du processus en cours. Dans les systèmes multi-tâches, la préemption du processus en cours se fait au profit de l'ordonnanceur. L'ordonnanceur mène un arbitrage pour décider quel processus doit s'exécuter. Dans un système temps-réel, il paraît logique que les tâches qui sont les plus critiques gagnent le droit d'utiliser le processeur lorsqu'elles ont besoin de s'exécuter. Ainsi, toute section de code exécutable doit pouvoir être interrompue au profit d'une autre. Ce principe est valable à la fois pour les processus utilisateurs et pour le code du noyau. De plus, lorsque la préemption est faite pour organiser la politique d'ordonnancement, cette politique doit satisfaire en priorité les demandes en ressources des processus les plus critiques. Ce point est régis par la mise en place, dans les systèmes temps-réels, d'ordonnancements spécifiques : ordonnancement rapide (type «Round-Robin»), ordonnancement à héritage de priorités Utilisations typiques Les systèmes temps-réels ne reposent pas que sur l'aboutissement des traitements, ils font apparaître des contraintes sur les échéances. Selon la gravité de la non tenue des échéances, on définit la «dureté» du temps réel. Illustration 6 : Répartition des applications en fonction de leurs contraintes 24/104

25 Utilisations typiques - Utilisations typiques En fonction de l'importance de la tenue des échéances pour la réalisation des opérations, on définit deux grandes catégories de temps-réel : le temps-réel dur et le temps-réel mou Temps réel dur On distingue les applications dites de temps réel dur, pour lesquelles, le non respect des échéances peut entrainer des graves problèmes de sécurité ou le non respect de la qualité du service rendu. Dans ce cas, les exigences se présentent sous une forme impérative. Par exemple, la tâche doit être terminée en, au maximum, 3ms. Parmi les secteurs nécessitant des systèmes temps réel dur, l'aéronautique, la robotique ou l'industrie de contrôle/supervision. on retrouve 3.2. Temps réel mou Les applications de temps réel mou peuvent se permettre de voir, bien que très rarement, des échéances non respectées. Les exigences de temps se présentent sous la forme d'un ou plusieurs intervalles ainsi qu'un ratio de réussite associé. Par exemple, on voudra que la tâche soit terminée en moins de 3ms dans 80% des cas et en moins de 5ms dans 99,9% des cas. La mesure de cette probabilité définie la Qualité de Service. On voit apparaître des applications de temps réel mou dans les domaines de la finance et du multimédia. Le premier domaine (la finance), bien que fonctionnant avec des intervalles de décompte de l'ordre de la milli-seconde, impose que les échéances soient tenues. C'est ce qui a suscité la mise en application de systèmes temps-réel dans ce domaine. Par exemple, l'indicateur des cents plus grosses capitalisations boursières du Royaume-Uni, le «FTSE1 100 Index», est calculé et diffusé toutes les quinze secondes, en temps-réel. Le second domaine (le multimédia) illustre le fait que l'on puisse parfois accepter que des échéances ne soient pas vérifiées. L'exemple typique est celui de la vidéo. Un utilisateur courant accepte généralement que le décodage d'une vidéo ou d'une musique soit brièvement manqué lorsque son ordinateur est soumis à une forte charge. 4. Patch-RT Depuis plusieurs années, plusieurs personnes ont eu la volonté de modifier le noyau Linux pour qu'il soit capable de répondre aux contraintes du temps-réel, sans l'aide de co-noyau. Le patch-rt a la vocation de transformer le noyau Linux (par l'application d'un patch sur le code source du noyau) en un véritable système temps réel. Le mainteneur actuel de ce patch est Ingo Molnar, un ingénieur de la société Red Hat. Les programmes qui utilisent ce noyau modifié n'utilisent pas d'api particulière, ils se basent sur l'utilisation de l'api POSIX. 1 FTSE : Financial Times Stock Exchange 25/104

26 En effet, dans la ligné du standard POSIX2 (norme IEEE Std ), il a été défini un certain nombre d'appels systèmes pour résoudre les contraintes de temps-réel (management de l'ordonnancement, signaux temps-réels, méthodes de création de «threads»...). Présentés sous la forme d'amendements pour la version IEEE Std , ils ont été incorporés comme des options à la norme, lors de sa révision en Modifications structurelles Les chemins d'exécutions Le chemin d'exécution d'un processus est un indicateur macroscopique du déroulement des opérations réalisés par ce processus. C'est une manière unifiée et linéaire de se représenter le déroulement des opérations du programme. En réalité, le chemin d'exécution d'un processus n'est pas linéaire : de par la façon dont sont exécutées les instructions par le processeur, de par la façon dont a été optimisé le code à la compilation... On distingue généralement les portions où le processus fait appel au noyau (via des appels systèmes) pour que celui-ci effectue des tâches particulières : on dit que le processus s'exécute dans l'espace noyau. À l'inverse, lorsque le processus n'effectue pas de tâches critiques, on dit qu'il s'exécute dans l'espace utilisateur La préemption du noyau Généralement, le noyau est la partie de code la plus critique du système. C'est dans le contexte du noyau que sont manipulés des structures de données sensibles : la table des processus, la table des pages mémoires... C'est pour cela qu'il n'est généralement pas possible de préempter l'exécution du noyau. Pourtant, si le noyau préempte un processus et met longtemps à compléter son chemin d'exécution, cela introduit des latences d'exécutions. L'exécution du noyau peut empêcher l'exécution de processus de hautes priorités. La première solution est de modifier la structure du noyau pour raccourcir les chemins d'exécution. En plus de cette première approche, on peut décider que le noyau puisse être préempté. 2 La norme POSIX (Portable Operating System Interface) est issu de la nécessité pour les différents systèmes de type Unix (d'où le «X» du nom de la norme) d'avoir une interface identique, simplifiant ainsi la portabilité des applications. 26/104

27 La préemption du noyau - La préemption du noyau Illustration 7 : Préemption du noyau Si un processus demande un service au noyau (suite à un appel système, par exemple), on considère que son chemin d'exécution passe en mode noyau. Dans le schéma 7, le chemin d'exécution du processus 1 peut être compris comme la «trace» verte. La préemption du noyau intervient lorsqu'une tâche de plus haute importance a aussi besoin de s'exécuter dans l'espace noyau. Dans le schéma précédent, le processus 2 préempte l'exécution du processus 1, qui est en mode noyau, au profit de sa propre exécution. Ainsi, la tâche de plus haute importance n'est pas obligée d'attendre la fin du chemin d'exécution noyau du premier processus. Toutefois, si l'on accepte que le noyau soit ré-entrant, il faut baliser les portions où sont faites des modifications dans les structures sensibles du noyau. Il faut empêcher que deux processus modifient les mêmes données lorsqu'ils ont un accès concurrent au noyau. Le patch-rt met en place, autour des portions de code critique, des structures spécifiques («mutex3», par exemple) qui empêchent l'accès simultané de ces portions. On protège ainsi l'accès aux structures sensibles et l'on assure la cohérence des données contenues La gestion des interruptions Dans un noyau standard, et pour un driver correctement construit, le traitement des interruptions se découpe en : une routine d'interruption (très courte) et une «softirq» (ou «tasklet»). La routine d'interruption essaye de faire uniquement le travail le plus important (copier les données depuis le «buffer» du périphérique vers un emplacement mémoire, modifier un bit d'acquittement sur le matériel...). Elle laisse le reste des traitements à la tâche de la «softirq». Les composants qui gèrent une interruption (ISR4 et softirq) préemptent les processus pour s'exécuter, quels que soit leurs priorités. Ce mécanisme peut-être pénalisant dans un système temps-réel : si le traitement de l'interruption est long, il empêche le processus de s'exécuter et apporte une latence dans le système. Il peut aussi y avoir un flot soudain d'interruptions. Dans un noyau classique, cela nécessite l'exécution de nombreuses routines d'interruptions à la suite. Pendant que les routines d'interruptions occupent le processeur, les processus ne peuvent pas s'exécuter. Dans les systèmes temps-réel, il faut pouvoir décider que certaines interruptions soient retardées si leurs importance est moindre, comparé à l'exécution et à 3 MUTEX : MUTual Exclusion (exclusion mutuelle) 4 ISR : Interrupt Service Routine 27/104

28 l'aboutissement du traitement mené par un processus. Bien sûr, on ne peut empêcher le signal électrique de l'interruption d'interrompre le fonctionnement du processeur. Seulement, lorsqu'un signal d'interruption arrive, un noyau patché (avec le patch-rt) prend le parti de créer un fil d'exécution noyau (un «thread noyau»). Il ne fait que cette opération avant de retourner à l'exécution du processus précédent : créer et compléter la structure contenant les informations du fil d'exécution. Le fil d'exécution contiendra le corps de la routine d'interruption. L'avantage de cette configuration est que les fils d'exécution peuvent être ordonnancés au même titre que des processus classiques (par exemple, ils apparaissent dans la liste des processus que donne la commande ps). Il est possible de modifier la priorité d'exécution des routines d'interruption. La gestion du tempsréel sur le système repose ensuite sur la capacité de l'administrateur à échelonner correctement les priorités des processus. Il faut que les processus critiques aient la possibilité de mener leur traitement à temps et que l'ordonnancement des routines d'interruptions n'amènent pas la perte de données. Il faut aussi réfléchir à ce que n'apparaisse pas une situation d'inter-blocage («deadlock») Modifications comportementales 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 entrées apparaissent dans le menu de configuration du noyau, avant la compilation. Elles se trouvent dans le sousmenu «Preemption mode» du menu «Processor type and features». Ces options sont : pas de préemption (PREEMPT_NONE) Lorsque le première option est choisie, le noyau Linux fonctionne comme il le faisait dans les versions antérieures à 2.4. Lorsque du code s'exécute en mode noyau, il est impossible de le préempter. Ce mode est avantageux dans le sens où il y a moins de changements de contextes et donc moins de charge pour système («overhead» lié à l'ordonnancement, par exemple). De plus, le cache est moins souvent renouvelé et donc mieux utilisé. préemption volontaire du noyau (PREEMPT_VOLUNTARY) La deuxième option repose sur le fait que le code du noyau contient des appels à une fonction utilisée à des fin de déboguage : la fonction might_sleep. Traditionnellement, cette fonction vérifie si l'ordonnancement peut être effectué sans problèmes et affiche un message indiquant le résultat de ses tests. La deuxième configuration du patch-rt utilise cette fonction pour effectuer un appel à l'ordonnanceur. Ainsi, chaque endroit où la fonction apparaît devient un point de préemption possible. Cette option est sécurisante et améliore la réactivité d'un système. Elle présente le désavantage de restreindre la préemption à des zones bien déterminées du noyau. préemption du noyau (PREEMPT_DESKTOP) La préemption du noyau est possible par l'insertion de verrous tournants 28/104

29 Les modes de configuration - Les modes de configuration («spin-lock») autour des sections de code critique. Dans cette méthode, un processus qui bloque sur un verrou se met à exécuter une boucle infinie en attendant que le verrou ne se libère. La méthode trouve sa meilleure application sur les systèmes multi-processeurs. Il y a tout de même certains défauts majeurs pour cette implémentation. En général, le code qui est protégé par le verrou est court et donc, la boucle d'attente ne dure qu'un bref instant. Il faut toutefois comprendre que le temps d'attente de la boucle active est conditionné par la longueur du code qui est protégée. Cela va à l'encontre du déterminisme : on ne peut savoir à l'avance quel processus (et donc, quel longueur de code) va être la cause du blocage. Si un processus détient un verrou, il empêche tout les autres processus de le préempter, même s'ils ne souhaitent pas accéder à la portion de code actuellement utilisée. Dans le cas d'un système mono-processeur, l'attente active consiste à continuer d'autoriser l'accès au processeur pour une tâche qui ne fait rien d'autre que d'attendre et de tester la disponibilité de la ressource. Il y a donc un consommation de cycles processeurs. préemption complète (PREEMPT_RT) La stratégie qui est mise en place dans la configuration précédente ne résout pas complètement le problème. Il faudrait que chaque portion de «code critique» soit protégée par son propre système de verrou. Pour cela, dans la configuration «préemption complète», la majorité des verrous qui étaient implémentés dans la configuration précédente sont transformés en «mutex». Ainsi, le processus qui tente d'atteindre la ressource, et bloque sur le «mutex», est mis en sommeil laissant la possibilité à d'autres processus d'être ordonnancés. Le mécanisme mis en place permet de diminuer le temps de réaction des processus temps-réel. Les latences sont largement réduites L'héritage de priorité Il existe un problème récurrent dans la théorie d'ordonnancement des tâches. Ce problème est connu sous la dénomination : «inversion de priorité». On présente généralement un exemple avec trois processus, de priorités croissantes. 29/104

30 Illustration 8 : Exemple d'inversion de priorité Le processus 1, de plus faible priorité, s'exécute et protège un accès à une donnée sensible à l'aide d'un mécanisme de type «mutex». Un processus de plus haute priorité (processus 3) est démarré. Il préempte l'exécution du premier processus puisqu'il possède une priorité plus élevée. Si le processus souhaite avoir accès à la même donnée que le processus de faible priorité, selon les mécanisme de mutex, il est mis en sommeil. Il va devoir attende que le processus de plus faible priorité termine sont traitement. Le problème apparaît si un processus de priorité «intermédiaire» (processus 2) est démarré car il préempte l'exécution du processus de plus faible priorité. Il retarde donc d'autant le redémarrage du processus de plus haute priorité (qui est toujours en attente de la libération de la ressource par le processus de plus faible priorité). La solution est de faire hériter la priorité élevé du processus qui fait la demande de ressource, au processus qui la détient. Le processus qui détient la ressource est donc ordonnancé prioritairement. Il libère donc la ressource plus rapidement. Une fois qu'il libère la ressource, il retrouve sa priorité originelle, et se fait préempter par le processus de plus haute priorité qui faisait une demande concurrente. Le temps d'attente est donc réduit. Si ce problème apparaît dans l'exécution de fils d'exécution noyau, cela peut avoir des effets désastreux (un processus de priorité élevé peut se retrouver bloqué quasi infiniment). C'est pour cela que le patch-rt met en place l'héritage de priorité sur les mécanismes de protection du noyau. Thomas Gleixner, Ingo Molnar et d'autres contributeurs ont implémentés un mécanisme de protection, à base de mutex, rapide et robuste appelé «robust futex». Ce mécanisme a été implémenté à partir des mutex légers (ou «futex») en espace utilisateurs qui avait été apporté par Rusty Russell. Les «futex» ont été introduit dans le noyau à partir de la version (septembre 2006). Il est a noter que ces structures ne sont accessible en espace utilisateur qu'à travers une librairie C GNU de version 2.5 ou supérieure Compteurs à haute résolution Pour que le noyau soit capable de répondre à l'arrivée d'un évènement, il faut qu'il 30/104

31 Compteurs à haute résolution - Compteurs à haute résolution soit capable de distinguer l'arrivée de cet évènement dans le temps. La plus petite unité que le noyau est capable de résoudre est le «jiffy». La fréquence (en Hertz) des «jiffies» est essentiellement calculée à partir d'une variable nommée HZ. La diminution de cette unité de temps minimale permet d'augmenter la résolution temporelle du système. Mais, la mise à jour du compteur de «jiffies» nécessite l'exécution d'une routine d'interruption lié à l'horloge. Donc, il y a le risque de surcharger le système (avec le traitement de cette interruption) lorsque l'on augmente la résolution du système. L'implémentation originale des compteurs fait apparaître des latences importantes. L'implémentation des compteurs à haute résolution temporelle a été ajoutée pour l'architecture x86 depuis la version L'architecture de base avait été rajoutée dans le noyau Linux depuis la version On peut rendre fonctionnel ce système depuis le menu de configuration de la compilation du noyau. Le travail de développement continu d'être fait dans le patch-rt. 5. Xenomai Pour implémenter le temps réel avec des systèmes de type GNU/Linux, on peut faire fonctionner deux noyaux côte-à-côte (on parle de systèmes à co-noyaux). L'approche consiste à ajouter un noyau (ou «micro-noyau») à côté d'un noyau Linux classique. C'est l'approche qui est faite par Xenomai. Le micro-noyau s'occupe de la gestion des interruptions matérielles, fait fonctionner des tâches temps-réelles, apporte des fonctionnalités de gestion du temps Historique On situe généralement le lancement du projet Xenomai suite à la publication de l'article de Karim Yaghmour sur Adeos en Xenomai a été créé pour faciliter la migration des applications qui reposaient sur des solutions temps-réels propriétaires vers une solution Open Source (système de type GNU/Linux). Un des points critiques de la migration est de continuer à garantir la bonne tenue des échéances (contrainte typique des systèmes temps-réels). C'est en 2002 que Xenomai a été porté sur Adeos. Ceci a permis d'affranchir Xenomai des dépendances liés aux différents systèmes d'exploitations existants et d'améliorer la prédiction des latences d'interruptions. En 2003, le projet originel a été fusionné avec le projet RTAI dont le but était lui aussi de proposer un solution temps-réel libre. Le code source de RTAI et la partie spécifique à Xenomai (qui s'appelait alors RTAI/fusion) sont restés relativement indépendants. C'est après ce regroupement, et au cours des développements qui ont suivi, que le projet Xenomai a gagné sa capacité d'être porté sur différentes architectures matérielles. En 2005, le projet Xenomai s'est séparé du projet RTAI et a repris son indépendance. À cette date, le projet Xenomai a pris son nom actuel. 5 «Adaptive Domain Environment for Operating Systems», dans la Bibliographie 31/104

32 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'accès à une même ressource physique pour plusieurs systèmes Les domaines L'une des applications courantes de cette couche est le fonctionnement de deux noyaux côte à côte sur le même matériel. Pour rendre cela possible, Adeos introduit le concept de «domaine». Généralement, un système d'exploitation complet prend place dans un domaine, bien que ce ne soit pas une contrainte. Par contre, le point commun de ces domaines est le fait qu'ils sont en compétition pour traiter des événements externes (interruptions matérielles) ou internes (exceptions, interruptions logicielles). Un système, cantonné dans un «domaine», se définit un espace d'adressage privé et des abstractions telles que les processus, les adresses virtuelles... Entre parenthèses, un tel système n'est pas restreint à son domaine s'il est capable de détecter Adeos et de l'utiliser comme intermédiaire. L'utilisation d'adeos par un système donné lui permet de partager des ressources avec d'autres systèmes. Illustration 9 : Adeos et les domaines 1. Dans l'usage général, le système contenu dans le domaine accède au matériel sans aucune restriction. Tout se passe comme si Adeos n'était pas présent. 2. Adeos reçoit le contrôle du matériel lorsqu'une interruption matérielle ou logicielle surgit. Le système Adeos peut aussi accéder au matériel pour ses propres besoins. 3. Lorsque le système d'exploitation n'a pas conscience de la présence d'adeos, Adeos doit préparer l'environnement de traitement des interruptions pour le système sus-jacent. En particulier, il présente la pile de façon à ce que le 32/104

33 Les domaines - Les domaines gestionnaire d'interruption du système agisse correctement. 4. Lorsque le système a connaissance de la présence d'adeos, il peut alors demander à avoir accès aux ressources des autres domaines, demander à changer la priorité sur son accès aux interruptions... La communication entre Adeos et le système devient bi-directionnelle Le pipeline d'interruption Adeos supervise l'accès aux ressources par les différents domaines. Par exemple, Adeos hiérarchise l'accès aux interruptions en les distribuant à travers une «file d'interruption». Illustration 10 : Pipeline d'interruption et disposition des domaines La notification d'une interruption est postée à l'entrée du pipeline. Elle parcourt ensuite le pipeline. Les différents domaines sont placés les uns à la suite des autres, en fonction des priorités qui leurs ont été attribuées. Le domaine ayant la plus haute priorité reçoit la notification en premier. Chaque domaine décide d'une action : accepter l'interruption (accept) L'interruption est vue par le système contenu dans le domaine et elle est traitée. ignorer l'interruption pour le moment (stall) L'interruption n'est pas traitée immédiatement par le domaine. Par exemple, le domaine se protège de l'irruption d'interruptions pendant qu'il effectue un traitement particulier. se défausser de l'interruption (discard) L'interruption passe au domaine suivant comme si le système n'en avait pas eu connaissance. terminer une interruption (terminate) L'interruption n'est plus propagée aux domaines suivants. Une fois que le traitement a été mené par la routine d'interruption du domaine, le domaine concerné fait appel à un service de Adeos. Ce service autorise le domaine suivant dans le pipeline à prendre le contrôle du CPU et donc, de faire les traitements 33/104

34 nécessaires. Il a été évoqué la possibilité que le système soit dans l'incapacité de recevoir une interruption. Pour éviter que les notifications d'interruptions soient perdues pour le domaine, elles sont enregistrées dans une zone qui servent de «tampon» pour le domaine. Cette zone est appelée «log» d'interruption. Une fois que le système est de nouveau capable de traiter les interruptions, il tente de traiter toutes les interruptions en attentes. Cette étape permet de re-synchroniser les domaines Gestion du temps-réel L'utilisation d'adeos Xenomai repose sur le système Adeos. Lors du patch du noyau, il est définit par défaut quatre domaines pour Adeos. Dans le premier domaine, le système temps-réel prend place (Xenomai utilise la dénomination de «nucleus»). Dans le second domaine, un système de type GNU/Linux fonctionne. Les deux autres domaines ne sont pas utilisés. Le noyau Linux est de type GPOS6. Il est pratique d'avoir un tel noyau car il bénéficie d'un support matériel important (nombre de pilotes de périphériques). De plus, il permet de faire fonctionner des tâches Linux courantes. On a le bénéfice d'un système polyvalent (GNU/Linux), utilisé avec un système spécifique pour le temps-réel (Xenomai). Illustration 11 : Xenomai et le noyau Linux 6 GPOS : General Purpose Operating System 34/104

35 L'utilisation d'adeos - L'utilisation d'adeos Le schéma 11 illustre les deux domaines (contenant respectivement Linux et Xenomai), fonctionnant au dessus d'adeos. On peut donc utiliser des applications spécifiques pour chacun des domaines. Puisque le système Adeos utilise une couche d'abstraction matérielle, il est relativement indépendant du matériel qui est sousjacent. Grâce au mécanisme de pipeline d'interruption (décrit au paragraphe ), Xenomai (qui est dans le domaine primaire) reçoit tout les événements avant le noyau Linux (qui se trouve dans le domaine secondaire). Xenomai peut donc traiter les interruptions immédiatement, quel que soit l'état du noyau Linux (même si, par exemple, le noyau utilise le mécanisme de «masque» du processeur pour cacher les interruptions). Xenomai peut aussi privilégier le contrôle de ses fils d'exécution, quels que soit le domaine où ils résident. Ceci permet de garantir des temps de latence inférieurs à la micro-seconde, quel que soit la tâche menée par le noyau Linux. Dans la figure 11, on observera que Adeos doit se situer entre la couche d'abstraction matérielle et Xenomai. La majorité des requêtes que doit traiter Adeos viennent donc de cette couche. En pratique, les services ont été implémentés dans des fichiers qui sont ajoutés aux sources du noyau Linux au cours du patch7. Les fonctions spécifiques qui sont implémentées commencent généralement par le préfixe «rthal_». Dans le cas des systèmes de type ARM, il faut explorer les fichiers kernel/xenomai/arch/generic/hal.c et arch/arm/xenomai/hal.c des sources patchées du noyau Linux L'architecture de Xenomai Le micro-noyau de Xenomai («nucleus») est en fait une abstraction de noyau tempsréel (RTOS) reposant sur : des structures de données des services (des méthodes) des flags Parmi les structures de données qui sont manipulées par Xenomai, on peut retenir : «xnthread_t» qui est l'abstraction de tâche temps-réel, «xnsynch_t» qui est un objet générique permettant de synchroniser des tâches, «xntimer_t» qui est un implémentation générique de compteur temporel. Parmi les différents services qui sont proposés par Xenomai, il faut comprendre au moins le «pod» et le «regsitre». Le pod (dénommé «xnpod» dans l'implémentation) est l'abstraction qui s'occupe du management des tâches temps-réel. C'est cette abstraction qui est responsable de la création et de la suppression des tâches (des structures «xnthread_t»), du changement de la politique d'ordonnancement, de l'appel à l'ordonnanceur... C'est un des éléments central du noyau temps-réel. Le registre est un moyen de partager facilement les descripteurs d'objets. Lorsqu'un 7 En effet, Adeos (et donc, le système Xenomai) repose sur l'application d'un patch sur les sources du noyau Linux. 35/104

36 objet est créé, simultanément, une entrée est créée dans un registre. Ensuite, tout autre service qui veut utiliser l'objet utilise le nom symbolique (de l'objet) pour retrouver l'entrée correspondante dans le registre. Le nom de l'objet sert de «clé» pour retrouver l'entrée dans l'index. C'est finalement la structure identifiant l'objet, dans le registre («xnhandle_t»), qui contient le descripteur de l'objet. La structure d'index partagé permet de centraliser les données Les modes d'exécution Il est généralement fait état du mode d'exécution primaire et secondaire. Le premier traduit le fait que les fils d'exécution s'exécutent au dessus du domaine de plus forte priorité (le domaine contenant Xenomai). Le second traduit le fait que les fils d'exécution s'exécutent dans l'espace utilisateur courant (le domaine Linux) La migration des fils d'exécution Xenomai dérive ses «threads» (xnthread) de la structure de «thread» (task_struct) implémentée dans Linux. En fait, un processus se voit attacher une structure particulière (appelée «real-time shadow») lorsqu'elle fonctionne dans le domaine primaire. Une telle architecture permet à une tâche temps-réel d'être ordonnancée indifféremment par l'un ou l'autre des domaines. C'est ce qui autorise la «migration» des tâches entre les domaines. Une tâche temps-réel qui fait un appel système ne pouvant pas être traité par Xenomai est «migrée» dans le domaine Linux pour répondre à sa demande. Elle reste dans le domaine correspondant pour le reste de son exécution (pour ne pas pénaliser la latence du système par la charge apportée lors de la migration de la tâche) tant qu'elle ne fait pas un appel temps-réel. Lorsqu'une tâche temps-réel du domaine Xenomai s'exécute au dessus du domaine Linux, elle reste considérée comme telle. En effet, les priorités des tâches temps-réel de Xenomai s'échelonnent entre 1 et 99. Dans le système Linux, les tâches peuvent avoir une priorité s'échelonnant entre 1 et 139. Sachant que les tâches courantes ont une priorité comprise entre 100 et 139 et que les tâches dont la priorité est inférieure à 100 sont considérées comme temps-réel. Cela permet d'avoir une correspondance des priorités et garantie l'ordonnancement prioritaire. Toutefois, cela peut les pénaliser puisqu'elles sont soumises aux latences du système Linux. Un autre des avantages de la réutilisation de la structure de thread Linux apparaît lors de la période de développement d'une l'application. Un processus temps-réel peut continuer à être tracé à l'aide d'une application de déboguage, quel que soit le domaine où il s'exécute Le temps-réel dans le mode secondaire Si une tâche est considérée comme temps-réel, il faut que sa priorité soit renforcé quel que soit son domaine d'exécution. Par exemple, une tâche s'exécutant dans le domaine primaire (donc, temps-réel) doit pouvoir être préempté par une tâche de plus haute priorité s'exécutant dans le domaine secondaire. Par contre, lors d'une tentative d'accès au CPU, une tâche non temps-réel (donc, pas connue par Xenomai) doit toujours être préemptée au profit d'une tâche temps-réel du premier domaine. 36/104

37 Le temps-réel dans le mode secondaire - Le temps-réel dans le mode secondaire Toutefois, lorsque le second domaine ordonnance ses processus et décide de celui qu'il va exécuter, toutes les tâches (temps-réel ou non temps-réel) rentrent en compétition. Il faut comprendre qu'une tâche temps-réel dans le second domaine, bien qu'ayant une priorité plus élevée qu'une tâche quelconque, devra régulièrement laisser sa place pour l'exécution d'autres tâches. Le système Linux conserve son caractère de système multi-tâches. Les tâches doivent être préservés des problèmes d'inversion de priorité. Xenomai le fait nativement, mais seul le noyau Linux patché avec PREEMPT_RT permet cette protection. Il faut donc continuer à vérifier les différents cas si l'on utilise un système Xenomai basé sur la branche principale du noyau Linux API temps-réel Les «Skins» Les applications industrielles embarqués ont généralement demandées un effort de déboguage et d'optimisation important avant d'atteindre leurs formes stables. Au sein d'une entreprise, les personnes compétentes dans le domaine du temps-réel ne peuvent pas forcément être employées dans un processus de portage long et contraignant. Les équipes de développement ne sont pas prêtes à changer la base de leurs applications : le changement d'api représente une charge de travail trop importante (changement de nombreux appels de fonctions, modifications des objets manipulés...). Pourtant, bien que présentant des différences subtiles, les objets ou les concepts qui sont utilisés dans les API propriétaires sont sensiblement équivalents (mutex, appels systèmes, tâches de synchronisation, ordonnancement). Il a donc été crée des objets génériques dans l'environnement de Xenomai et des couches sont rajoutées qui implémentent la grammaire ou les mécanismes spécifiques de chaque API. Ces couches sont appelées «skins» et miment le comportement d'un certain nombre d'apis temps-réels (POSIX b, psos+, RTAI, uitron, VRTX, VxWorks). Les «skins» se présentent comme des modules noyau qui peuvent être chargés au besoin. On peut aussi décider que ces fonctionnalités soient intégrées dans le noyau au moment de la compilation plutôt que d'avoir des modules L'API native temps-réel Xenomai propose sa propre API pour la réalisation d'applications temps-réel. Cette API se veut relativement succincte et laisse au programmeur le choix d'agencer les fonctionnalités de bases pour créer des mécanismes évolués. 37/104

38 Illustration 12 : Appels systèmes temps-réels depuis l'espace utilisateur et l'espace noyau Les appels systèmes invoqués par les applications temps-réels dans l'espace utilisateur sont redirigés vers le noyau depuis l'espace utilisateur grâce à une librairie spécifique de Xenomai : libnative.so. On peut créer des modules temps-réels qui font appels aux services du micro-noyau. Cette approche, qui ressemble à celle préconisée par d'autres système temps-réel (RTAI, notamment), n'est pas à privilégier. Il est préférable d'avoir des applications temps-réels, évitant ainsi que le noyau ne soit complètement bloqué (et impose un redémarrage du système) à cause d'une erreur d'exécution du module temps-réel. Dans cette API, on fait appel aux services apportés par le noyau temps-réel à l'aide d'appels systèmes spécifiques. Parmi ces appels, on retrouve : le management des tâches temps-réel Il existe un certain nombre d'appels systèmes pour créer ou détruire des descripteurs de tâches temps-réels. La création et le démarrage des tâches est indépendant (à l'opposé de l'api POSIX, par exemple). Il est ainsi possible d'imaginer des fonctions qui se chargent d'initialiser tout les objets et d'autres qui se chargent de les détruire. Le lancement des traitements est alors clairement indiqué à l'endroit où l'opération doit être effectuée. Il est possible d'introduire des mécanismes d'attentes entre les tâches. On peut aussi explicitement déclarer une tâche comme étant périodique, ou lui imposer un délai d'attente. Il est possible qu'une tâche fasse des appels à l'ordonnanceur, pour elle même ou pour une autre tâche. On peut donc imaginer un modèle où une tâche principale coordonne l'activité de toutes les 38/104

39 L'API native temps-réel - L'API native temps-réel autres. la gestion du temps Les principaux mécanismes consistent à gérer des compteurs de temps. La particularité de l'api Xenomai se situe dans sa capacité à adresser une horloge plusieurs horloges, en fonction des besoins de l'utilisateur. De plus, il est possible, au moment de la compilation, de choisir si l'horloge système compte le temps en «ticks» ou en unité de temps (nano-seconde, par exemple). L'API propose alors des méthodes de conversions. Le fait de ne compter qu'en «ticks» système permet de réduire la charge en ce qui concerne la conversion des données brutes en unités compréhensibles à un niveau macroscopique. Par contre, il faut évaluer l'effet des masquages d'interruptions et l'irrégularité apportée à la base de mesure. la synchronisation entre tâches Dans cette section, il faut prendre en compte les méthodes qui permettent d'utiliser des «mutexs», des «sémaphores». Ce sont essentiellement les appels pour créer l'objet, le retrouver depuis son nom symbolique, le détruire et effectuer les opérations de bases de cet objet (acquérir ou libérer, dans le cas des «mutex»). la communication entre tâches La communication entre les tâches peut se faire par le biais de files de messages, de tubes inter-processus (IPC) ou de portions de mémoire partagées. Le premier mécanisme est généralement utilisé au sein d'un même programme qui est multi-threadé. Le second est utilise entre deux (ou plus) processus indépendant qui ne se connaissent pas nécessairement au moment du démarrage Real-Time Driver Model RTDM est un «skin» spécifique pour la gestion des entrées/sorties sur périphériques. Par exemple, il permet de créer des modules ou des drivers de périphériques ayant des contraintes temps-réel qui sont portables. En effet; les modules implémentés utilisent une API commune. 39/104

40 40/104

41 Travail réalisé Portage et évaluation de Xenomai sur une plateforme PC/104

42 1. Environnement de développement Parce que le matériel et les performances du système embarqué ne sont pas suffisantes pour développer les logiciels nécessaires (car, pas destinées à cet usage), on choisit généralement de déporter le développement sur un ordinateur plus puissant. Le choix au sein du centre de service elise est de faire le développement sur un ordinateur de type PC. Ce système hôte, sur lequel j'ai effectué le développement du système (récupération des sources, paramétrage, compilation...), fait fonctionner la version la plus à jour de la distribution Ubuntu. De cette façon, il n'y a pas de différences entre le type du système hôte et du système cible (tout deux de type Linux). Pour effectuer le portage de Xenomai, j'ai du commencer par organiser mon environnement de développement. Ensuite, j'ai du apprendre à utiliser des outils spécifiques au développement. Enfin, j'ai installé les outils de compilation croisée 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'intérieur de ce dossier, on trouve les sous-dossiers suivants : archives/, build/, conf/, debug/, images/, rootfs/, sysapps/, tmp/. archives/ Ce dossier contient les archives sous forme compressées des fichiers sources que j'ai utilisé. Par exemple, on y retrouve l'archive du compilateur croisée. Ainsi, on conserve une trace des ressources utilisées pour de futurs développements. build/ À l'intérieur de ce dossier se trouvent les fichiers issus des compilations du noyau (et donc, de Xenomai). Je conservais ainsi les dossiers des sources de Linux et de Xenomai, vierges des binaires de compilations. conf/ Pour éviter de retaper les mêmes commandes d'une fois sur l'autre, j'ai fait un certains nombres de scripts Bash. J'ai décidé de les placer dans ce dossier. debug/ Pour le test de l'environnement de Xenomai, j'ai eu besoin de faire la compilation croisée de quelques applications de déboguage. J'ai donc placé les exécutables correspondants dans ce dossier. images/ La compilation du noyau génère beaucoup d'objets mais tous ne sont pas utiles dans l'utilisation finale du système. Dans mon cas, je ne gardais que le fichier binaire du noyau, le fichier binaire compressé du noyau, la table des symboles, le fichier de configuration (.config). rootfs/ Ce dossier contient l'architecture d'un système de fichier selon la norme du FHS et les fichiers utiles à tous les types de systèmes. On y retrouve, par exemple, le fichier /etc/fstab, les fichiers de la libc, les fichiers de périphériques). sysapps/ Ce dossier contient les sources des applications intégrées dans le 8 Voir dans la Bibliographie 42/104

43 L'arborescence de travail - L'arborescence de travail système. Par exemple, je conservais les sources de BusyBox ou de SysVinit dans ce dossier. Il contient aussi les portions de code que j'ai créé pour utiliser les API temps-réels. tmp/ Traditionnellement, ce dossier contient des fichiers temporaires (tentatives ou essais de compilations, développements...). Dans un premier temps, j'avais décidé de suffixer certains de ces dossiers (les dossiers build/ et rootfs/) par les terminaisons _xeno ou _std pour en expliciter le contenu (pour indiquer qu'ils contiennent des documents liées à Xenomai ou à leurs versions «standards»). En fait, j'ai été amené à faire plusieurs compilations d'un même type de système avec des paramètres de compilation différents. J'ai donc changé de pratique. J'ai inséré trois sous-dossiers : Branches/, Tags/, Trunk/. Ces trois sous-dossiers sont habituellement rencontrés dans les projets de développement. Le dossier Branches/ me permettait de conserver plusieurs versions différentes. Le dossier Trunk/ du dossier rootfs/ contenait une version du système de fichier dont j'avais la certitude que ses éléments étaient fonctionnels. Le dossier Trunk/ du dossier build/ contenait les éléments de la compilation actuellement menée Les outils Logiciel de suivi de version : git De façon à mettre en place un développement basé sur les dernières versions des sources, il a été décidé d'utiliser le logiciel de suivi de version git 9. Ce logiciel permet de faire une copie locale des fichiers depuis un dépôt. En plus de copier l'arborescence de fichiers du projet que l'on récupère, le logiciel met en place un certains de nombre fichiers qui lui sont propres et qui lui permettent de garder une trace de l'historique du projet. En plus de pouvoir mettre à jour les sources régulièrement, j'ai pu personnellement créer des branches de développement sur le PC hôte. D'abord, j'ai créé une branche contenant les sources du noyau Linux dans leurs version 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 Une fois que les modifications ont été apportées aux fichiers sources, j'ai choisit de les «suivre» grâce à la fonction correspondante du logiciel git. Enfin, j'ai créé une branche spécifique depuis la version des sources Linux pour appliquer une version de Xenomai patchée. Ces patchs m'ont été proposés au cours d'un échange avec la «mailing-list» d'entraide de Xenomai Le système d'information du centre de service Dans le centre de service elise, au sein duquel j'ai travaillé, chaque personne dispose 9 Une présentation détaillée du fonctionnement de git est faite en page 86, en Annexe 43/104

44 de sa propre machine pour effectuer son travail. Toutefois, tout les postes sont en réseau et peuvent accéder à des ressources communes, disponibles sur un serveur. Le serveur est appelé «gforge». En plus de pouvoir récupérer les données depuis le serveur (en faisant de la copie tunnelée par SSH), il a été mis en place un système de montage de dossier par NFS. Ainsi chaque ordinateur peut accéder à un dossier nommé partage dont le contenu est sur le serveur 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 créent une base de connaissance. Ils remplissent les pages de façon collaborative. J'ai créé des pages sur le Wiki, dans la section réservée à Xenomai, décrivant la marche à suivre pour mettre en place l'environnement de compilation, par exemple. une système de gestion de version Trac peut être couplé avec le logiciel de suivi de version Subversion. Lorsque l'on met à jour les fichiers sur le serveur svn, ils apparaissent dans l'interface web. On peut parcourir les éléments sans avoir à les télécharger sur la machine de développement. un système de «billets» Trac un outil accessible de façon décentralisé. Bien que les données et le logiciel qui servent de base à l'architecture soient contenus sur le serveur «gforge», les postes du centre de service peuvent accéder au portail grâce à un navigateur Internet. 44/104

45 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 système d'authentification avec mot de passe. Il est ainsi possible pour des clients de suivre l'avancement d'un projet, depuis ce portail, de façon sécurisée. La combinaison du Wiki et du logiciel de suivi de version est très utile car elle permet de conserver un historique des tâches menées sur une plateforme donnée. Au cours des premiers mois, j'ai souvent utilisé cet deux composants pour voir les opérations qui avaient été menées sur la carte Viper. Je me suis souvent inspiré des méthodes utilisées par le passé (pour la mise en place des outils de compilation croisée, pour la modification du script de démarrage de la carte...) Les outils de compilation croisée Contraintes La compilation vers la carte Viper nécessite des outils capables de fonctionner sur le PC hôte, et capables de produire des binaires compatibles avec le matériel présent sur la carte : ce sont les outils de compilation croisée (compilateur, éditeur de liens...). On notera que le compilateur doit être assez récent pour pouvoir supporter les options de compilation liées au standard EABI. C'est au cours de la première compilation de Xenomai que ce point a été soulevé. J'avais commencé par installer et utiliser les outils fournis sur les Cds livrés avec la carte. Mais la version de cette chaîne de compilation était trop vieille et ne supportais pas les options liées à EABI. Il a fallu 45/104

46 trouver la raison de l'échec de la compilation dans les messages de compilation, puis faire une recherche et récupérer les outils sur le site du support Internet du constructeur de la carte. Lorsque j'ai eu à tester l'environnement Xenomai, j'ai du activer une fonctionnalité spécifique de Xenomai. Le fait d'activer cette fonctionnalité a, de nouveau, soulevé des problèmes de compilation. L'un des mainteneurs du projet Xenomai m'a indiqué que le problème était dû à la chaîne de compilation. Cette fois-ci, la version du compilateur était trop récente et était sensible à certains paramètres. J'ai donc décidé de changer à nouveau d'outils et d'utiliser ceux qu'il me garantissait comme fonctionnels Dépaquetage L'installation des outils est très simple. On commence par aller chercher le paquet qui contient les outils, depuis le dossier de partage /media/nfs/partage/viper/ : cp /media/nfs/partage/viper/arm-2008q1-126-arm-none-linux-gnueabi-i686pc-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-linuxgnu.tar.bz Modification des variables d'environnement Les logiciels sont désormais présents dans le dossier /usr/local/arm/arm2008q1/bin/. Pour pouvoir facilement les utiliser, j'ai modifié une variable d'environnement du système. Pour que tout les utilisateurs puissent avoir un accès à ces exécutables, il faut modifier la variable PATH dans le fichier /etc/environment de la façon suivante : PATH="/usr/local/arm/arm-2008q1/bin:/usr/local/bin[...]" J'ai rajouté le chemin vers les fichiers exécutables de la chaîne de compilation au début de la variable PATH Tests de l'environnement Si l'on veut vérifier la prise en compte de ces manipulations (après redémarrage du système), dans un terminal, on tape : arm-none-linux-gnueabi-gcc --version Cette ligne de commande doit normalement donner un aperçu de la version du logiciel 46/104

47 Tests de l'environnement - Tests de l'environnement et de sa configuration. Pour tester le fonctionnement du logiciel, j'ai mené la compilation de plusieurs autres sources. En particulier, j'ai compilé un noyau Linux non patché et ses modules. Cet exécutable a été utilisé au cours des essais du chargement du noyau par TFTP expliqué dans la partie J'ai aussi compilé le logiciel BusyBox. Le fait que les exécutables (noyau Linux, BusyBox) fonctionnent correctement permet de valider le bon fonctionnement du compilateur, du bon déroulement de l'édition de lien sur la librairie C... On peut considérer qu'un exécutable aussi sensible que le noyau est un test approprié pour la validation. 2. Prise en main de la carte Viper 2.1. Le chargeur d'amorçage : RedBoot Le chargeur d'amorçage (ou «bootloader») est un logiciel de taille généralement faible qui se charge de vérifier le matériel présent sur la carte et d'effectuer des opérations simples de management. Il est aussi responsable du chargement du noyau, et de fait, du système. L'utilisation de «bootloader» est courante dans les systèmes embarqués. En effet, les plus petits systèmes ne disposent généralement pas de BIOS. De plus, les chargeurs d'amorçage sont généralement configurables, plus facilement qu'un BIOS. Le chargeur d'amorçage de la carte Viper (appelé RedBoot) dispose de ces fonctionnalités de base. Il possède aussi un éventail de fonctions plus évoluées accessible depuis une invite de commande (management de la mémoire, gestion de l'horloge...). Par exemple, RedBoot utilise un script pour effectuer le démarrage du système. Ce script est éditable et personnalisable à volonté. Pour modifier le script de démarrage, on tape la commande dans l'invite de RedBoot : RedBoot>fconfig J'ai du apprendre à utiliser cette fonctionnalité essentielle pour autoriser la conservation des éléments du système (noyau et système de fichier) de façon déportée. Pour mieux appréhender cette fonctionnalité, j'ai fait des essais de configurations mixtes (noyau dans la mémoire Flash, système de fichier déporté sur le PC de développement...) ; notamment, avec le précédent noyau Linux qui avait été porté sur la carte. Au cours de ces manipulations, j'ai appris que RedBoot, en commandant le démarrage du niyau, est responsable de certains comportements du système GNU/Linux (choix du périphérique servant de console, vitesses de transferts des données...). Le chargeur d'amorçage RedBoot est dérivé d'un autre chargeur plus connu : ecos. J'ai donc dû rechercher certaines informations sur l'utilisation de ce logiciel dans le manuel de ecos. 47/104

48 2.2. Communication avec la carte Viper La carte Viper ne possède pas d'écran ou de clavier puisque c'est un système qui est censé fonctionner en autonomie lorsqu'il est déployé dans un contexte industriel Liaison série avec C-Kermit La méthode de connexion habituelle est le raccordement du PC de développement et de la carte Viper par un câble série spécifique dit : «null-modem cable». Dans ce câble, la pin d'envoi des données, à l'une des extrémités, est reliée à la pin de réception des données à l'autre extrémité. Il permet à deux ordinateurs de pouvoir s'échanger des données sans avoir besoin d'un modem entre ceux-ci. On peut vérifier le câble avec un simple voltmètre. Pour communiquer avec la carte, on démarre un logiciel d'émulation de terminal. Il a été choisit d'utiliser le logiciel C-Kermit. Ce choix a été dicté par la compatible entre le logiciel d'émulation de terminal et la gestion de la liaison série du logiciel RedBoot. La communication par la liaison série permet indifféremment : de se connecter sur la console de RedBoot d'obtenir les informations de la console de démarrage du noyau Linux de se connecter à la carte Viper lorsqu'un terminal fonctionne sur l'un des ports série de celle-ci L'avantage de cette connexion est la possibilité d'envoyer des caractères d'interruption (du type «Ctrl+C»). Entre parenthèses, c'est ce caractère qui permet de notifier l'interruption du script de démarrage à RedBoot et d'accéder à son invite de commande. J'ai malheureusement eu des problèmes avec cette connexion. En effet, lorsque la carte reste trop longtemps sous tension, il devenait impossible d'avoir des données compréhensibles. Parfois, le logiciel C-Kermit n'affichait plus du tout de données en provenance du port série. Pour trouver la cause de ce problème, j'ai adopté une approche «top-down». J'ai commencé par vérifier que les paramètres du programme (fonctionnant sur le PC) étaient bon : choix du port série, format des données... L'apparition d'un flot de caractères non compréhensibles m'a fait supposer un problèmes de synchronisation ; j'ai donc particulièrement vérifié la vitesse de transmission des données. J'ai ensuite vérifié l'état du câble reliant les deux machines. Puis, tout les éléments précédents étant corrects, j'ai observé ce port série avec un oscilloscope. Je me suis auparavant documenté pour comprendre comment les octets de données sont envoyés sur une liaison série. J'ai découvert que la ligne de communication tombait quasiment au même niveau que la masse après quelques instants de fonctionnement, alors que son état de repos (dans la norme) est un état de tension haut. J'en suis donc arrivé à la conclusion que le contrôleur série de la carte est endommagé Liaison Ethernet et console Telnet Étant donné les problèmes que j'ai pu avoir avec le port série, j'ai décidé d'utiliser un client Telnet depuis le PC hôte, pour se connecter à la carte. J'ai choisit cette solution, 48/104

49 Liaison Ethernet et console Telnet - Liaison Ethernet et console Telnet car ainsi, on utilise ainsi le contrôleur Ethernet de la carte au lieu du contrôleur de la liaison série. De plus, j'ai découvert qu'il était aussi possible d'avoir accès à la console du chargeur d'amorçage par cette méthode. J'ai utilisé deux configurations pour relier le PC à la carte : un câble Ethernet croisé qui relie directement les cartes réseaux des deux machines. Cette configuration ne dépend pas d'un matériel supplémentaire. un concentrateur placé entre le PC et la carte ; les deux machines étant reliées à cet appareil central par des câbles Ethernet droits. Lorsque le système ne démarre pas (pas de noyau présent, par exemple...), le chargeur d'amorçage reste en fonction et présente son invite de commande. Il est possible d'avoir cette invite de commande autrement que par la liaison série. En effet, le chargeur d'amorçage se place en écoute sur le port Ethernet. Je pouvais alors m'y connecter depuis le PC de développement en initiant une connexion Telnet sur le port Ainsi, il faut taper la commande, sur le poste fixe : telnet Trying Connected to Escape character is '^]'. [...] Lorsque le système d'exploitation de la carte est démarré, si un serveur Telnet fonctionne il est possible de s'y connecter par la liaison Ethernet. Si ce serveur a été configuré par défaut, il est en écoute sur le port 23, selon la classification des ports bien connus («well-known ports»). Il suffit alors de donner l'adresse IP de la carte Viper au client Telnet sur le PC de développement : telnet La connexion par Ethernet présente un défaut majeur : on ne peut pas avoir accès aux informations de la console noyau au cours du démarrage. En effet, le noyau est capable d'afficher les informations de démarrage sur un port série car il charge un minimum de support pour une liaison de ce type. La même chose ne peut être faite avec le port Ethernet, ce qui nécessiterait de charger toute la pile réseau au préalable. Entre le moment où RedBoot passe la main au démarrage du noyau et le moment où le système est pleinement opérationnel, il n'y a aucun programme en écoute sur le port Ethernet Configuration de démarrage Le chargement du noyau par TFTP Plutôt que de flasher la mémoire de la carte à chaque nouvelle compilation du noyau, j'ai décidé d'utiliser la capacité du chargeur d'amorçage à récupérer des fichiers depuis un poste distant par le protocole TFTP. On gagne ainsi le temps nécessaire à la 49/104

50 procédure de copie sur la mémoire Flash de la machine. De plus, la mémoire Flash est limitée en terme de nombre de recopies. On évite donc d'user prématurément la puce mémoire. J'ai choisi de le recopier en grande partie le script de démarrage qui était présent à l'origine sur la carte Viper. J'ai modifié deux lignes de façon à rendre la procédure possible : RedBoot>ip_address -l RedBoot>load -r -b %{FREEMEMLO} -h m tftp zimage xeno La première ligne permet au chargeur d'amorçage de paramétrer les connexions réseaux. Le fait d'attribuer une adresse IP à la carte permet à RedBoot de déduire le réseau associé et le masque de sous-réseau. Une fois la configuration réseau effective, il peut aller télécharger (avec la directive «load») le fichier spécifié sur le serveur TFTP se situant sur la machine dont l'adresse IP est donnée. Il place les données à l'adresse mémoire indiqué dans l'alias «FREEMEMLO» Le montage du système de fichier par NFS Pour les mêmes raisons (rapidité de mise à jour du système de fichier sur la cible...), j'ai décidé de conserver l'image du système de fichier sur la machine hôte et de monter ce système de fichier grâce au protocole NFS. Il existe un autre avantage lié à la conservation du système de fichier sur la machine de développement : il y a la possibilité de modifier les fichiers en cours de fonctionnement. J'ai utilisé cette fonctionnalité pendant le développement des applications. Je menais la compilation sur le PC hôte puis je plaçais le code compilé dans l'image du système de fichier pendant son fonctionnement. Cela le rendait immédiatement disponible au système Linux fonctionnant sur la Viper, sans que je sois obligé de flasher la mémoire et de redémarrer le système. Pour commencer, j'ai du vérifier que la capacité de montage du système de fichier par NFS était activée dans la configuration du noyau Linux. Ensuite, j'ai modifié le script de démarrage de RedBoot. Pour simplifier la modification du script en lui-même, j'ai définis un alias qui comporte la ligne de paramètres pour le noyau : RedBoot>alias cmdlinenfs=\""rootfs=/dev/nfs/ root=/srv/nfsboot/ nfsvers=3,tcp ip= : ::::off"\" Ce qui fait que le noyau reçoit cette ligne de paramètres lorsque le script de démarrage exécute la commande : RedBoot>exec -c %{cmdlinenfs} J'ai construit la chaîne de paramètres en me basant sur une précédente chaîne de paramètres définie dans RedBoot. J'ai aussi directement regardé les explications qui sont données dans le fichier kernel-parameters.txt, fournis avec le noyau Linux. 50/104

51 Création du système de fichier - Création du système de fichier 3. Création du système de fichier 3.1. Motivations Au cours des premiers tests, je devais normalement réutiliser un système de fichier existant. Malheureusement, ce système de fichier a été créé de façon à autoriser seulement des sessions utilisateurs avec mot de passe. Les mots de passe n'étaient pas ceux traditionnellement utilisés au sein du centre elise ou fixés par le constructeur de la carte. Pour contourner ce problème, j'ai tenté de passer des arguments au noyau. Pour cela, j'ai modifié la chaîne de paramètres passée au noyau dans le script de démarrage de RedBoot. Par exemple, j'ai tenté de passer l'argument «-S» pour faire initialiser le système en mode utilisateur unique. J'ai découvert que cette option ne permet pas de débloquer le système. En effet, le système de fichier était issus d'un distribution Debian modifiée. Dans les distributions de ce type, le fait de passer l'argument «-S» sous-entend que l'utilisateur unique est l'administrateur du système ; il est tout de même demandé le mot de passe de ce super-utilisateur. J'ai aussi tenté de donner directement le chemin de la première application à lancer grâce au paramètre «init». J'avais donc un alias du type : RedBoot>alias cmdline="init=/bin/sh" Dans ce cas, l'application doit effectivement démarrer mais elle ne se place pas en attente sur le port série. Il n'est donc pas possible d'avoir un environnement de travail depuis l'interpréteur de commande. Enfin, j'ai tenté de faire démarre l'application «getty» de la même façon que précédemment (en donnant le chemin vers cet exécutable). Cette application sert d'intermédiaire : elle se place en écoute sur le port série et est censé démarrer un interpréteur de commande quand elle détecte une connexion. En fait, il est d'abord fait appel à «sulogin» (qui se charge de gérer l'authentification de l'utilisateur) avant de démarrer un interpréteur de commande. J'ai découvert seulement plus tard, dans les pages du manuel, que le programme «sulogin» lis les fichier /etc/passwd et /etc/shadow. C'est pour cela qu'il demande le mot de passe du super utilisateur. Si ces fichiers n'existent pas, le mot de passe n'est pas demandé. Peut-être aurait-il fallu supprimer les deux fichiers pour ne pas avoir de demande de mot de passe. Au final, je n'ai pas réussi à passer outre cette protection par mot de passe. En accord avec mon encadrant, il a été décidé de créer entièrement un système de fichier. Ce choix a été fait pour contrer le problème mais il se révèle, dans le cadre de ma formation, que c'est une démarche instructive pour la compréhension globale d'un système. De plus, dans le cadre des systèmes embarqués, le fait de créer soi-même le système de fichier permet de s'assurer que l'on garde des proportions acceptables en terme de taille mémoire. J'ai fait cela en suivant différentes démarches décrites dans «Building Embedded Linux Systems» ou dans «Linux From Scratch»10 (LFS). 10 Voir dans la Bibliographie 51/104

52 Une autre raison qui conforte dans la création d'une nouvelle arborescence de fichier est la capacité à maintenir et à finement adapter le système à la carte. En effet, j'ai tenté plusieurs fois de copier une arborescence de fichier d'une distribution existante (Debian et OpenSuse) et de la simplifier pour qu'elle s'adapte à la carte, malheureusement, ceci aboutit à des erreurs qu'il est difficile de retracer Squelette de base Les directives du FHS Selon les directives du «Filesystem Hierarchy Standard», un certain nombre de dossiers doivent être présent dans un système de fichier de type Linux/Unix. Ceci permet aux applications de pré-supposer les emplacements d'installation des fichiers ou des dossiers. Cela permet aussi à une personne de maintenir un système en ayant le même type de pré-supposés. Pour les personnes qui connaissent les systèmes de type GNU/Linux, on retrouve l'arborescence de base de ces systèmes. Dans la liste suivante, j'ai détaillé les dossier que j'ai du peupler et dont l'architecture des sous-dossiers et des fichiers a été particulièrement travaillé au cours du stage. bin/ est le dossier qui contient les commandes essentielles au système. dans ce dossier que prennent place les liens vers le logiciel BusyBox, donner l'impression que toutes les applications de la suite CoreUtils présents. J'ai essentiellement vérifié la présence de ces liens et le fait pointaient bien vers le binaire de l'application. boot/ est le dossier qui contient le noyau et les configurations nécessaires au démarrage. Je n'ai pas placé les fichiers du noyau puisque j'ai essentiellement utilisé le chargement du noyau par TFTP. J'avais créé ce dossier dans le but de tester le système en totale autonomie sur la carte Viper. dev/ est le dossier qui contient les fichiers de périphériques. Je l'ai peuplé de façon statique (sans utilisation du logiciel udev) pour qu'il contienne les fichiers de périphériques usuels et ceux dont j'avais besoin pour accéder au matériel présent sur la carte Viper. etc/, ce dossier contient les fichier de configuration du système et des applications. J'y ai mis les différents scripts qui composent le système de démarrage et les fichiers de configuration de applications (en particulier pour les serveurs inetd et telnetd). lib/ est le dossier qui contient les librairies utiles au système. C'est dans ce dossier que j'ai du placer une copie de la libc. Cette version de la librairie C a été utilisé aussi au cours des compilations croisées. root/ est le dossier personnel de l'administrateur système. C'est un dossier optionnel selon les directives du FHS mais que j'ai rajouté puisque j'ai créé ce compte unique dans le système. sbin/ est le dossier qui contient les applications nécessaires au système et/ou utilisées pas l'administrateur du système. Il est nécessaire de créer ce dossier (au même titre que le dossier bin/) pour que BusyBox puisse placer les liens 52/104 C'est pour sont qu'ils

53 Les directives du FHS - Les directives du FHS correspondant à des applications telles que init. tmp/ est un dossier contenant fonctionnement des applications. des fichiers temporaires au cours du usr/, ce dossier correspond aux «UNIX System Ressources». Il contient plusieurs sous-dossiers. En particulier, il comprend un sous-dossier bin/ qui contient les binaires des applications utilisées par les utilisateurs courant. J'y ai placé certaines des applications que j'ai compilé pour la Viper ; en particulier les applications de déboguage (gdbserver et strace). var/, c'est dans ce dossier que prennent place des fichiers susceptibles d'être modifiés par le fonctionnement des applications. En particulier, j'y trouvais le fichier qui sert de log d'erreur pour le système. Les dossiers media/, mnt/, opt/ et srv/ ne sont pas décrit car je ne les ai pas utilisés au cours de l'étude. Puisque j'utilisais un noyau Linux, il a été nécessaire de rajouter deux dossiers. Ces dossiers sont des points de montage pour des systèmes de fichiers virtuels. Ils permettent de faire l'interface entre les programmes (ou les utilisateurs) et le noyau. Ce sont : proc/ Ce système de fichier virtuel recense les informations du système (numéro de version du noyau, matériel, accès aux descripteurs de tâches...) sys/ Ce système de fichier virtuel a sensiblement le même rôle que le précédent. Toutefois, il possède une présentation du matériel de façon hiérarchique qui est plus compréhensible Les fichiers de périphériques Le livre «Building Embedded Systems» rappelle qu'un certain nombre de «nœuds» doivent être présents dans le système de fichier. L'ouvrage rappelle aussi que les numéros majeurs et mineurs nécessaires pour la création des fichiers de périphériques sont contenus dans le fichier devices.txt du dossier Documentation/ des sources du noyau Linux. En suivant ces directives, j'ai créé les fichiers de périphériques suivant : console : interface d'affichage des informations du noyau mem : interface avec la mémoire du système null : périphérique virtuel dont l'écriture est toujours possible random : périphérique de génération de valeur aléatoire zero : périphérique virtuel dont la lecture est toujours possible Parmi les fichiers basiques, j'ai dû ajouter ceux utilisés par les consoles (dénommés tty*). En plus des consoles, puisque la communication avec la carte s'est faite dans un premier temps par la liaison série, j'ai créé les fichiers correspondants aux consoles séries (dénommés ttys*). Étant donné que la commande pour créer ces fichiers est quasi identique, j'ai décidé d'automatiser ce processus et de créer un script. Il comporte les lignes suivantes : 53/104

54 for i in {{0..4},{64..67}} ; do if [ $i -lt 64 ] ; then j=$i else j="s$(($i-64))" fi mknod -m 600 tty$j c 4 $i done J'utilise la liste des numéros mineurs au sein de la boucle «for». Selon que le numéro mineur est inférieur (pour les terminaux) ou supérieur (pour les terminaux série) à 64, je modifie l'indice qui apparaît à la suite de la chaîne de caractères «tty». J'ai du aussi créer un dossier /dev/pts/ qui est monté au cours du démarrage. Il permet de créer des pseudo-terminaux. Les pseudo-terminaux étant des programmes qui simulent le fait que l'on se connecte à un terminal. Il était nécessaire de créer et de monter ce dossier au démarrage, en particulier pour pouvoir utiliser Telnet. Enfin, j'ai créé quatres liens symboliques dans le dossier /dev/. Un programme, au cours de son exécution, doit pouvoir accéder à son entrée standard et à ses sorties (standard et erreur). Ainsi, j'ai d'abord commencé par créer /dev/fd qui est un lien symbolique vers /proc/self/fd, puis j'ai rajouté les liens vers les descripteurs de fichiers usuels : entrée standard (stdin), sortie standard (stdout), sortie d'erreur (stderr). J'ai rajouté ces opérations dans le script précédent en ajoutant : ln -s /proc/self/fd /dev/fd j=0 for i in {in,out,err} ; do ln -s /dev/fd/$((j++)) /dev/std$i done 3.3. Applications Un certain nombre d'applications sont absolument nécessaires pour faire fonctionner un système GNU/Linux SysVinit Les systèmes de type GNU/Linux utilisent généralement le système de démarrage dit «SysVinit» (comprendre «System V init», en rapport avec l'apparition de ce système dans la version 5 de Unix distribuée par AT&T). Particulièrement, la procédure de démarrage nécessite la présence de l'application (init). D'autres outils sont aussi utilisés pour gérer l'extinction du système. 54/104

55 SysVinit - SysVinit J'ai commencé par récupérer les sources de ce système. Puis, j'ai effectué la compilation croisée de toutes les applications composant le système en donnant le nom du compilateur (avec l'option CC) : cd ~/xenomai/sysapps/sysvinit-2.86/src make CC=arm-none-linux-gnueabi-gcc Il est a noter que, dans la logique d'un système embarqué, je n'ai pas installé la documentation associée aux programmes. Pour cela, j'ai parcouru le fichier Makefile pour trouver les opérations correspondant à l'installation des pages du manuel et les commenter pour qu'elles ne soient pas exécutées. Ceci est possible car le fichier a vraisemblablement été rédigé à la main (il n'est pas issu d'une génération automatique). Il reste clair et compréhensible. Il est donc facile de trouver la cible «install» et de commenter les lignes : install: [...] for i in $(MAN1); do \ $(INSTALL) -m 644../man/$$i $(ROOT)$(MANDIR)/man1/; \ done [...] Une fois ces lignes commentées, j'ai installé les programmes dans le futur système de fichier de la carte (grâce à l'option ROOT). J'ai donné en paramètres le numéro d'identifiant et le numéro du groupe de référence de mon identité sur le PC de développement. Cela évite de donner l'appartenance de ces applications au super utilisateur et de devoir changer d'identifiant pour éditer les applications au cours du développement. make BIN_OWNER="$(id -un)" BIN_GROUP="$(id -gn)" \ >ROOT=~/xenomai/rootfs install BusyBox Les systèmes embarqués disposent généralement de peu de mémoire ; que ce soit de la mémoire vive (utile au cours du fonctionnement) ou de la mémoire Flash (pour la sauvegarde des données lorsque le système est hors tension). Pour donner un ordre d'idée, la carte que j'ai utilisé au cours de mon stage possède 64Mo de SRAM et 32Mo de Flash11. Pour répondre à ces contraintes, il a été développé le logiciel BusyBox. Il regroupe dans un seul exécutable une grande majorité des commandes usuelles (cat, rm, ls...) qui composent la suite de logiciels appelée GNU Core Utilities. Plutôt que de compiler le paquet coreutils, il a été choisit d'utiliser cette application. 11 Un présentation détaillée la carte Viper est faite en page 80, en Annexe 55/104

56 C'est pour cela que j'ai récupéré les sources de ce logiciel avec git : cd ~/xenomai/sysapps git clone git://busybox.net/busybox.git Il faut introduire le fait que BusyBox implémente une version simplifié de init. Malheureusement, dans une première version de mon système de fichier, je n'ai pas réussit à faire fonctionner cette implémentation de façon à ce que les scripts de démarrage soient exécutés. Des recherches sur Internet ont soulevées que ce problème était courant : l'application BusyBox semble n'utiliser que le fichier /etc/inittab et n'exécute pas les scripts qui peuvent apparaître dans ce fichier. Hors, suite au problème de connexion série12, j'avais besoin que le processus init soit capable de configurer les interfaces réseau et de démarrer un serveur Telnet, ce qu'il ne faisait pas. J'ai donc décidé d'utiliser SysVinit pour le démarrage et BusyBox pour les autres applications. J'ai donc dû prêter attention à la configuration de compilation de BusyBox. J'ai commencé par appliquer la configuration par défaut. Ensuite, j'ai recensé les applications présentes dans SysVinit. Finalement, j'ai configuré BusyBox de façon à ce que les différents liens qui auraient pu entrer en conflit ne soient pas créés. Pour appliquer la configuration par défaut, il faut donner la cible «defconfig» à make. Le reste de modifications se fait de manière interactive en utilisant le menu de configuration. Il faut donc donner la cible «menuconfig» à make : cd ~/xenomai/sysapps/busybox make CROSS_COMPILE=gnu-none-linux-gnueabi- ARCH=arm defconfig make CROSS_COMPILE=gnu-none-linux-gnueabi- ARCH=arm menuconfig Puis, j'ai compilé le logiciel en donnant la cible «install» de façon à ce que les objets compilés soient installés dans le squelette de l'arborescence de fichier système (grâce à l'option CONFIG_PREFIX) : make CROSS_COMPILE=gnu-none-linux-gnueabi- ARCH=arm \ >CONFIG_PREFIX=~/xenomai/rootfs install Une fois ces opérations terminés, j'ai pu vérifier qu'il n'a été créé qu'un seul exécutable (qui a été placé dans le dossier /bin/). Toutes les autres commandes sont en fait des liens symboliques vers cet exécutable : 12 Voir la partie /104

57 BusyBox - BusyBox ls -l ~/xenomai/rootfs/bin lrwxrwxrwx 1 root root addgroup -> busybox lrwxrwxrwx 1 root root adduser -> busybox lrwxrwxrwx 1 root root ash -> busybox -rwxr-xr-x 1 root root busybox [...] 3.4. Démarrage Le choix du système rc La procédure de démarrage des systèmes GNU/Linux repose sur le programme init et une architecture de scripts de démarrage. Le programme init est le premier programme à être invoqué par le noyau. Ce programme va lire le fichier de démarrage /etc/inittab dans lequel apparaît différentes règles. Ces règles régissent le lancement d'applications ou l'exécution de scripts. Il existe essentiellement deux systèmes de démarrage. Le premier, dit SysVinit, se retrouve dans les distributions Linux courantes (Ubuntu, Debian, Fedora, OpenSuse) avec plus ou moins de variations. Le deuxième est dit «système rc» est plutôt originaire des systèmes de type «BSD13». J'ai tenté plusieurs fois de mettre en place un système de démarrage du premier type, parce que je pensais utiliser la distribution Ubuntu sur laquelle je travaillais. Je pensais copier système existant et le simplifier pour qu'il réponde à mes besoins. Malheureusement cette approche laisse souvent des erreurs dans les scripts. Ces erreurs sont ensuite difficile à retracer. De plus, la distribution Ubuntu a adopté un processus de démarrage différents de la norme SysVinit et pour lequel il est difficile d'avoir des informations sur Internet. J'ai donc pensé créer entièrement le système pour la carte en simplement en copiant l'esprit du démarrage de SysVinit. Je me suis basé sur des distributions qui étaient plus respectueuses de la norme : OpenSuse ou Fedora, par exemple. Le problème de ces distributions est la complexité inhérente à l'accumulation des années de développement. J'avais donc du mal à faire ressortir les commandes nécessaires de celles plus optionnelles. Pour illustrer le degré de complexité des architectures de démarrage, il faut savoir que les distributions citées précédemment proposent généralement un logiciel pour manager les scripts de démarrage. J'ai finalement opté pour le deuxième système de démarrage qui est plus compact et plus simple. Je me suis basé sur les informations données dans le manuel de présentation de la distribution Slackware. En effet, cette distribution Linux implémente un système de démarrage de type BSD. Il faut savoir que la distribution Slackware est en partie issue du projet LFS14. J'avais donc deux sources de documentation pour 13 BSD : Berkeley Software Distribution. Distribution historique développée au sein de l'université de Berkeley depuis le système UNIX 14 LFS : Linux From Scratch. Distribution minimale à développer soi-même. 57/104

58 créer les différents scripts Les sessions utilisateurs Bien que les systèmes embraqués ne soient pas des systèmes interactifs avec des utilisateurs, j'ai trouvé qu'il serait intéressant de configurer au moins un compte : le compte du super-utilisateur. De cette manière, à l'ouverture de session, un mot de passe est demandé et protège l'accès au système. La mise en place des sessions utilisateurs repose sur la présence de trois fichiers : /etc/passwd, /etc/shadow, /etc/group. Je me suis basé sur les fichiers de la distribution Ubuntu que j'utilisais pour le développement. J'ai supprimé de nombreux comptes et groupes qui n'étaient pas utiles pour le système que je mettais en place. Par exemple, sur les distributions Ubuntu, il est définit un groupe ayant la possibilité de créer des tâches périodiques (démarrées périodiquement par le démon «cron»). De cette façon, seuls les utilisateurs qui appartiennent à ce groupe peuvent ajouter des tâches périodiques dans le «pool» du démon. Toutefois, cette fonctionnalité n'étant pas présente et pas utile sur le système, j'ai enlevé le groupe correspondant. L'initialisation du compte de super-utilisateur s'est fait en trois étapes : 1. j'ai créé un fichier vide pour contenir les mots de passe 2. j'ai donc démarré le système sans le système de comptes utilisateurs 3. j'ai ajouté le mot de passe de l'administrateur en utilisant la commande passwd Le serveur inetd Le serveur inetd est couramment appelé le «super-serveur». Il permet de remplacer l'écoute de tous les serveurs sur un système disposant de peu de ressources. En effet, il se place en écoute sur tout les ports de la machine. C'est seulement lorsqu'une requête arrive sur l'un des ports qu'il démarre le serveur correspondant pour répondre à la demande. Dans la logique d'un système embarqué (donc, disposant de peu de ressources), j'ai décidé de mettre en place une telle architecture. Pour cela, j'ai utilisé l'implémentation du serveur inetd par BusyBox. Le serveur inetd ne démarre en fait que les serveurs spécifiés dans un fichier de configuration appelé inetd.conf. Dans ce fichier, il est précisé : le type de service (ce qui va déclarer le numéro du port d'écoute par défaut) le type de données échangés le protocole de communication utilisé la manière dont doit se comporter le serveur à la réception d'une requête le chemin vers l'exécutable du serveur la ligne de paramètre à passer au serveur J'ai cependant du adapter la ligne de ce fichier à cause de BusyBox. En regardant le fichier de configuration, on voit que l'on donne la chaîne de paramètre «telnetd 58/104

59 Le serveur inetd - Le serveur inetd i» au serveur Telnet, ce qui semble absurde : # Telnet server: telnet stream tcp nowait root /usr/sbin/telnetd telnetd -i En fait, le fichier /usr/sbin/telnetd n'est qu'un lien vers BusyBox. Hors, BusyBox fonctionne de la façon suivante : il décide de mimer l'exécution du programme dont il reçoit le nom comme premier argument. Donc, selon la rédaction que j'ai faite du fichier, la ligne de commande suivante est exécutée (après remplacement du lien par l'exécutable pointé) et prend tout son sens : busybox telnetd -i Le serveur Telnet L'implémentation simplifiée du serveur Telnet par BusyBox nécessite : la présence du dossier /dev/pts/ (comme indiqué au point ) le montage des pseudo-terminaux dans ce dossier le fichier de périphérique /dev/ptmx Ces nécessités n'apparaissent ni dans les pages du manuel de cette application ni dans dans celles de BusyBox. Au départ, je n'avais créé aucun de ces éléments et je n'arrivais donc pas à faire fonctionner le serveur Telnet. J'ai du chercher sur Internet quel était le problème. En fait, j'ai trouvé la solution indirectement, en cherchant une explication sur la notion de pseudo-terminal. Illustration 14 : Pseudo-terminal lors d'une connexion Telnet entre de deux machines Lorsqu'un client Telnet envoi une requête à un fait par un réseau de type Ethernet. Le serveur est monté dans le dossier /dev/pts/ de la Lorsqu'une demande d'initialisation de session serveur Telnet, la communication se possède un descripteur de fichier qui machine sur laquelle il fonctionne. est faite (par le client), le serveur 59/104

60 Telnet lance le programme responsable de cette tâche. Le programme qui initie les sessions utilisateurs (identification, puis lancement d'un interpréteur de commande) s'appelle getty. Lorsque cet outil démarre, il s'attache à une interface lui donnant l'impression qu'il est raccordé à un terminal série. En l'occurrence, il tente d'ouvrir le périphérique raccordé au fichier /dev/ptmx. Comme le montre le schéma 14, la notion de pseudo-terminal apparaît dans le mécanisme qui relie le périphérique ouvert par le programme getty (/dev/ptmx) au descripteur de fichier détenu par le serveur Telnet (et monté dans le dossier /dev/pts/). Cette notion cache au programme getty que la communication ne se fait pas par le biais d'un terminal, mais par le réseau Ethernet. Une fois que j'ai découvert cette nécessité, j'ai rajouté le dossier et le fichier dans le dossier /dev/. J'ai aussi rajouté, dans l'un des scripts de démarrage que j'ai écrit, une opération analogue à : mount -t devpts devpts /dev/pts À l'instar du montage du système de fichier /proc/, j'ai découvert que le paramètre indiquant le périphérique source (dans ce cas, le deuxième «devpts») est ignoré par la commande mount. Toutefois, il est plus intéressant de donner le nom «devpts» plutôt que «none», s'il la commande se termine en erreur et qu'un message est affiché dans la console du système. 4. Portage de Xenomai 4.1. Manipulations sur le noyau Linux Patch du noyau Xenomai se présente sous la forme d'un patch de noyau Linux. Dans ce sens, j'ai exécuté le script de préparation sur le dossier contenant les sources du noyau Linux. Cette opération est détaillée dans un fichier (README.INSTALL) à la base de l'arbre des sources de Xenomai. J'ai adapté la commande de façon à ce que l'architecture du système cible soit la bonne : ~/xenomai/xenomai-2.4/scripts/prepare-kernel.sh \ >--linux=~/xenomai/linux y \ >--arch=arm \ >--adeos=~/xenomai/xenomai-2.4/ksrc/arch/arm/patches/adeos-ipipe arm patch Dans cette commande, on indique trois paramètres : 1. la location des sources du noyau Linux (option --linux) 2. l'architecture cible (option --arch) 60/104

61 Patch du noyau - Patch du noyau 3. la location du patch Adeos qui va être appliqué (option --adeos) En guise de travail préparatoire, j'ai utilisé les commandes du logiciel (de suivi de version) git pour que les fichiers des sources du noyau soient tels qu'à la version Sinon, les mises à jour successives et les patchs appliqués depuis cette version introduisent trop de différences dans les fichiers sources, et l'application du patch se termine en erreur. On notera que le patch se présente comme un fichier texte qui répertorie les fichiers et les lignes de code à modifier. La symbolique de ces fichiers est relativement simple : la position du changement est encadré par une double répétition du symbole Les lignes qui sont ajoutées sont précédées du symbole «+» tandis que celles qui sont enlevées sont précédées du symbole «-». Les autres lignes de codes sont la pour fournir un contexte. Une bonne pratique pour vérifier l'application du patch était de choisir un fichier modifié et de cibler une modification effectuée dans celui-ci. Il me suffisait ensuite de regarder dans le fichier, à la position indiquée, et de vérifier que les modifications étaient effectives 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 matérielle choisie, à la manière d'une liste de paramètres. Cette opération se fait avec la commande : make viper_defconfig Des fichiers par défaut, pour les architectures ARM supportées par la communauté de développement du noyau Linux, se trouvent dans le dossier arch/arm/configs/ des sources. Le précédent responsable du centre elise avait effectué le portage du noyau Linux sur la carte Viper. Il avait donc créé le fichier de configuration par défaut de la carte et l'avait soumis à la communauté. J'ai du adapter la configuration du noyau (à partir de cette configuration par défaut) pour répondre parfaitement aux contraintes de Xenomai. Par exemple, j'ai du enlever les options qui permettent normalement d'avoir une diminution de la consommation d'énergie : l'adaptation de la fréquence du processeur en fonction de la charge et la mise hors tension des périphériques lorsqu'ils sont inactifs. Ces deux options sont susceptibles d'induire des variations dans la fréquence de rafraichissement des horloges du systèmes et donc, peuvent créer des latences non désirées. Ce point particulier est soulevé dans le fichier TROUBLESHOOTING, présent dans les sources de Xenomai Compilation du noyau Le processus de compilation du noyau est une tâche complexe, qui nécessite de compiler de nombreux systèmes (gestion de la mémoire, gestion du réseau...), euxmêmes constitués de nombreux fichiers sources. Pour automatiser la compilation, une arborescence de fichiers Makefile a été développé au cours des années. Ce système 61/104

62 (couramment dénommé «kbuild») propose aussi un certains nombre de cibles (par l'intermédiaire des «Makefile») pour aider le développement du noyau. J'ai utilisé les fonctionnalités de ce système au cours du processus de portage de Xenomai. Par exemple, pour garder les sources du noyau aussi propres que possible au cours des différentes compilations, j'ai systématiquement passé une option à make. Cette option indique que les résultats de compilation doivent mis dans un autre dossier que le dossier contenant les sources. Ainsi, j'évitais que des objets issus d'une précédente compilation ne viennent poser des problèmes lors de la compilation en cours. La ligne de commande permettant de lancer la compilation du noyau et de ses modules ressemblait donc, en ajoutant cette option («O») : make O=~/xenomai/build zimage modules Une fois que la compilation avait été correctement menée, j'utilisais l'une des cibles du Makefile pour installer les modules dans le dossier contenant les objets compilés. Cette cible s'appelle «modules_install» et doit être utilisé avec l'argument «INSTALL_MOD_PATH». make INSTALL_MOD_PATH=~/xenomai/images/modules xeno \ >modules_install 4.2. Installation sur le système de fichier Mise en place du noyau Une fois que la compilation est terminée, il faudrait copier le noyau et les fichiers importants sur le système de fichier de la carte Viper. En fait, dans l'environnement de développement que j'ai utilisé (où les objets étaient conservés sur le PC hôte), le noyau était disponible par le serveur TFTP et le système de fichier par le serveur NFS. Je m'occupais de copier les éléments aux bons emplacements avant de lancer toute opération sur la carte. Dans un premier temps, je commençais par archiver les données dans un dossier spécifique : le dossier images/. J'ai créé un script qui se chargeait de ces opérations. Le script se présentait de la manière suivante : 62/104

63 Mise en place du noyau - Mise en place du noyau work_date = $(date +%d%m%y) type = dbg version = xeno-$type-$work_date cd $build cp vmlinux ~/xenomai/images/vmlinux-$version cp arch/arm/boot/zimage ~/xenomai/images/zimage-$version cp System.map ~/xenomai/images/system.map-$version cp.config ~/xenomai/images/$version.config Ce script permettait la copie de : l'image du noyau (vmlinux) l'image compressé du noyau (zimage) la table des symboles (System.map) le fichier de configuration utilisé au cours de la compilation (.config) Je conservais ces éléments et suffixais (ou préfixais) les noms de façon à ce qu'ils soient rapidement reconnaissables. Le préfixe contenait le type de configuration («dbg» pour les versions d'évaluation, «patch» pour les versions modifiées, «trace» lorsque le traceur du pipeline d'interruption était activé) et la date à laquelle la compilation avait été menée. Une fois que ces informations étaient archivées, je pouvait copier le dossier contenant les modules dans le système de fichier à l'aide de la commande : cp -a ~/xenomai/images/modules xeno/* ~/xenomai/rootfs Il faut noter la présence de l'option «-a» dans la commande. Cette option permet de conserver les attributs des fichiers et les liens. Il faut être vigilant à cette option, particulièrement pour les liens. Si un objet est utilisé à plusieurs endroits, il n'y a généralement pas de duplication de l'objet ; mais la création de plusieurs liens pointant vers cet unique objet Compilation des librairies Le lancement d'un script configure depuis le dossier contenant les sources est un processus typique de compilation d'applications. L'exécution de ce script aboutit à la création d'un fichier Makefile. C'est cette procédure qui est utilisée pour compiler les bibliothèques de Xenomai. Le script accepte un certain nombre de paramètres. Dans mon cas, la commande a pris la forme suivante : 63/104

64 cd ~/xenomai/build_xeno ~/xenomai/xenomai-2.4/configure \ >--host=arm-none-linux-gnueabi \ >--enable-arm-mach=pxa \ >--enable-arm-eabi Il faut noter que le paramètre «--host» sert de préfixe à la recherche du compilateur croisé. Autrement dis, le script vérifie s'il existe des outils de compilation croisée sur la machine qui commencent par «arm-none-linux-gnueabi-». Selon la documentation disponible dans les sources de Xenomai, il n'y a pas besoin de donner l'option «--enable-arm-arch». Seul l'architecture ARM «integrator» oblige la présence de cette option. En effet, en explorant le script «configure», j'ai vérifié que la version de l'architecture est donnée par défaut. Pour autoriser le déboguage des applications qui utilisent les librairies dynamiques, j'ai souvent rajouté le paramètre «--enable-debug». Cette option conserve les symboles de déboguage lors de la compilation des librairies. Elle me permettait d'utiliser le débogueur au sein des librairies lorsque l'application avait été lié dynamiquement à ces librairies. Grâce à cette option, je pouvais faire du déboguage pas-à-pas même dans les fonctions des librairies. Une fois que le Makefile a été généré, pour installer les librairies et d'autres utilitaires dans les sous-dossiers de /usr/xenomai/, il faut lancer la commande : make DESTDIR=~/xenomai/rootfs install J'ai remarqué qu'il ne fallait pas changer l'option «--prefix» lorsque je faisait fonctionner le script à l'étape précédente. En effet, l'option indique le dossier dans lequel les éléments seront installés dans le système de fichier. L'option «DESTDIR», dans la commande de make, indique le dossier de copie des éléments. Dans notre cas, c'est en modifiant ce paramètre que l'on pointe vers la racine du système de fichier de la carte Viper. Au final, les éléments sont installés dans $DESTDIR/usr/xenomai. Pour une utilisation finale, sur un système embarqué, il aurait fallut que je veille à ne pas installer la documentation et les librairies statiques (dont l'extension est «.a»). 5. Évaluation de Xenomai 5.1. Visualisation de la console Dans tout développement d'applications, et en particulier dans le domaine des systèmes embarqués, il est important d'avoir un retour d'informations sur ce qui se passe dans le système au travers de la console. J'ai donc du m'assurer des points suivant : Présence des fichiers de terminaux dans le système de fichier (/dev/ttys*) 64/104

65 Visualisation de la console - Visualisation de la console Comportement de la console en fonction de la chaîne de paramètre passée au noyau par défaut (CONFIG_CMDLINE) Comportement de la console en fonction de la chaîne de paramètre du script de démarrage de RedBoot (qui réécrit la chaîne de caractère précédente) Le visionnage des informations de la console est utile lors de la phase de démarrage. Il permet de suivre la découverte du matériel et le bon démarrage de certains modules. Dans le cas du portage de Xenomai, cela m'a permit de voir que le pipeline d'interruption était correctement activé. Ensuite, dans l'ordre, je pouvais voir que Xenomai était enregistré comme un domaine auprès d'adeos, que le micro-noyau était chargé, puis que les différents «skins» étaient activés. I-pipe : pipeline enabled. [...] I-pipe: Domain Xenomai registered. Xenomai: hal/arm started. Xenomai: real-time nucleus v2.4.8 (Lords Of Karma) loaded. Xenomai: starting native API services. Xenomai: starting POSIX services. Xenomai: starting RTDM services. Dans le cas où le noyau subit un crash, il fournit toujours des informations sur la console. Il donne une trace des dernières instructions qui ont été exécutées sur le processeur. Il donne aussi la valeur des tout les registres au moment de l'erreur fatale. Par exemple, j'ai utilisé cette information pour me faire aider sur la mailing-list de Xenomai. Cette information a permis à l'un des mainteneurs de pointer une erreur sur la compilation des librairies de Xenomai. En effet, la trace des dernières instructions indiquait que les applications tentaient d'utiliser des instructions de calcul flottant alors que le processeur XScale de la carte Viper ne possède pas d'unité de calcul de ce type Critères d'évaluations Les connaissance acquises par la lecture des ouvrages ou des articles sur Xenomai et les systèmes temps-réels m'ont permis de mettre en avant des facteurs à évaluer Les situations propices aux latences Pour créer des situations propices aux latences, il faut identifier les causes communes de latences dans un système. Les latences sont généralement dues aux: nombreuses interruptions matérielles et aux traitements associés On peut créer ce genre de situation sur notre carte de test en la soumettant à une série de «ping» depuis le PC de développement. 65/104

66 nombreuses interruptions logicielles (exceptions) On peut créer une charge factice qui génère beaucoup d'accès mémoires (et donc génère des appels systèmes défaillants) en tapant une commande en tâche de fond, de la forme : dd if=/dev/zero of=/dev/null La mesure de la gigue On peut évaluer la gigue du système par des solutions logicielles. Elle repose sur des mesures faites par une tâche périodique. Si une tâche est déclarée périodique (de période donnée), alors deux mesures de temps devraient être faites avec un écart égal à cette période. Si la différence entre les deux valeurs mesurés par les horloges est différente de la période indiquée, il y a de la gigue dans le système. C'est la méthode qui est employée dans certains programmes de la suite de test (détaillés dans la partie suivante) La suite de tests Parmi les éléments qui sont installés par le script «configure» de Xenomai, il figure sept scripts. Ils font fonctionner des applications de test de Xenomai. Ces scripts sont disponibles dans le dossier /usr/xenomai/share/xenomai/testsuite/. Les applications se trouvent dans le dossier /usr/xenomai/bin/. Le principal intérêt de lancer les applications depuis les scripts réside dans le lancement d'une commande introduisant de la charge sur le système, en plus de l'application. Éventuellement, on peut utiliser directement les binaires des applications depuis le dossier. Voici un tableau résumant les différentes applications : Application Statut Description clocktest fonctionnel Test des horloges systèmes cyclic fonctionnel Test des «timers» irqbench non fonctionnel Environnement de matérielles pour x86 klatency fonctionnel Mesure des latences dans le mode noyau latency fonctionnel Mesure des latences dans le mode utilisateur switchbench fonctionnel Évaluation de la fréquence migration entre domaines switchtest fonctionnel Évaluation de la fréquence maximale de migration entre domaines en fonction de la charge du système mesure des latences maximale de Les informations sur le fonctionnement des applications (dans les pages de manuel) sont très succinctes. J'ai donc du rapidement parcourir le code source des applications 66/104

67 La suite de tests - La suite de tests pour comprendre quel était l'intérêt de chacune Clocktest Dans un système, il existe généralement plusieurs compteurs qui servent d'horloge. En particulier dans les systèmes à multi-processeurs, chaque CPU possède sa propre horloge. Chaque horloge qui est redéfinie doit rester synchronisée avec une horloge de référence. L'application «clocktest» permet de mesure l'écart une horloge et l'horloge de référence, ainsi que l'écart entre les horloges de différents CPUs. Cette application repose sur un thread qui est lancé de façon cyclique. D'une fois sur l'autre, la période de mesure est aléatoire (comprise entre 1 et 1,1ms). Au cours d'une période, le «thread» relève différents couples de valeurs depuis l'horloge de référence et l'horloge testée. En comparant la différence des valeurs fournies par ces deux horloges, il se définit un instant de référence pour la période de mesure. Cet instant de référence est le moment où la phase (la différence) entre les deux horloges est minimale. Le programme définit alors : le décalage («offset») comme la différence entre les deux valeurs obtenues (depuis l'horloge de référence et l'horloge testée) au moment où la phase est minimale for (i = 2; i < 10; i++) { delta = tod_val[i] - tod_val[i-1]; if (delta < min_delta) { min_delta = delta; idx = i; } } [...] per_cpu_data->offset = clock_val[idx] - tod_val[idx]; le glissement («drift») comme le rapport du temps écoulé depuis le début du test mesuré selon l'horloge de référence et celui mesuré par l'horloge testée per_cpu_data->drift = (clock_val[idx] - per_cpu_data->first_clock) / (double)(tod_val[idx] - per_cpu_data->first_tod) - 1; la vrille («warp») comme la différence entre les valeurs de deux horloges de CPU différents Le programme permet de tester deux types de compteurs : CLOCK_REALTIME qui est un compteur donnant le temps depuis une référence 67/104

68 fixe. Cette référence est communément appelée Epoch. CLOCK_MONOTONIC qui est un compteur arbitraire que chaque application peut définir et configurer Cyclic Une demande d'ordonnancement périodique de threads repose sur des compteurs (les «timers», en anglais). Le but de ce programme est de mesurer les latences liés à ces «timers». Pour cela, le programme crée un certain nombre de threads qui sont ordonnancés par Xenomai. Une fois que ces threads sont démarrés, la tâche «main» se contente d'afficher les statistiques des threads au minimum toutes les 10000µs (il y a un appel à la fonction usleep). Chacun des threads, lorsqu'il est créé, utilise la même routine. Cette routine repose principalement sur une boucle. Pendant la période où le «main» est en sommeil, les threads ont le temps d'effectuer plusieurs boucles. Pendant ces boucles, ils font la différence entre une mesure du compteur et une mesure précédente du compteur. Une fois cette mesure collectée, ils mettent à jour leurs statistiques : la latence minimale, actuelle, moyenne et maximale. L'application donne une ligne d'en-tête. Cet en-tête est la recopie exacte du contenu du fichier /proc/loadavg. Dans les pages du manuel, on trouve que les trois premiers chiffres sont la moyenne du nombre de processus dans la file des processus (prêt à être exécutées), moyennés sur 1, 5 et 15 minutes. Le quatrième champ représente le nombre d'entités (processus ou thread) dans l'état RUNNING ou UNINTERRUPTIBLE, rapporté sur le nombre d'entités présent dans le système. Le dernier champ est le PID du dernier processus démarré. Le programme présente pour chacun des «threads» un certain nombre d'informations : le numéro du thread dans l'application (ainsi que son TID15, au niveau système), la priorité pour le système Xenomai, le compteur interne de la boucle active et la latence minimale, actuelle, moyenne et maximale Klatency Pour faire fonctionner cette application, il est généralement nécessaire de charger un module noyau spécifique (la nécessité d'insérer le module dépend du choix qui a été fait à la compilation). On insère le module en utilisant la commande modprobe : modprobe xeno_klat Pour vérifier le chargement du module dans le noyau, on peut utiliser la commande lsmod ou aller voir le contenu de /proc/modules. L'avantage du «fichier» indiqué en dernier est de cibler les dépendances des modules. En effet, les lignes de ce fichier donnent (entre autres informations) le nom du module (le premier champ), le nom du 15 TID : Thread ID. Dans un programme non multi-threadé, le TID est identique au PID. Dans le cas inverse, chaque thread d'une même application possède un identifiant unique (TID) et partagent le PID de l'application. 68/104

69 Klatency - Klatency module dont il dépend (le quatrième champ) et l'état (l'avant dernier champ). Le principe de ce test est de mesurer les latences pour une tâche périodique de 100µs fonctionnant en mode noyau Latency Ce programme est écrit en utilisant l'api native Xenomai. Il a pour but de mesurer les latences d'exécution de façon logicielle. Le programme «main» a pour seule fonction de créer et de démarrer deux tâches. La première s'occupe de la mesure des latences et ne fait pas d'appels à des fonctions de la libc standard. Ainsi, elle reste continuellement ordonnancée par Xenomai. La seconde qui s'occupe de l'affichage voit nécessairement ses contraintes de périodicité relâchées. Puisque la tâche d'affichage n'a pas de périodicité, mais effectue ses activités en synchronisation avec la tâche de mesure grâce à un sémaphore, la tâche de mesure peut effectuer plusieurs mesures lors d'une période d'affichage. Donc, les lignes commençant par RTD (Real Time Data) affichent : la gigue minimale sur une période d'affichage la gigue maximale sur une période d'affichage la gigue minimale sur la durée du test la gigue maximale sur la durée du test la gigue moyenne sur la durée du test Le programme insère parfois une ligne commençant par RTT (Real Time Task) donnant un rappel de l'activité en cours. Cette ligne comprend une indication du temps d'exécution de la tâche depuis le début du test. La tâche de mesure est censé faire des mesures avec la périodicité indiqué, pendant une seconde. Lorsque la seconde est passée, le groupe de mesures constitue un échantillon qui est mis-à-jour dans un histogramme. Une fois que la mise à jour est faite, un signal sur le sémaphore prévient la tâche d'affichage. Le cycle recommence par la ré-initialisation des valeurs minimale et maximale de gigue et le nombre de dépassements. Si la tâche met plus que la durée de la période pour compléter sa mesure, elle manque un (ou plusieurs) point de libération périodique. Le nombre de points de libérations manqués peut être comptabilisé (grâce à l'appel rt_task_wait_period). Lorsque ce cas se présente, le nombre de cycles manqués est comptabilisé et la tâche tente de se recaler avec le prochain point de libération Résultats Commentaires critique J'ai finalement décidé de ne pas utiliser tout les tests qui sont présents dans la suite. Par exemple, je n'ai pas utilisé l'application «cyclic». Le code de cette application est 69/104

70 issus d'une précédente application qui permettait le test des compteurs à haute résolution. Dans le code source de cette application, la distinction entre le traitement et la mesure n'est pas clair. Par exemple, la boucle qui fait la mesure des latences ne fait pas que cette opération : elle se charge aussi de faire plusieurs traitements sur les données. De plus, l'introduction d'une différence entre les périodes des threads pose question. Il serait plus logique d'avoir des threads de priorités différentes. Une situation de concurrence de l'accès au processeur devrait être pris en charge par l'ordonnanceur et ne pas être «évitée» dans l'implémentation du test Analyse des mesures de «clocktest» L'affichage des résultats se présente de la façon suivante : * * * Type ^C to stop this application * * == Tested clock: 0 (CLOCK_REALTIME) CPU ToD offset [us] ToD drift [us/s] warps max delta [us] Pour la plateforme Viper, on a seulement un processeur. Il n'y a donc pas de «warps» et donc pas d'écart maximum («max delta»). Dans le cas du test de l'horloge CLOCK_REALTIME, j'ai obtenu des «offset» oscillant entre -5µs et -6,5µs. Dans le cas du test de l'horloge CLOCK_MONOTONIC, j'ai obtenu des «offset» oscillant entre ,0µs et ,5µs. Pour les deux cas, l'écart entre les deux mesures est de 1,5µs. On a donc pas de différence perceptible, à une échelle macroscopique, de la mise à jour des compteurs et du décalage des valeurs qui doit être fait, au niveau noyau, pour ensuite les présenter à l'utilisateur Analyse des mesures de «latency» Si l'on regarde les deux premiers listings16, on peut dire que la latence minimale est fonction de la période de la tâche. La diminution de la période de la tâche fait, dans un premier temps, diminuer la latence maximale rencontrée. On notera avec le deuxième et le troisième listing que la diminution de la latence minimale atteint un palier lorsque la période de la tâche devient petite. 16 Les résultats que je présente sont disponibles en page 82, en Annexe 70/104

71 Analyse des mesures de «latency» - Analyse des mesures de «latency» Lorsqu'il n'y a pas de dépassements, on peut imaginer que la différence entre la durée de la période et la latence maximale constitue le temps restant pour l'exécution de la tâche, de la manière suivante : Illustration 15 : Latence maximale et temps d'exécution En réalité, cette première impression est fausse : les dépassements de "release point" interviennent même lorsque l'on présente un période plus grande que le temps restant évalué (comme le montre le dernier listing). La priorité de la tâche n'a pas d'influence sur les latences rencontrées. Dans le cas présent, cela s'explique par le fait que la tâche s'exécute sans aucune autre charge pour le système (la tâche d'affichage étant basculé dans le domaine Linux) Le traceur du pipeline Pour comprendre la raison de certains blocages du systèmes, j'ai compilé Xenomai de façon à ce que le traceur du pipeline d'interruption soit présent. Le traceur du pipeline permet de voir les appels de fonction au niveau noyau. Ainsi, on peut suivre l'alternance des domaines au dessus d'adeos. 6. Développement sous Xenomai 6.1. Réalisations Les compétences acquises J'ai choisis de développer des applications utilisant l'api Xenomai. J'ai fais ce choix pour créer et étudier des situations typiques des temps-réels sur le système Xenomai (ordonnancement concurrent, accès aux données de façon concurrentes...). Cela m'a aussi permis de me perfectionner dans la maîtrise du langage de programmation C et dans les outils de développement. De cette manière, mon projet d'étude ne s'est pas restreint simplement à la compréhension du code mais bien à une démarche de compréhension et de résolutions de problèmes liés au temps-réel. Effectivement, tout en me basant sur les applications disponibles dans la suite de test de Xenomai et dans les exemples qui sont joints avec la documentation de l'api, j'ai du faire face à des problèmes spécifiques : problèmes de synchronisation des tâches dans une application Les appels systèmes spécifiques à Xenomai permettent de gérer la création et 71/104

Du 19 au 22 novembre 2012.

Du 19 au 22 novembre 2012. Formation Linux embarqué et Pierre Ficheux (pierre.ficheux@openwide.fr) Du 19 au 22 novembre 2012. 1 MODIFICATIONS VERSION DATE AUTEUR(S) DESCRIPTION 1.0 20/1/2011 P. Ficheux Création 1.1 5/12/2011 P.

Plus en détail

Panorama des temps réels sous GNU/Linux. Stelian Pop

Panorama des temps réels sous GNU/Linux. Stelian Pop <stelian.pop@openwide.fr> Panorama des temps réels sous GNU/Linux Stelian Pop Conférence Linux Solutions, 2 février 2006 Le besoin en contexte industriel il y a souvent besoin d'un comportement temps réel:

Plus en détail

Formation au développement de systèmes Linux embarqué Session de 5 jours

Formation au développement de systèmes Linux embarqué Session de 5 jours Formation au développement de systèmes Linux embarqué Session de 5 jours Titre Aperçu Supports Durée Formateur Langue Public ciblé Pré-requis Formation au développement de systèmes Linux embarqué Chaînes

Plus en détail

Etude et mise en oeuvre de PREEMPT-RT et Xenomai sur cible DSP Blackfin BF537

Etude et mise en oeuvre de PREEMPT-RT et Xenomai sur cible DSP Blackfin BF537 ENSEIRB-MATMECA Rapport de projet avancé 3 ème année électronique Etude et mise en oeuvre de PREEMPT-RT et Xenomai sur cible DSP Blackfin BF537 Etudiants : Alexandre Braconnier Axel Chevalier Jean-Marc

Plus en détail

QCM systèmes d exploitation (Quarante questions)

QCM systèmes d exploitation (Quarante questions) QCM systèmes d exploitation (Quarante questions) QUIZZ OS N 1 (10 questions avec réponses) Question 1: Aux origines de l informatique, l'interface utilisateur des systèmes d exploitations était composée

Plus en détail

Informatique industrielle A7-19571 Systèmes temps-réel J.F.Peyre. Partie I : Introduction

Informatique industrielle A7-19571 Systèmes temps-réel J.F.Peyre. Partie I : Introduction Informatique industrielle A7-19571 Systèmes temps-réel J.F.Peyre Partie I : Introduction Plan de la première partie Quelques définitions Caractéristiques communes des applications temps-réel Exemples d

Plus en détail

NOTIONS SUR WINDOWS NT

NOTIONS SUR WINDOWS NT Chapitre 10 NOTIONS SUR WINDOWS NT Le système d'exploitation WINDOWS NT (New Technology) a été conçu par Microsoft entre 1988 et 1993. Cinq objectifs étaient poursuivis en créant ce nouveau SE : - offrir

Plus en détail

Introduction à la notion de système d'exploitation

Introduction à la notion de système d'exploitation Page 1 sur 9 1. Sommaire 1. Sommaire... 2 2. Description du système... 3 2.1. Rôles du système... 3 2.2. Composantes du système... 4 2.3. Systèmes multitâches... 4 2.4. Systèmes multi-processeurs... 4

Plus en détail

GESTION DES PROCESSUS

GESTION DES PROCESSUS CHAPITRE 2 : GESTION DES PROCESSUS Objectifs spécifiques Connaître la notion de processus, Connaître les caractéristiques d un processus ainsi que son contexte Connaître la notion d interruptions et de

Plus en détail

M3 - Kernel Programming

M3 - Kernel Programming M3 - Kernel Programming Nicolas CORMIER Epitech 2008 Dans le cadre de la réalisation d'un début de micro kernel en mode protégé sur processeur x86, ce document décrit l'architecture du noyau ainsi que

Plus en détail

ETNA Projet de Fin d Étude 2005-2007 RimElse Cahier des charges. c Copyleft 2006, ELSE Team

ETNA Projet de Fin d Étude 2005-2007 RimElse Cahier des charges. c Copyleft 2006, ELSE Team ETNA Projet de Fin d Étude 2005-2007 RimElse Cahier des charges c Copyleft 2006, ELSE Team 18 avril 2006 Table des matières 1 Introduction 2 2 Présentation du projet 3 2.1 Une distribution Évolulable..................

Plus en détail

Systèmes d'exploitation Gestion des processus

Systèmes d'exploitation Gestion des processus Systèmes d'exploitation Gestion des processus Cours SYE Prof. Daniel Rossier Version 2.3 (2009-2010) 1 Plan Processus Changement de contexte Threads IPC (Inter-Process Communication) Algorithmes d'ordonnancement

Plus en détail

Cisco Unified Computing Migration and Transition Service (Migration et transition)

Cisco Unified Computing Migration and Transition Service (Migration et transition) Le service Cisco Unified Computing Migration and Transition Service (Migration et transition) vous aide à migrer vos applications de façon fluide vers la plate-forme Cisco Unified Computing System, à les

Plus en détail

Les systèmes d exploitation

Les systèmes d exploitation Définitions Les systèmes d exploitation Version LJV #090915 septembre 2009 Le système d'exploitation: (anglais operating system, en abrégé OS) ensemble des programmes nécessaires et indispensables au fonctionnement

Plus en détail

Questions à choix multiples Page 1 de 11

Questions à choix multiples Page 1 de 11 INF3172 Principes des systèmes d'exploitation Examen intra hiver 2015 Question #1 Quel est l'objectif d'un système d'exploitation? a) Protéger les composants de l'ordinateur b) Fournir une abstraction

Plus en détail

Le Workflow comme moteur des projets de conformité

Le Workflow comme moteur des projets de conformité White Paper Le Workflow comme moteur des projets de conformité Présentation Les entreprises sont aujourd'hui soumises aux nouvelles régulations, lois et standards de gouvernance les obligeant à mettre

Plus en détail

Les OS embarqués. B. Miramond UCP

Les OS embarqués. B. Miramond UCP Les OS embarqués B. Miramond UCP Les OS embarqués VxWorks : noyau RT le plus utilisé dans l'industrie. Supporte TCP/IP et une API socket. Coût des licences important. QNX : noyau RT de type UNIX. Intègre

Plus en détail

Retrospect 9 pour Mac Manuel d'utilisation, addendum

Retrospect 9 pour Mac Manuel d'utilisation, addendum Retrospect 9 pour Mac Manuel d'utilisation, addendum 2 Retrospect 9 Manuel d'utilisation, addendum www.retrospect.com 2011 Retrospect, Inc. Tous droits réservés. Manuel d'utilisation de Retrospect 9, première

Plus en détail

Théorie des Systèmes d'exploitation : Introduction

Théorie des Systèmes d'exploitation : Introduction Théorie des Systèmes d'exploitation : Introduction Quelques systèmes d'exploitation... 3 Architecture des ordinateurs... 4 Schéma simplifié :... 4 Les concepts des systèmes d'exploitation... 5 Les 2 principales

Plus en détail

Vous avez des problèmes d'impression réseau? UniPrint. est la solution qu'il vous faut. Aperçu du produit

Vous avez des problèmes d'impression réseau? UniPrint. est la solution qu'il vous faut. Aperçu du produit Aperçu du produit Vous avez des problèmes d'impression réseau? est la solution qu'il vous faut. Les responsables IT et les administrateurs systèmes savent que dans tout environnement informatique d'entreprise,

Plus en détail

GENERALITES SUR LES SYSTEMES D EXPLOITATION

GENERALITES SUR LES SYSTEMES D EXPLOITATION CHAPITRE 1 : GENERALITES SUR LES SYSTEMES D EXPLOITATION Objectifs spécifiques Connaître la définition d un système d exploitation Connaître le rôle d un système d exploitation Connaître les classes des

Plus en détail

FileMaker Pro 14. Utilisation d'une Connexion Bureau à distance avec FileMaker Pro 14

FileMaker Pro 14. Utilisation d'une Connexion Bureau à distance avec FileMaker Pro 14 FileMaker Pro 14 Utilisation d'une Connexion Bureau à distance avec FileMaker Pro 14 2007-2015 FileMaker, Inc. Tous droits réservés. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, Californie 95054

Plus en détail

Configuration DCOM pour OPC Factory Server

Configuration DCOM pour OPC Factory Server Configuration DCOM pour OPC Factory Server Sommaire 1. Présentation de OPC...2 2. Présentation de OLE, COM et DCOM...2 2.1. Qu'est-ce qu'ole?...2 2.2. Qu'est-ce que COM?...3 2.3. Qu'est-ce que DCOM?...3

Plus en détail

SOMMAIRE. Utilisation des profils itinérants. Chapitre 1 Mise en place 2

SOMMAIRE. Utilisation des profils itinérants. Chapitre 1 Mise en place 2 Page 1 sur 21 SOMMAIRE Chapitre 1 Mise en place 2 1.1 Qu est ce que c est 2 1.2 Quelques recommandations 3 1.3 La sécurité? 4 1.4 Comment le configurer? 5 1.5 Comment obtenir les droits sur le profil?

Plus en détail

Fiche technique: Sécurité des terminaux Symantec Endpoint Protection La nouvelle technologie antivirus de Symantec

Fiche technique: Sécurité des terminaux Symantec Endpoint Protection La nouvelle technologie antivirus de Symantec La nouvelle technologie antivirus de Symantec Présentation Protection avancée contre les menaces. Symantec Endpoint Protection associe Symantec AntiVirus à la prévention avancée des menaces pour fournir

Plus en détail

Chapitre 1 : Introduction aux Systèmes d Exploitation (SE)

Chapitre 1 : Introduction aux Systèmes d Exploitation (SE) 1. Introduction Chapitre 1 : Introduction aux Systèmes d Exploitation (SE). 1 système informatique est un ensemble constitué de matériels et de logiciels et qui assure le traitement des données.. Les pgms

Plus en détail

CA ARCserve Backup r12

CA ARCserve Backup r12 DOSSIER SOLUTION : CA ARCSERVE BACKUP r12 CA ARCserve Backup r12 CA ARCSERVE BACKUP R12 ASSURE UNE PROTECTION EXCEPTIONNELLE DES DONNÉES POUR LES SERVEURS, LES BASES DE DONNÉES, LES APPLICATIONS ET LES

Plus en détail

Windows 2008 server -Introduction-

Windows 2008 server -Introduction- Windows 2008 server -Introduction- Rappel sur les systèmes d exploitation Un système d exploitation (Operating System) est un ensemble de programmes responsables de la liaison entre les ressources matérielles

Plus en détail

Table des matières. Chapitre 1 Les architectures TSE en entreprise

Table des matières. Chapitre 1 Les architectures TSE en entreprise 1 Chapitre 1 Les architectures TSE en entreprise 1. Présentation............................................. 11 1.1 Le concept........................................... 11 1.2 Approche contextuelle.................................

Plus en détail

Service de planification et de conception de réseau sans fil unifié Cisco

Service de planification et de conception de réseau sans fil unifié Cisco Service de planification et de conception de réseau sans fil unifié Cisco Augmentez la précision, la vitesse et l'efficacité du déploiement d'une solution de réseau sans fil unifié Cisco. Adoptez une approche

Plus en détail

Chapitre 5. Communication interprocessus. 5.1 Introduction

Chapitre 5. Communication interprocessus. 5.1 Introduction Communication interprocessus 5.1 Introduction Dans une activité parallèle (ou pseudo parallèle), un ensemble de processus séquentiels s exécutent en parallèle. Cette exécution résulte deux types de relations

Plus en détail

GUIDE DES BONNES. Gestion des systèmes. www.kaspersky.com/be

GUIDE DES BONNES. Gestion des systèmes. www.kaspersky.com/be GUIDE DES BONNES Pratiques www.kaspersky.com/be 2 Votre guide des BONNES pratiques en matière de gestion des systèmes. Renforcez la sécurité et réduisez la complexité de votre environnement grâce à des

Plus en détail

KASPERSKY SECURITY FOR BUSINESS

KASPERSKY SECURITY FOR BUSINESS KASPERSKY SECURITY FOR BUSINESS IDENTIFIER. CONTRÔLER. PROTÉGER. Guide de migration RENOUVELLEMENTS ET MISES À NIVEAU DES LICENCES : Guide de migration PRÉSENTATION DE LA NOUVELLE GAMME ENDPOINT SECURITY

Plus en détail

Windows Server 2008. Chapitre 1: Découvrir Windows Server 2008

Windows Server 2008. Chapitre 1: Découvrir Windows Server 2008 Windows Server 2008 Chapitre 1: Découvrir Windows Server 2008 Objectives Identifier les caractéristiques de chaque édition de Windows Server 2008 Identifier les caractéristiques généraux de Windows Server

Plus en détail

VIRTUALISATION ET CLOUD COMPUTING. Année Universitaire : 2015-2016

VIRTUALISATION ET CLOUD COMPUTING. Année Universitaire : 2015-2016 VIRTUALISATION ET CLOUD COMPUTING Enseignant : Mohamed MANAA Année Universitaire : 2015-2016 Plan La virtualisation Qu'est-ce que la virtualisation? Pourquoi virtualiser? Terminologies Techniques de virtualisation

Plus en détail

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Système virtuel StruxureWare Data Center Expert Le serveur StruxureWare Data Center Expert 7.2 est disponible comme système virtuel pris en charge

Plus en détail

Contrôle à distance. Logiciels existants:

Contrôle à distance. Logiciels existants: Contrôle à distance Logiciels existants: CrossLoop, dont l édition gratuite est limitée à une seule machine. Est un utilitaire permettant de contrôler un ordinateur à distance s'inscrivant directement

Plus en détail

FileMaker Pro 11. Exécution de FileMaker Pro 11 sur Citrix XenApp

FileMaker Pro 11. Exécution de FileMaker Pro 11 sur Citrix XenApp FileMaker Pro 11 Exécution de FileMaker Pro 11 sur Citrix XenApp 2007-2010 FileMaker, Inc. Tous droits réservés. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker est une

Plus en détail

REALISATION d'un. ORDONNANCEUR à ECHEANCES

REALISATION d'un. ORDONNANCEUR à ECHEANCES REALISATION d'un ORDONNANCEUR à ECHEANCES I- PRÉSENTATION... 3 II. DESCRIPTION DU NOYAU ORIGINEL... 4 II.1- ARCHITECTURE... 4 II.2 - SERVICES... 4 III. IMPLÉMENTATION DE L'ORDONNANCEUR À ÉCHÉANCES... 6

Plus en détail

Livre blanc relatif à iclass SE et multiclass SE OSDP avec SCP

Livre blanc relatif à iclass SE et multiclass SE OSDP avec SCP Livre blanc relatif à iclass SE et multiclass SE OSDP avec SCP Livre blanc relatif à OSDP OSDP est l'acronyme de «Open Supervised Device Protocol» SCP est l'acronyme de «Secure Channel Protocol» Le secteur

Plus en détail

Citrix XenApp 6.5 Concepts et mise en oeuvre de la virtualisation d'applications

Citrix XenApp 6.5 Concepts et mise en oeuvre de la virtualisation d'applications Virtualisation, enjeux et concepts 1. Définition et vue d'ensemble 15 1.1 Terminologie et concepts 16 1.2 Bénéfices 17 1.3 Technologies et solutions de virtualisation 19 1.3.1 Virtualisation de serveurs

Plus en détail

Cible de sécurité CSPN. TRANGO Hypervisor. Sommaire. Tableau de révision. TRANGO Virtual Processors

Cible de sécurité CSPN. TRANGO Hypervisor. Sommaire. Tableau de révision. TRANGO Virtual Processors Cible de sécurité CSPN TRANGO Hypervisor TRANGO Virtual Processors Sommaire Tableau de révision...1 1 Identification du produit...2 2 Glossaire...2 3 Argumentaire (description) du produit...2 3.1 Description

Plus en détail

Systèmes d exploitation

Systèmes d exploitation Systèmes d exploitation Un système d exploitation (SE, en anglais Operating System ou OS) est un ensemble de programmes responsables de la liaison entre les ressources matérielles d un ordinateur et les

Plus en détail

Système d exploitation

Système d exploitation Chapitre 2 Système d exploitation 2.1 Définition et rôle Un ordinateur serait bien difficile à utiliser sans interface entre le matériel et l utilisateur. Une machine peut exécuter des programmes, mais

Plus en détail

Licence et activation de MapInfo Professional 12.0

Licence et activation de MapInfo Professional 12.0 Licence et activation de Asie-Pacifique / Australie : Téléphone : +61 2 9437 6255 pbsoftware.australia@pb.com pbsoftware.singapore@pb.com www.pitneybowes.com.au/software Canada : Téléphone : +1 416 594

Plus en détail

Contribution à la mise en service d'une ferme de serveurs connectée à une grille de calcul pour la physique des hautes énergies

Contribution à la mise en service d'une ferme de serveurs connectée à une grille de calcul pour la physique des hautes énergies Contribution à la mise en service d'une ferme de serveurs connectée à une grille de calcul pour la physique des hautes énergies Charlier Fabrice 2è licence en informatique Année Académique 2005-2006 Plan

Plus en détail

Systèmes temps réel et logiciel libre

Systèmes temps réel et logiciel libre Systèmes temps réel et logiciel libre Pierre FICHEUX (pierre.ficheux@openwide.fr) Avril 2012 1 Présentation Open Wide SSLL créée en septembre 2001 avec Thales et Schneider => 10 ans d'expérience! 120 collaborateurs

Plus en détail

LANDPARK NETWORK IP LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU

LANDPARK NETWORK IP LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU LANDPARK NETWORK IP Avril 2014 LANDPARK NETWORK IP VOUS PERMET D'INVENTORIER FACILEMENT VOS POSTES EN RÉSEAU Landpark NetworkIP est composé de trois modules : Un module Serveur, que l'on installe sur n'importe

Plus en détail

les Solutions pour la Distribution

les Solutions pour la Distribution SPIRAL Group, les Solutions pour la Distribution SPIRAL est un groupe international au service de la Distribution. L expertise de SPIRAL Group repose sur une double dynamique :sa connaissance de l organisation

Plus en détail

FICHE DESCRIPTIVE LPIC-1 (LPI 101 et LPI 102)

FICHE DESCRIPTIVE LPIC-1 (LPI 101 et LPI 102) Prérequis : FICHE DESCRIPTIVE LPIC-1 (LPI 101 et LPI 102) Avoir les connaissances de base du fonctionnement de Linux et les systèmes d'exploitation Objectifs : Le premier niveau de certification Linux

Plus en détail

Institut Supérieure Aux Etudes Technologiques De Nabeul. Département Informatique

Institut Supérieure Aux Etudes Technologiques De Nabeul. Département Informatique Institut Supérieure Aux Etudes Technologiques De Nabeul Département Informatique Support de Programmation Java Préparé par Mlle Imene Sghaier 2006-2007 Chapitre 1 Introduction au langage de programmation

Plus en détail

Yphise. Le SAN. Architectures SAN

Yphise. Le SAN. Architectures SAN Architectures SAN Mardi 28 mars 2000 Laurent Ruyssen - 53 Bd de Sébastopol - T 1 45 08 86 70 F 1 45 08 05 51 yphise@yphise.com - http://yphise.fr ABS0003-1 Nous accompagnons les Directions Informatiques

Plus en détail

Cours 3 : L'ordinateur

Cours 3 : L'ordinateur Cours 3 : L'ordinateur Abdelkrim Zehioua 2éme année Licence Gestion Faculté des sciences Économiques et sciences de Gestion Université A, Mehri - Constantine 2 Plan du cours 1.Définitions de l'ordinateur

Plus en détail

vbladecenter S! tout-en-un en version SAN ou NAS

vbladecenter S! tout-en-un en version SAN ou NAS vbladecenter S! tout-en-un en version SAN ou NAS Quand avez-vous besoin de virtualisation? Les opportunités de mettre en place des solutions de virtualisation sont nombreuses, quelque soit la taille de

Plus en détail

PFE Télécommunications. Pré-rapport à l'issue des 6 premières semaines de stage. Page 1 sur 5 1 %

PFE Télécommunications. Pré-rapport à l'issue des 6 premières semaines de stage. Page 1 sur 5 1 % PFE Télécommunications Pré-rapport à l'issue des 6 premières semaines de stage!"!"#$%&' ()*()!")+")# (#),()-,)*)"-./0 1 ()*()!")+-)# % 23 &0 )14) 56 7$8797%77:7' '72 Page 1 sur 5 Contexte Les centres de

Plus en détail

Communication sans collaboration

Communication sans collaboration Siège social : Avanade France 125 avenue de Paris 92320 Châtillon www.avanade.com/fr Avanade est le principal intégrateur de solutions pour l entreprise basées sur la plate-forme Microsoft. Sa mission

Plus en détail

en version SAN ou NAS

en version SAN ou NAS tout-en-un en version SAN ou NAS Quand avez-vous besoin de virtualisation? Les opportunités de mettre en place des solutions de virtualisation sont nombreuses, quelque soit la taille de l'entreprise. Parmi

Plus en détail

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN 1. DÉVELOPPEMENT D'APPLICATION (CONCEPTEUR ANALYSTE) 1.1 ARCHITECTURE MATÉRIELLE DU SYSTÈME INFORMATIQUE 1.1.1 Architecture d'un ordinateur Processeur,

Plus en détail

VMWare Infrastructure 3

VMWare Infrastructure 3 Ingénieurs 2000 Filière Informatique et réseaux Université de Marne-la-Vallée VMWare Infrastructure 3 Exposé système et nouvelles technologies réseau. Christophe KELLER Sommaire Sommaire... 2 Introduction...

Plus en détail

Introduction aux systèmes GNU/Linux

Introduction aux systèmes GNU/Linux Introduction aux systèmes GNU/Linux Séance 1 inetdoc.net Philippe Philippe Latu Latu // Université Université Toulouse Toulouse 33 Paul Paul Sabatier Sabatier Document Document sous sous licence licence

Plus en détail

Guide d'installation. Release Management pour Visual Studio 2013

Guide d'installation. Release Management pour Visual Studio 2013 1 Guide d'installation Release Management pour Visual Studio 2013 Le contenu de ce document est fourni «en l'état». Les informations et les points de vue contenus dans ce document, y compris les URL et

Plus en détail

Les avantages de la virtualisation sont multiples. On peut citer:

Les avantages de la virtualisation sont multiples. On peut citer: 1 Les mécanismes de virtualisation ont été introduits il y a fort longtemps dans les années 60 par IBM avec leur système CP/CMS. La motivation première de la virtualisation est la possibilité d'isoler

Plus en détail

SOUTIEN INFORMATIQUE DEP 5229

SOUTIEN INFORMATIQUE DEP 5229 SOUTIEN INFORMATIQUE DEP 5229 Le Diplôme d études professionnelles D.E.P. en soutien informatique a une durée totale de 1800 heures à temps plein. Le programme permet de développer les compétences nécessaires

Plus en détail

Objectifs de la formation : Savoir réaliser la maintenance et l'administration de premier niveau sur un réseau d'établissement SCRIBE.

Objectifs de la formation : Savoir réaliser la maintenance et l'administration de premier niveau sur un réseau d'établissement SCRIBE. Scribe : Formation Référent TICE Objectifs de la formation : Savoir réaliser la maintenance et l'administration de premier niveau sur un réseau d'établissement SCRIBE. Savoir déterminer la cause d'un problème

Plus en détail

Temps Réel. Jérôme Pouiller Septembre 2011

Temps Réel. Jérôme Pouiller <j.pouiller@sysmic.org> Septembre 2011 Temps Réel Jérôme Pouiller Septembre 2011 Sixième partie VI Architectures des OS temps réels J. Pouiller Temps Réel 172 / 197 18 Problématique des OS RT 19 Systèmes Symétriques

Plus en détail

Annexe : La Programmation Informatique

Annexe : La Programmation Informatique GLOSSAIRE Table des matières La Programmation...2 Les langages de programmation...2 Java...2 La programmation orientée objet...2 Classe et Objet...3 API et Bibliothèque Logicielle...3 Environnement de

Plus en détail

UN SYSTÈME D'EXPLOITATION = DES SERVICES COMMUNS GESTION DES DIVERS PROCESSUS GESTION DES RESSOURCES PHYSIQUES :

UN SYSTÈME D'EXPLOITATION = DES SERVICES COMMUNS GESTION DES DIVERS PROCESSUS GESTION DES RESSOURCES PHYSIQUES : UN SYSTÈME D'EXPLOITATION = DES SERVICES COMMUNS GESTION DES DIVERS PROCESSUS processus locaux ou distants représentés localement (proxys). GESTION DES RESSOURCES PHYSIQUES : mémoire principale pour y

Plus en détail

II Importation et retrait automatiques de

II Importation et retrait automatiques de II Importation et retrait automatiques de postes de travail Les services d'importation et de retrait automatiques de postes de travail de Novell ZENworks for Desktops (ZfD) permettent de gérer facilement

Plus en détail

HP Data Protector Express Software - Tutoriel 4. Utilisation de Quick Access Control (Windows uniquement)

HP Data Protector Express Software - Tutoriel 4. Utilisation de Quick Access Control (Windows uniquement) HP Data Protector Express Software - Tutoriel 4 Utilisation de Quick Access Control (Windows uniquement) Que contient ce tutoriel? Quick Access Control est une application qui s'exécute indépendamment

Plus en détail

Introduction : Caractéristiques du RAID : La redondance et la parité : Les différents types de systèmes RAID :

Introduction : Caractéristiques du RAID : La redondance et la parité : Les différents types de systèmes RAID : Introduction : La technologie RAID (regroupement redondant de disques indépendants) permet de constituer une unité de stockage à partir de plusieurs disques durs. Cette unitée,appelée grappe, a une tolérance

Plus en détail

Bénéficiez d'un large choix d'applications novatrices et éprouvées basées sur les systèmes d'exploitation i5/os, Linux, AIX 5L et Microsoft Windows.

Bénéficiez d'un large choix d'applications novatrices et éprouvées basées sur les systèmes d'exploitation i5/os, Linux, AIX 5L et Microsoft Windows. 1. Le nouveau eserver i5 en bref Gérez plusieurs systèmes d'exploitation et environnements d'applications sur un seul serveur pour simplifier votre infrastructure et réduire les frais de gestion Simplifiez

Plus en détail

Manuel de Nero MediaStreaming pour MCE

Manuel de Nero MediaStreaming pour MCE Manuel de Nero MediaStreaming pour MCE Nero AG Copyright et marques Le présent manuel et son contenu sont protégés par copyright et sont la propriété de Nero AG. Tous droits réservés. Ce manuel contient

Plus en détail

PLANIFICATION ET SUIVI D'UN PROJET

PLANIFICATION ET SUIVI D'UN PROJET Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Guide méthodologique PLANIFICATION ET SUIVI D'UN PROJET Référence : CNRS/DSI/conduite-projet/developpement/gestion-projet/guide-planfi-suivi-projet

Plus en détail

Processeur JAP. Le langage JAVA

Processeur JAP. Le langage JAVA Processeur JAP Ce document présente les dernières nouveautés concernant le processeur JAVA de la société AED. Il commence par un rappel sur les caractéristiques du processeur actuel, puis présente les

Plus en détail

Client Citrix ICA Windows CE Carte de référence rapide

Client Citrix ICA Windows CE Carte de référence rapide Client Citrix ICA Windows CE Carte de référence rapide Exigences Pour exécuter le client ICA Windows CE, vous devez disposer des éléments suivants : Un périphérique Windows CE Une carte d'interface réseau

Plus en détail

Présentation. Logiciels libres. Open Source. Clinkast 4 Avenue du Général de Gaulle F 92360 Meudon (+33) 6 20 44 86 95 (+33) 1 46 30 24 13

Présentation. Logiciels libres. Open Source. Clinkast 4 Avenue du Général de Gaulle F 92360 Meudon (+33) 6 20 44 86 95 (+33) 1 46 30 24 13 Présentation Logiciels libres et Open Source Description Un logiciel libre* est en général gratuit. Il est utilisable et modifiable sans notification préalable à son auteur, qui a renoncé à ses droits

Plus en détail

PC Check & Tuning 2010 Optimisez et accélérez rapidement et simplement les performances de votre PC!

PC Check & Tuning 2010 Optimisez et accélérez rapidement et simplement les performances de votre PC! PC Check & Tuning 2010 Optimisez et accélérez rapidement et simplement les performances de votre PC! MAGIX PC Check & Tuning 2010 est la solution logicielle complète pour l'analyse, la maintenance et l'accélération

Plus en détail

Qu'est-ce que c'est Windows NT?

Qu'est-ce que c'est Windows NT? Qu'est-ce que c'est Windows NT? Que faire en cas de blocage d'une station NT? Profils «errants» avec win NT : des éclaircissements Echange de fichiers entre les deux environnements PC/Mac Blocage réseau

Plus en détail

Architectures des OS temps réels

Architectures des OS temps réels Temps Réel Jérôme Pouiller Sixième partie VI Architectures des OS temps réels Sysmic - J. Pouiller Temps Réel 171 / 1 Sysmic - J. Pouiller Temps Réel 172 / 1 Architectures multi-coeurs

Plus en détail

Temps Réel. Jérôme Pouiller

Temps Réel. Jérôme Pouiller <j.pouiller@sysmic.org> Temps Réel Jérôme Pouiller Sixième partie VI Architectures des OS temps réels Sysmic - J. Pouiller Temps Réel 171 / 1 Sysmic - J. Pouiller Temps Réel 172 / 1 Architectures multi-coeurs

Plus en détail

PCI (Payment Card Industry) DSS (Data Security Standard )

PCI (Payment Card Industry) DSS (Data Security Standard ) PCI (Payment Card Industry) DSS (Data Security Standard ) Jean-Marc Robert Génie logiciel et des TI PCI-DSS La norme PCI (Payment Card Industry) DSS (Data Security Standard) a été développée dans le but

Plus en détail

GESTION CENTRALISÉE DELL POWERVAULT DL 2000 OPTIMISÉ PAR SYMANTEC

GESTION CENTRALISÉE DELL POWERVAULT DL 2000 OPTIMISÉ PAR SYMANTEC GESTION CENTRALISÉE DELL POWERVAULT DL 2000 OPTIMISÉ PAR SYMANTEC NOTE DE SYNTHESE La solution Dell PowerVault DL2000 optimisée par Symantec Backup Exec est la seule à proposer un système intégré de sauvegarde

Plus en détail

Windows 8 Installation et configuration

Windows 8 Installation et configuration Editions ENI Windows 8 Installation et configuration Collection Ressources Informatiques Extrait 112 Windows 8 Installation et configuration Pour terminer l'application de l'image, nous devons configurer

Plus en détail

Programmation système : sémaphores

Programmation système : sémaphores Programmation système : sémaphores Un sémaphore permet de protéger une variable (ou un type de donnée abstrait) et constitue la méthode utilisée couramment pour restreindre l'accès à des ressources partagées

Plus en détail

Déploiement et gestion d ordinateurs avec un outil centralisé (Ghost Serveur 7.5)

Déploiement et gestion d ordinateurs avec un outil centralisé (Ghost Serveur 7.5) Déploiement et gestion d ordinateurs avec un outil centralisé (Ghost Serveur 7.5) QU EST CE Q UN SYSTEME D ADMINISTRATION ET DE DEPLOIEMENT?... 1 1. INSTALLATION SUR LE SERVEUR :... 4 2. PREPARATION DE

Plus en détail

Windows serveur 2008 installer hyperv

Windows serveur 2008 installer hyperv Windows serveur 2008 installer hyperv 1 Description Voici la description fournit par le site Microsoft. «Windows Server 2008 Hyper-V est le moteur de virtualisation (hyperviseur) fourni dans Windows Server

Plus en détail

7.2 Structure interne d'un processeur de base.

7.2 Structure interne d'un processeur de base. LES PROCESSEURS Introduction Dans le chapitre 5, nous avons vu les processeurs selon leur type (famille, fabricant). Ce chapitre va expliquer l'architecture interne de ces processeurs et leurs performances

Plus en détail

ORDONNANCEMENT DE L'UNITE DE TRAITEMENT

ORDONNANCEMENT DE L'UNITE DE TRAITEMENT ORDONNANCEMENT DE L'UNITE DE TRAITEMENT 1. OBJECTIFS... 2 2. ASSIGNATIONS ET DIAGRAMMES DE GANTT... 2 3. ALGORITHMES SANS RÉQUISITION... 4 3.1. ORDONNANCEMENT DANS L'ORDRE D'ARRIVÉE (FIFO)... 4 3.2. PLUS

Plus en détail

LA TECHNOLOGIE DU LENDEMAIN

LA TECHNOLOGIE DU LENDEMAIN LA TECHNOLOGIE DU LENDEMAIN Société : VNEXT est une société de conseil et d expertises technologiques dans le domaine de l infrastructure IT, le développement des logiciels et la formation professionnelle.

Plus en détail

Infrastructure RDS 2012

Infrastructure RDS 2012 105 Chapitre 3 Infrastructure RDS 2012 1. Introduction Infrastructure RDS 2012 Une infrastructure RDS 2012 R2 est composée de plusieurs serveurs ayant chacun un rôle bien défini pour répondre aux demandes

Plus en détail

MANUEL D' UTILISATION

MANUEL D' UTILISATION MANUEL D' UTILISATION Table des matières Présentation...2 Introduction...2 Matériel nécessaire...2 Logiciel nécessaire...3 Partie A : Installation et Mise en oeuvre du matériel et logiciel...4 Partie B

Plus en détail

FICHE PRODUIT COREYE CACHE Architecture technique En bref Plateforme Clients Web Coreye Cache applicative Références Principe de fonctionnement

FICHE PRODUIT COREYE CACHE Architecture technique En bref Plateforme Clients Web Coreye Cache applicative Références Principe de fonctionnement COREYE CACHE Solution d absorption de charge pour une disponibilité et une performance optimales des applications Web En bref Architecture technique La plateforme Coreye Cache délivre la majeure partie

Plus en détail

A. Présentation. B. Introduction. Chapitre 11

A. Présentation. B. Introduction. Chapitre 11 Chapitre 11 A. Présentation 1. Pré-requis matériel et configuration de l'environnement Pour effectuer toutes les mises en pratique de ce chapitre, vous devez disposer et configurer les machines virtuelles

Plus en détail

RoxMath. Pour un monde informatique libre

RoxMath. Pour un monde informatique libre RoxMath Pour un monde informatique libre RoxMath est une distribution GNU/Linux contenant de nombreux logiciels pour les Mathématiques adaptés pour l'éducation réalisée pour l'irem de la Réunion par Nathalie

Plus en détail

Symantec Backup Exec.cloud

Symantec Backup Exec.cloud Protection automatique, continue et sécurisée qui sauvegarde les données vers le cloud ou via une approche hybride combinant la sauvegarde sur site et dans le cloud. Fiche technique : Symantec.cloud Seulement

Plus en détail

Sécurité et Communication SIS. Serveur d Interphonie Software L interphonie ne s arrête pas aux frontières du hardware.

Sécurité et Communication SIS. Serveur d Interphonie Software L interphonie ne s arrête pas aux frontières du hardware. Sécurité et Communication SIS Serveur d Interphonie Software L interphonie ne s arrête pas aux frontières du hardware. SIS Le Serveur d Interphonie Software. Le premier serveur d interphonie entièrement

Plus en détail

BITDEFENDER GRAVITYZONE

BITDEFENDER GRAVITYZONE BITDEFENDER GRAVITYZONE Notes de publication de la version 5.1.17-441 Bitdefender GravityZone Notes de publication de la version 5.1.17-441 Date de publication 2014.11.21 Copyright 2014 Bitdefender Mentions

Plus en détail

1.1 Remote Procedure Call (RPC)

1.1 Remote Procedure Call (RPC) 1.1 Remote Procedure Call (RPC) Le modèle Client-Serveur est un modèle simple à utiliser pour la structuration des systèmes répartis. Mais ce modèle s appuie sur des communications de type entrée/sortie

Plus en détail