Rapport de recherche, Applications temps réel sur smartphones : BARTHOLOMÉ Anthony COULON Fabien MOUEZA Peter TRÉGUER Fabien

Rapport de recherche, Applications temps réel sur smartphones : Étude de l OS Android BARTHOLOMÉ Anthony COULON Fabien MOUEZA Peter TRÉGUER Fabien Université de Nantes Année universitaire 2010-2011

Table des matières Introduction 3 1 Présentation et étude d Android 4 1.1 Présentation générale d Android...................................... 4 1.2 Présentation technique d Android...................................... 5 1.3 Installation d Android............................................ 6 1.3.1 Installation Androidx86 en multiboot............................... 6 1.3.2 Installation Androidx86 en machine virtuelle........................... 6 1.3.3 Utilisation à partir d un livecd................................... 6 1.3.4 Compilation des sources....................................... 7 1.3.5 Sur un téléphone portable...................................... 7 2 Présentation du temps réel, essai sur Android 8 2.1 Présentation du temps réel......................................... 8 2.2 Notions.................................................... 9 2.2.1 État d un processus......................................... 9 2.2.2 Temps Réel.............................................. 9 2.3 Etude d Android pour le temps réel..................................... 10 2.4 Travaux déja effectués............................................ 11 2.5 Autres pistes de recherches......................................... 12 3 Première approche de recherche : Modification de l ordonnanceur 13 3.1 Etude de l ordonnanceur CFS de Linux.................................. 13 3.2 Resultats................................................... 14 3.2.1 Notion de tâches........................................... 14 3.2.2 Théorie................................................ 14 3.2.3 Pratique................................................ 15 4 Seconde approche : Application du patch RTAI pour Linux sur Android 17 4.1 Patch RTAI.................................................. 17 4.2 Etude de l arborescence Android...................................... 17 4.2.1 bionic................................................. 17 4.2.2 bootable................................................ 18 4.2.3 build.................................................. 19 4.2.4 dalvik................................................. 19 4.2.5 kernel................................................. 22 4.2.6 development............................................. 23 4.2.7 device................................................. 23 4.2.8 external................................................ 23 4.2.9 frameworks.............................................. 23 4.2.10 hardware............................................... 23 1

4.2.11 ndk.................................................. 24 4.2.12 packages................................................ 24 4.2.13 prebuilt................................................ 24 4.2.14 system................................................. 25 4.2.15 sdk................................................... 25 4.3 Resultats................................................... 26 Conclusion 27

Android Introduction Dans le cadre du module Initiation à la recherche, nous avons été affecté à un sujet de recherche Applications temps réel sur smartphones : étude de l OS Android. Un des objectifs est d étudier l OS Android du point de vue des garanties temporelles qu il peut offrir pour statuer sur son adéquation vis-à-vis des exigences des applications temps réel. Il s agira notamment d identifer les points de l OS qui limitent actuellement l utilisation d Android pour le temps réel. Pour ce faire, le travail sera réparti en quatre grandes parties. Il y aura la présentation générale d Android, celle de l ordonnancement temps réel et les deux approches de recherche que nous avons eu durant les quelques mois qui nous ont été accordés pour ce travail. La première partie consistera à étudier Android. Dans cette partie, il nous faudra découvrir ce qu est Android. Quel est son but, et les moyens mis en oeuvre pour les éxécuter. Il nous faudra comprendre comment fonctionne Android en général dans un premier temps, puis d une manière plus approndie dans un second temps. Cette étude nous faciletera le travail par la suite. Il est plus dur de travailler sur un système inconnu. Il nous faudra ensuite comprendre ce qu est le temps réel, puis tester si Android est compatible avec des applications temps réel. Tester également les performances d Android. Pour effectuer tous ces tests il sera nécessaire de l installer sur un ordinateur. Il y aura donc également des tutoriaux complets sur l installation de ce système initialement prévu pour des téléphones sur des architectures x86. Nous verrons également ou en est la recherche sur ce domaine. Pour cela, nous étudierons quelques articles traitant du même sujet. La troisième partie se basera sur l étude de l ordonnanceur de Linux. En effet, Android se basant sur Linux, peut être sera t il possible de modifier cette partie pour obtenir ce que l on recherche. Nous expliquerons le pourquoi de cette partie dans le chapitre concernant Android. La quatrième et derniere partie, sera une étude plus en détails de l arborescence d Android pour ainsi pouvoir utiliser Le patch RTAI. Le patch RTAI initialement prévu pour Linux, est un patch permettant de modifier l ordonnanceur de Linux pour le rendre compatible temps réel. Il est donc possible que ceci réponde à notre problème. Ceci sera davantage expliqué dans la partie concernée. Chacune des deux dernières parties aura une présentation générale sur le but recherché, le déroulement de la recherche et les résultats obtenus. 3 L A TEX

Android Chapitre 1 Présentation et étude d Android 1.1 Présentation générale d Android Android (prononcé Androïde) est un système d exploitation open source pour smartphones, PDA et terminaux mobiles conçu par Android, une startup rachetée par Google, et annoncé officiellement le 5 novembre 2007. D autres types d appareils possédant ce système d exploitation existent, par exemple des téléviseurs et des tablettes [17] Android peut servir à de multiples fins. Des centaines de milliers d application tournent aujourd hui sur ce qu on appelle l Android Market. Sur cette plateforme de téléchargement on peut trouver toutes sortes d applications telles que google maps, youtube, géolocalisation, gestion des contacts...il est possible de trouver des applications sur énormement de domaines (horaires de trains, applications d architecture...). C est pourquoi Android est aujourd hui en pleine expansion, et gagne chaque jour de nombreux utilisateurs en plus. Figure 1.1 Évolution d Android [11] 4 L A TEX

Comme le montre le graphique, Android est devenu le leader en tant que système d exploitation des smartphones. Il est devenu si important qu il serait plus que profitable que ce système puisse éxécuter des applications temps réel. Nous allons par la suite voir si ce système peut le gérer. 1.2 Présentation technique d Android Android est basé sur le noyau 2.6 de Linux pour fonctionner. En effet, Android n est pas un système d exploitation totalement indépendant. Sur le schéma suivant, on peut remarquer qu Android est constitué de plusieurs couches. La plus basse est le noyau de Linux sous la version 2.6. C est ce noyau qui gére les pilotes de base, mais également le boot du la machine. Au niveau supérieur, donc propre a Android nous avons les libraries. Ces libraries gérent toutes les bibliothèques utilent à l éxécution d Android. Dans cette couche, nous pouvons également trouver ce qui s appelle Android Runtime, qui contient la machine virtuelle Dalvik sur laquelle repose Android. A un niveau bien supérieur, nous avons les frameworks, qui permettent à tous les développeurs de créer leurs applications. Au niveau le plus haut, nous avons les applications. Figure 1.2 Architecture d Android [15] Maintenant que nous connaissons l architecture d Android, nous allons essayer de l installer sur un ordinateur.

1.3 Installation d Android 1.3.1 Installation Androidx86 en multiboot Vous pouvez installer Android sur un ordinateur comme tout autre système d exploitation. Pour ce faire, commencez par télécharger l image cd sur http ://www.android-x86.org/download. En choisissant de préférence la dernière version stable. 2 choix s offrent alors à nous. soit une installation par CD soit une installation par USB Si vous possèdez un netbook, la plupart du temps sans lecteur CD il vous est indispensable de prendre la version USB. Sinon choisissez selon ce que vous préférez. Ici nous prenons la version android-x86-1.6-r2.iso. Il vous faut ensuite graver l image CD. Il ne nous reste plus qu à procéder à une installation classique de système d exploitation. Redémarrez votre ordinateur avec le CD ou la clé USB et installer Android comme un linux classique en choisissant votre partition. Au démarrage suivant vous obtiendrez le choix entre votre (vos) ancien(s) système(s) et Android. 1.3.2 Installation Androidx86 en machine virtuelle L installation en machine virtuelle vous permet de ne pas avoir à choisir au démarrage sur quel système vous voulez démarrer. Vous pourrez lancer Android quand bon vous semble. L utilisation différe légérement selon linux ou Windows. Dans les deux cas devez commencer par télécharger l image cd sur http ://www.androidx86.org/download. installation sous linux Sous linux, commencez par installer virtual box. Pour ce faire, éxécutez la commande sudo apt-get install virtualbox-ose Installation sous Windows Pour installer VirtualBox sous Windows vous devez vous rendre à cette adresse http ://www.android-x86.org/download Téléchargez la version pour Windows et installez la. Utilisation de VirtualBox VirtualBox est un logiciel de virtualisation totalement gratuit. Une fois téléchargé et installé, éxécutez VirtualBox. Cliquez alors sur Nouvelle, dans la fenêtre qui s ouvre faites suivant, Donnez un nom comme Android, choisissez Linux comme systeme et 2.6 comme version. Il est ensuite conseillé d utiliser aux environs de 300 Mio pour la mémoire vive.faites suivant trois fois en laissant une image de disque de taille variable.choisissez l emplacement ou stocker le disque virtuel.puis enfin cliquez sur Terminer. Lors du lancement VirtualBox vous demandera de lui donner le fichier iso que vous avez précédemment téléchargé. Vous pouvez maintenant utiliser Android. Si vous voulez utiliser VMWare plutot que virtual box ceci est tout à fait possible et la marche à suivre est identique. 1.3.3 Utilisation à partir d un livecd Il est possible d utiliser Android sans forcément l installer. Ceci est la méthode la plus simple mais pas toujours la plus pratique lorsque que l on veut installer des programmes sur Android. C est plûtot une méthode pour tester le système. Pour utiliser un live CD, vous devez le télécharger à cette adresse : http ://www.android-x86.org/downloadhttp ://www.android-x86.org/download Prenez la version live. Il vous faut alors la graver, et vous pouvez directement l utiliser. (Il est aussi possible de le faire par USB au lieu d un CD).

1.3.4 Compilation des sources Sous Linux, (ici testé sous ubuntu 10.10) il est possible de télécharger et compiler les sources android. Pour ce faire, il faut se rendre sur le site : source.android.com/source/download.html Il faut alors suivre le tutorial indiqué. Attention, avant de faire la partie Building the code il faut modifier la version de gcc installée. Si vous possédez la version 4.3 il n y aura pas de soucis, par contre si vous avez la version 4.4, il faut la downgrader. Pour connaitre la version de gcc, lancer la commande : gcc -v Pour downgrader éxécutez ces commandes : sudo apt-get install gcc-4.3 g++-4.3 g++-4.3-multilib rm /usr/bin/gcc rm /usr/bin/g++ ln -s /usr/bin/gcc-4.3 /usr/bin/gcc ln -s /usr/bin/g++-4.3 /usr/bin/g++ Vous aurez alors a compiler android par la commande make Nous disposons maintenant d un Android compilé. A moins de disposer d une plateforme compatible Android, le mieux serait de pouvoir l utiliser sur un ordinateur. Nous allons donc utiliser un émulateur pour cela. Nous pouvons trouver cet émulateur dans le sdk fourni par la communauté Android. Le sdk est téléchargeable à cette adresse : http ://developer.android.com/sdk/index.html. Il faut extraire l archive. [8] Puis pour exécuter l emulateur : export PATH=$PATH:/chemin d acces au sdk/android-sdk-linux_x86/tools export ANDROID_SOURCE=~/dossier d installation d android export ANDROID_PRODUCT_OUT=${ANDROID_SOURCE}/out/target/product/generic_x86 export ANDROID_PRODUCT_OUT_BIN=${ANDROID_SOURCE}/out/host/linux-x86/bin export PATH=${PATH}:${ANDROID_PRODUCT_OUT_BIN}:${ANDROID_PRODUCT_OUT}; emulator -system system.img -data userdata.img -ramdisk ramdisk.img A partir d ici une fenêtre s ouvre, cette fenêtre contient l éxecution d Android que l on a compilé. 1.3.5 Sur un téléphone portable Déja sur Android Ceci est LA méthode la plus simple, si vous désirez utiliser le système Android. Si vous possèdez un téléphone portable qui tourne déja sur Android, vous n avez rien à faire juste l utiliser. En changeant la rom Sur certains téléphones, il vous est possible de changer votre système. La plupart des téléphones compatibles sont à la base sous Windows Mobile. Ce changement de rom n est malheureusement pas stable du tout et la moitié des fonctionnalités des téléphones ne sont pas prises en charges.

Android Chapitre 2 Présentation du temps réel, essai sur Android 2.1 Présentation du temps réel En une phrase, on parle de temps réel quand les informations qu on traite sont toujours aussi pertinentes par rapport à quand elles ont été émises. En informatique industrielle, on parle d un système temps réel lorsque ce système informatique contrôle (ou pilote) un procédé physique à une vitesse adaptée à l évolution du procédé contrôlé.(sources wikipedia.fr) Les systèmes en temps réel doivent prendre en compte des contraintes temporelles. Ces contraintes temporelles sont aussi importantes que le résultat que le système renvoi. Le système à des délais, ces délais doivent impérativement êtres respectés. Les systèmes informatiques temps réel sont aujourd hui présents dans de nombreux secteurs d activités : dans l industrie de production par exemple, au travers des systèmes de contrôle de procédé (usines,centrales nucléaires), dans les salles de marché au travers du traitement des données boursières en temps réel, dans l aéronautique au travers des systèmes de pilotage embarqués (avions, satellites), ou encore dans le secteur de la nouvelle économie au travers du besoin, toujours croissant, du traitement et de l acheminement de l information (vidéo, données, pilotage à distance, réalité virtuelle, etc.). Le développement de systèmes temps réel nécessite donc que chacun des éléments du système soit lui-même temps réel, c est-à-dire permette de prendre en compte des contraintes temporelles. Un système d exploitation conçu pour prendre en compte ces contraintes est appelé système d exploitation temps réel. [20] Parmis ces systèmes d exploitation gérant le temps réel nous avons : Adeos ART Linux ChorusOS DSP/BIOS ecos ELinOS FreeRTOS irmx ITRON LynxOS MicroC/OS-II Nucleus OS-9 OSE OSEK/VDX psos PikeOS QNX RedHawk RSX-11 RT-11 RT-LAB RTAI RTEMS RTLinux ou Real Time Linux RTOS-UH RTX SCEPTRE 8 L A TEX

SCIOPTA Symbian OS VRTX VxWorks Windows CE Xenomai Pouvoir utiliser le temps réel sous Android pourrait être d une importance capitale. Le nombre de tablettes tactiles utilisant Android est en constante hausse. A l aide de ces tablettes ou de simples télephones portables, il serait possible de réaliser les exemples précédemment donnés. Ce n est pas un marché à ignorer. Il nous faut donc savoir si Android est capable de supporter le temps réel. 2.2 Notions 2.2.1 État d un processus Un processus peut être dans différents états : D sommeil irrévocable R exécution S en sommeil mais redémarrable, notamment par le scheduler T arrêté X mort Z zombie, mort mais pas accusé au parent cf 2.1 Figure 2.1 Etats d un processus et principales transitions. On voit que certains états sont des états puits et qu on ne peut en sortir par le simple scheduler : gestion manuelle par redémarrage ou kill -9 Et l ordonnancement intervient lors du passage d un état à l autre. 2.2.2 Temps Réel Priorité Le problème avec l ordonnanceur CFS Linux est qu il n est pas temps réel, au sens que les tâches sont dotées d une priorité dynamique et que le but du temps réel de base est d avoir des tâches prioritaires une bonne fois pour

toute. Hors CFS essaie de répartir le même temps à toutes tâches, si bien qu une tâche qui prend le processeur passe d une faible priorité à une haute priorité, et une fois qu elle a utilisé son timeslice, elle devient moins prioritaire : on voit donc que la priorité dynamique change et c est le principe intrinsèque d une tâche sous CFS avec la convention dynamicpriority = max(100, min(staticpriority bonus + 5, 139)) cf [14] p260 Au niveau du code, on le voit dans la fonction recalc task prio( ) Plusieurs temps réels Certes, le noyau Linux d Android gère bien du temps réel avec SCHED FIFO SCHED RR mais ce n est pas du vrai temps réel car [14] p312 : SCHED FIFO basé FCFS(First Come First Served)premier rendu premier servi SCHED RR qui assure une préemption qu à intervales réguliers et non pas quelconques De plus, il ne faut pas confondre temps réel mou qui tolère une certaine variation du temps de latence temps réel pur qui ne souffre d aucun retard 2.3 Etude d Android pour le temps réel Nous allons maintenant essayer de voir si Androïd fonctionne en temps réel. Pour cela nous allons nous appuyer sur quelques articles de recherche. Le premier [12] est un article testant Android sur le temps réel. Pour ce faire, des tests sur la Texas Instrument Zoom II Mobile dévelopment kit ont étés réalisés. Ces tests ont pour but de déterminer si Android est capable de respecter des contraintes temporelles. Pour faire ces tests, ils ont créer deux applications la première partie est l application Test qui va éxécuter des tâches selon des temps donnés, le test permettra de savoir si des violations d échéances ont eu lieu. Le test donnera également le nombre de ces violations. la deuxième partie est l application Loading qui va faire tourner le CPU et les autres I/O ressources. Ceci afin de faire saturer le système. Cette application a trois états, un état éteint, ou l on test que les tâches sans rien d autre. Un état normal ou les ressources sont utilisées moyennement, et un état fort ou un maximum de ressources est utilisé. Les résultats sont alors écrits dans des fichiers textes. voici par exemple le diagramme obtenu lors d un loading fort Figure 2.2 délais

Nous voyons sur ce graphique plusieurs choses. Le S de la légende est pour Slippage, qui est le temps d attente entre le moment ou l on demande d éxécuter la tâche et le moment ou elle s éxécute réellement. Nous remarquons que ce temps est de plus en plus long. De plus, le Slippage est de plus en plus fréquent. Il en ressort plusieurs problèmes. Il y a un temps de latence dans le noyau de Linux, mais également un autre temps de latence pour passer la main à la machine virtuelle d Android Dalvik. Il y a lors des tests des temps de réponse trop important. Si nous utilisons Android pour des applications à forte demande temps réel, nous voyons bien qu Android n est pas capable de le gérer.android ne semble donc pas adapté par défaut à du temps réel. 2.4 Travaux déja effectués Nous ne sommes certainement pas les premiers à nous pencher sur ce problème. Si nous voulons vraiment avancer, il nous faut commencer par regarder ou en est la recherche sur ce domaine aujourd hui. Une entreprise Esol à l air de travailler sur ce domaine spécifiquement. Après lecture de l article qu ils ont publié [13], nous pouvons voir qu ils n ont pas fait que s intérresser au problème. Ils ont trouvé une solution bien à eux. En effet, Android repose sur Linux 2.6 qui à la base n est pas un système temps réel. Esol a donc décidé d enlever Linux pour mettre leur propre système d exploitation. Le kernel de Linux à donc été remplacé par et-kernel Adaptor for Android. voici un schéma représentant leur produit final : Figure 2.3 architecture esol Cette solution semble très efficace, d après ce qu ils peuvent écrire. Cependant, cette solution n est pas libre. De plus, ils ne travaillent que sur leurs propres matériel, ce n est pas une solution temps réel grand public. Nous gardons quand même leur idée de modifier le kernel pour obtenir du temps réel, même si nous ne developperons pas comme eux notre propre kernel. Nous pouvons plûtot envisager une modification du noyau de Linux, sous forme de patch. Cette solution nous semble déja plus envisageable.

2.5 Autres pistes de recherches A partir du dernier article qui nous était fourni [4]. Nous en apprenons davantage sur l ordonnanceur de Linux. Ce qui sera certainement une piste à étudier plus en détails. Nous expliquerons le fonctionnement de l ordonnanceur dans la partie suivante. Une des possibilités décrite est donc de modifier l ordonnanceur de Linux, pour qu il accepte le temps réel, cela rejoint un peu le point précédent, sans être tout à fait pareil. Ici on modifierai directement le code de l ordonnanceur, il n est pas question de patch. Ici nous chercherons donc comment et ou est implémenté l ordonnancement pour le modifier. Une autre solution plus avantageuse serait de modifier également la VM Dalvik. Dans la partie précédente, on a vu qu Android reposait sur Linux au niveau le plus bas. Au niveau juste au dessus nous avons la couche runtime avec à l intérieur la VM Dalvik. Une solution pourrait être de faire en sorte que cette machine virtuelle accepte d ordonnancer du temps réel. Nous expliquons davantage l utilité de Dalvik et son fonctionnement dans la partie décrivant l arborescence d Android. En bref, avoir un Linux temps réel et une machine virtuelle temps réelle donnerait une performance bien plus élevée. Pour rendre la VM Dalvik temps réelle, on peut l étendre en utilisant RTSJ (Real-Time Specifications for Java). Dalvik étant écrite en JAVA, on peut utiliser cette extension. Le problème majeur reste donc de modifier l ordonnanceur CFS de Linux. Nous voyons donc que deux approches se dégagent aux vues des recherches qui se font déja. La première serait de modifier Linux à la main c est à dire aller chercher dans le noyau Linux ou se passe l ordonnancement, et le modifier pour le rendre temps réel. La deuxième approche serait d essayer de regarder les solutions qui existent déja pour essayer de patcher Linux pour le rendre temps réel. Nous voyons quand même que les deux solutions reposent sur le même principe modifier Linux et non (ou seulement en partie) Android. Dans les grandes lignes, pour rendre le noyau temps réel, on devra s attacher à : sensibilité aux interruptions en noyau, ISR attention au phénomène d inversion de priorité ressources gérees par mutex plus performantes que les verrous tournants unités de temps fines

Android Chapitre 3 Première approche de recherche : Modification de l ordonnanceur 3.1 Etude de l ordonnanceur CFS de Linux Android 2.2 Froyo est basé sur un noyau linux 2.6.35.7. Depuis la version 2.6.23 du noyau on utilise l odonnanceur Completly Fair Scheduler (ou CFS). Il est basé sur un arbre binaire de recherche rouge-noir. Le principe est simple : on trie les processus en fonction du temps passé en exécution sur le processeur et on les stock dans cet arbre. Le processus qui aura passé le plus de temps en exécution sera tout à droite de l arbre. Ainsi l ordonnanceur choisi toujours la tache la plus à gauche. La tache est ensuite réinsérée dans l arbre et grâce à aux propriétés des arbres rouge-noire il reste à peu près équilibré. Figure 3.1 Arbre de priorité des taches L ordonnanceur CFS est implémenté dans kernel/kernel/sched fair.c Les fonctions importantes de l ordonnanceur sont définie dans la structure sched class. enqueue task(...) est la méthode qui ajoute les taches dans l arbre rouge-noire. 13 L A TEX

dequeue task(...) supprime une tache. pick next task(...) choisit la prochaine tache à être exécutée. task tick(...) est la méthode qui peut faire les préemptions. Elle est appelée par scheduler tick(void) elle même appelée en boucle par le timer. 3.2 Resultats Quand on veut rajouté la gestion des taches temps réel dans l ordonnanceur CFS on s aperçoit qu il y a une incompatibilité avec la structure utilisé. En effet la gestion des priorités est faite par un arbre qui trie les taches par temps d exécution. Cependant la priorité des taches temps réel n est pas basé sur le même critère. Si par exemple on veut avoir un ordonnancement de type EDF on ne peut pas avoir un arbre qui trie les taches à la fois par deadline et par temps d exécution. La prise en compte des taches temps réel par l ordonnanceur de linux demande donc une refonte de sa structure. En se contentant d un simple RT, comme RM, il faut quand même [3] respect des échéances temporelles bonne gestion de la montée en charge car jusqu à un seuil critique, la surcharge ne doit pas être préjudiciable au respect des échéances si un pool de tâches doit être traité, le système doit dire à l avance si c est possible ou pas avant de se lancer dans des calculs, qui peuvent engager de gros risques : prédictibilité le système doit être robuste et une tâche ne doit pas mettre en péril l intégrité du système. pour être facilement maintenable sans connaître parfaitement le système tout entier, le paradigme doit être basé sur le modulaire. Le noyau Android est-il CFS donc complexité O(1) avec le noyau 2.6? En effet, pour respecter la prédictibilité, un temps constant est tout indiqué, même si pour connaître cette donnée spécifique, liée au matériel qui interprète le code compilé du scheduler par exemple, il faut faire des mesures expérimentales. une connaissance parfaite du matériel(dma,processeur) doit être requise, ce qui n est jamais le cas dans la réalité.certes ils permettent des accélérations, mais sont une source d incertitude dommageable en situation critique. une autre source d indeterminisme est le comportement du gestionnaire de tâche lui-même : gestion des ressources,etc. Pour être sûr de ne pas être ennuyé par des aléas, on se contentera de simples RM sans ressources. Il vient : comment lancer la gestion de telle tâche? Comme sous GNU Linux, on peut lancer des tâches par un premier processus init. Et les redémarrages ne font pas de mal à la machine et sont rapides(voir ultra rapide : redémarage à la volée,sans boot) car on est en émulation. 3.2.1 Notion de tâches Ce sont les entités qui seront traitées par le scheduler. On peut aussi dire processus ou par abus de langage, démons. La petite différence vient qu en principe un démon reste toujours en arrière plan et n interragit avec l utilisateur qu indirectement ; on dit aussi des services(voire processus batch [5] p256), dont la santé est primordiale, c est pourquoi ils sont eux-mêmes gérés par des super-serveurs (inetd,xinetd qui gèrent notamments les intérruptions par redémarrage automatique en cas de bug par exemple). Si on regarde plus précisément un processus, c est la donnée d un descripteur de processus qui permettent au scheduler le gérer convenablement. [14] indique qu il contient différents champs : state, thread info, usage flags, run list tasks, mm, real parent parent, tty, thread, fs, files, signal pending. 3.2.2 Théorie Par une simple simulation hors-ligne des valeurs calculées par le ordonnanceur.

3.2.3 Pratique En introduidant des métriques (ps,graphique, moniteur système(notion de monitor?)) pendant que le scheduler est en situation.comme le chat de Schrödinger, ça change légèrement le comportement, mais peut être considéré comme négligeable, d autant plus si ces métriques sont prises en compte par le scheduler et bien traitées(idéee de récursion : le ordonnanceur doit traiter une entité qui le mesure lui-même?), et si les vraies tâches montent en charge, leur proportion de prise de processeur augmente(seuil critique?). Protocole Dans la vulgarisation scientifique, les résultats ne sont pas envoyés directement à l écran à cause de gros temps de latence. Des solution sont donc des sorties des mesures de temps de changement d états haut ou bas d une tâches par des ports parallèles ; ou par des sorties fichiers pour analyse à postiori. Résultats attendus, comparaisons Les plus simples comparaisons sont de voir la différence pour un système normal et temps réel entre système chargé 3.2 ou pas 3.3. La charge peut être apportée par des top rapprochés top -d 0 Figure 3.2 Différence pour un système non temps réel entre non chargé et chargé

Figure 3.3 Différence pour un système temps réel entre non chargé et chargé

Android Chapitre 4 Seconde approche : Application du patch RTAI pour Linux sur Android RTAI est une extension libre de Linux. Cette extension permet au système de gérer des tâches temps réelles. RTAI fonctionne sous la forme d un patch à appliquer directement au noyau de Linux. Etant donné qu Android est basé sur un noyau Linux, nous allons par la suite essayer de patcher ce noyau, pour qu Android tourne en temps réel. 4.1 Patch RTAI Pour comprendre comment fonctionne RTAI, nous avons commencé par l essayer sur un Linux classique. Nous avons récupéré un kernel sur kernel.org. Nous n avons pas pris n importe lequel, nous avons pris le 2.6.35.7. Ce kernel est celui sur lequel se repose Android 2.3 auquel nous avons précédemment récupéré les sources. Il nous faut maintenant récupérer la version de RTAI qui permet de patcher ce kernel. Après quelques recherches il s agit de RTAI 3.8.1. Nous la téléchargeons donc sur www.rtai.org. Pour appliquer le patch nous avons suivi le tutoriel http ://cedric.cnam.fr/ bouzefra/installation rtai.pdf [7] Ce tutoriel expose point par point comment appliquer RTAI sur un noyau Linux dont on dispose des sources. Ce tutoriel est pour une ancienne version de RTAI et de Linux mais la procèdure n ayant pas changé, cela ne pose pas de soucis. On obtient un fichier patch.txt qui indique que le patch s est correctement installé. Ce fichier patch est donné en annexe. Si on applique ce patch à l arborescence Android, nous obtenons un fichier patch.txt remplis d erreurs. Il nous faut nous placer dans le dossier kernel pris de Linux, et la le patch se déroule correctement également. Nous obtenons ainsi un Android temps réel. Nous reste maintenant à le compiler. Pour ce faire, nous suivons la procèdure décrite dans le tutorial précédemment donné. Nous obtenons ainsi un Android compilé basé sur un noyau temps réel. Cependant, lorsque nous l éxecutons, nous n obtenons qu un écran noir. Le patch RTAI a du modifier des éléments qu Android à besoin. Il nous faut maintenant trouver ce qui utilise les fichiers modifiés par RTAI. 4.2 Etude de l arborescence Android 4.2.1 bionic Ce terme fait penser aux extensions mécaniques et robotiques de l Homme. Y-a-il un rapport. libc libdl libm libstdc++ libthread db linker : ce sont principalement des bibliothèques pour développer en C. Il y a les librairies partagées, dynamique,mathématique... Il y a également du C++, de la gestion de parallèlisme, de l assemblage en exécutable ELF(donc compatible Linux). Bionic semble être un nom quelconque, mais marque la spécificité par rapport aux bibliothèques POSIX GNU Linux : en [8] 17 L A TEX

4.2.2 bootable Notion de démarrage sous Linux En fait le démarrage est une succession de prise en charge de matériel et codes. Cette prise en charge est de plus en plus importante au cours de la session car la reconnaissance est incrémentale et est basée sur la capacité du chaînon précédent [16]. Pour nous, le démarrage est très important car c est par lui qu on pourra introduire notre textbfscheduler qui fonctionnera alors en autonome. Ainsi, à l appui sur le bouton ON d un PC, on passe par le mode Réel du processeur x86 [16] [5] : le POST qui teste les différents matériels le bootstrapping avec entre autres le BIOS( Basic Input/Output System) qui est une ROM qui teste le matériel non volatile comme les disques durs, carte PCI, lecteur de CD-ROM qui se trouvent à des adresses prédéfinies. Selon les matériels bootables et l ordre de nos préférences, il donne la main au CD-ROM ou à des gestionnaires de démarrage de second niveau : GRUB, LILO, etc, selon les secteurs de boot(446octets) du Master Boot Record (MBR) en début de disque,suivi par notamment 64 pour une table de 4 partitions primaires maximum. GRUB, LILO Ce sont les démarreurs des disques durs implémentant GNU Linux. Ils chargent surtout les OS correspondant, et leur donnent la main : que ce soient des vrais systèmes avec noyau( avec certaines options) ou de simples programmes. Ils donnent eux-même la main au noyau en mode réel où on a accès qu à 1MB de mémoire non protégée, où évidemment ce n est pas le vrai noyau qui est chargé On passe alors au mode protégé qui lance : le vrai noyau et des fonctions processeurs plus étendues comme la pagination. Le noyau devant s appliquer au contenu d un disque, pour pouvoir lire ses données(en EXT2,3,4,etc), il lance les premiers drivers disques spécifiques à la partition pour pouvoir la monter, grâce à initrd ou initramfs(la différence est une simple optimisation de la mémoire en taille, fragmentation, indépendance à un autre système de fichier). init(), le père de tous les processus. C est lui qui lance les processus utilisateurs et les démons : consoles, login. Après, pendant la session, le processeur peut passer : en mode noyau : il a alors tous les droits(processeur, noayau), mais doit avoir les droits root, car passer dans ce mode peut planter la machine, il faut donc des gens qui savent ce qu ils font(codeurs du noyau, ou root). Autre grand avantage : ce code peut préempter d autre code. ou mode utilisateur : mode sécurisé où la machine n est pas en péril. cf 4.1 Figure 4.1 Séquence de démarrage sous Linux

Où intervient le scheduler? [5]p257 : alors qu on aurait pu croire que ça allait être une sorte de super processus à la priorité dynamique maximale 100 ([14] p260), ce n est pas un processus mais une simple fonction qui est appelée lors de chaque laps de temps slice, et qui traite les différentes listes par priorités. Sous Android En gravant les CDs sous Linux, bootable fait plutôt penser à la section d amorçage des CDs pour pouvoir démarrer une distribution au démarrage de l ordinateur(post) i.e. Power On Self Test). bootable n est pas présent dans l arbre Linux. En regardant la structure sous Android, on voit bootloader diskinstaller recovery. Donc, notre première impression se voit confirmée. Sur Linux, pour graver un CD-ROM, on utilise mkisofs et cdrecord, et ce qui le rend bootable :??. De prime abord, on peut se demander ce que les CD viennent faire là, sachant que les appareils Android sont soit des téléphones, soit des tablettes sans fonction de gravure. À cela, on répond que comme l émulation préconisée par nous à partir d un CD, si cette procédure marche, l installation sur n importe quel CD est censée fonctionner de fait sur n importe quelle machine PC ; d autre part, c est peut-être aussi du code emprunté à Linux pour une adoption de masse pour les machines sous Android. D autre part, si on n envisage pas encore beaucoup de PC sous Android, n oublions pas aussi que les clés USB autres cartes Flash sont elles aussi bootables et plus envisageables car les tablettes proposent souvent des ports dédiés. 4.2.3 build La création de quoi? Du noyau, comme xconfig ;make ;make install pour installer un noyau et ses modules? Ce module se compose de core libs target tools. core ne contient presque que des.mk, ce sont donc des directices de compilation libs target désigne les cibles sur lesquelles intaller Android, avec board/generic pour des matériels generiques, sans noyau, traités par émulation, permetant une prise en charge de purs systèmes user, ces produits sont pour le moins exotiques(cf README.txt). tools : différent utilitaires (bizarre le traitement des progragrammes Java par des.mk dans beginverbatimbuild/tools/droiddoc/src endverbatimau lieu de Ant). Par qui sont utilisés ces utilitaires? 4.2.4 dalvik Généralités Dalvik est une machine virtuelle basée sur les registres qui gère la plate-forme Java sur les appareils mobiles Android. Dalvik a été écrit par Dan Bornstein qui l a nommé d après le village de pêcheurs de Dalvík en Islande [19]. Cette VM permet d exécuter les applications qui ont été converties en un exécutable compact Dalvik (.dex), un format adapté aux systèmes limités en termes de mémoire et de vitesse du processeur. On trouve donc Android sur des appareils le plus souvent mobiles comme un téléphone portable, une tablette numérique, etc... bref la plupart des appareils qui nécessitent un OS embarqué et possédant peu de ressources. Une fois les application Android compilées en fichiers.dex elles sont automatiquement zippés en fichier.apk (Android Package) [6]. Les classes compilées en.dex deux fois moins lourdes qu un fichier jar qui aurait été généré pour une machine virtuelle java quelconque [1]. On a généralement plusieurs classes java dans un seul fichier DEX. Le fichiers DEx procurent une très bonne optimisation car durant la génération d un fichier.dex on a recours à des répétitions minimale, des associatiosn par type et des labels implicites. Pendant l installation chaque fichier DEX est vérifié et les optimisations telles que le byte-swapping, bytepadding, la liaison statique et les méthodes in-line sont effectuées pour minimiser l évaluation du temps d exécution et éviter les violations de sécurité. L article cité précédemment est un extrait du livre de Sayed Hashimi, Satya Komatineni et Dave MacLean, Pro Android 2 [2]. On trouve dans cet article un exemple du gain d espace que procure la Dalvik VM. Pour un simple navigateur Internet qui équivaut à 500Ko en fichier.jar avec une VM java, équivaut à 200Ko avec les fichiers.dex et la machine virtuelle Dalvik.

La Dalvik VM utilisant les registres et non une pile, diminue ainsi le temps d exécutions de 30% grâce à une diminution de 30% du nombre d instructions par rapport à une utilisation dans une VM comme la Java VM. Cette diminution du nombre d instructions implique donc une diminution des accès en mémoire. Ce système du fichiers DEX à un impacte direct sur l optimisation de la mémoire, de la gestion de la batterie et sur la fréquence du CPU. En revenche on ne peut pas utiliser le Java byte-code avec Android, on est obligé de passer par les fichiers de classes qui seront donc transformés en fichiers DEX. On trouvera la comparaison entre un fichier.jar et un fichier.dex sur la figure 4.2 [9]. Figure 4.2 jar vs..apk Voici les différents dossiers que l on peut trouver dans le dossier dalvik : (liste non-exhaustive) dalvikvm : appel des lignes de commande de la machine virtuelle Dalvik dexdump : imitation d un objdump dexlist : liste toutes les méthodes de toutes les classes concrètes dans un ou plusieurs fichiers.dex dexopt : optimisation des commande DEX et vérification des entrées dvz : gère les instances de la VM libcore : toutes les librairies dont dalvik a besoin libdex : librairies en relation avec le format.dex libnativehelper : fonctions d aide pour les classes d Android vm : codes de la machine virtuelle Dalvik Démarrage La machine virtuelle Dalvik est capable de faire tourner plusieurs processus indépendants ayant chacun une adresse et une mémoire séparées. Durant le démarrage d un dispositif ou périphérique un processus est chargé de démarrer la machine virtuelle elle-même. On dispose d un processus de la VM nommé Zygote responsable de l initialisation et du chargement des classes Android les plus utilisées par la plus grande partie des applications. Ce zygote ouvre un socket qui accepte les commandes d une application quand une nouvelle application Android est démarrée. Le zygote crée un fils qui sera cette application. Les classes que l on a chargé dans le Zygote vont servir à cette application et sont partagées avec toutes les applications filles du Zygote. On chargera dans ce fils les classes propres à lui-même. On peut voir

ce système sur l image 4.3. Une telle approche permet d économiser de la RAM et et d augmenter la rapidité de démarrage des différentes applications. On ne peut pas utiliser le système de temps réel de Linux dans la machine virtuelle Dalvik. Figure 4.3 Zygote Heap (Tas) Garbage Collector Passons maintenant à la partie Garbage Collector de la machine virtuelle Dalvik. Les différentes threads s arrêtent eux-mêmes ou sont suspendus par le Garbage Collector (GC) ou un debugger. La machine virtuelle gère tous les threads créés grâce à une structure interne du style d une map. Le GC s occupe de la gestion de la mémoire dynamique en supprimant ou déplaçant les données qui ne sont plus utilisées par les applications. Tous les processus ont leur propre tas et un tas partagé avec les différents processus fils du Zygote (cf 4.3). Chaque tas est géré séparément par le GC. Les données contenues dans le tas du Zygote ne sont bien entendu pas supprimées par le GC car elles sont partagées entre différents processus fils, la gestion de la mémoire ne peut qu en être améliorée. Le GC utilise l algorithme mark and sweep. L algorithme Mark and Sweep est probablement le plus simple et le plus connu. Dans son principe, lorsque le GC se déclenche, il part des références racines de l application et suit récursivement toutes les références qu il rencontre. Chaque objet ainsi visité est marqué, il est effectivement accessible au programme, et ne doit en aucun cas être supprimé. Dans un deuxième temps, le GC joue le rôle du balayeur (opération sweep ), il parcourt linéairement le tas, objet par objet, et supprime tout objet qui n est pas marqué et récupère la mémoire qui lui était allouée. Bien entendu, il efface également les marques des objets survivants en prévision de la prochaine collecte [10]. On peut voir le mécanisme sur la figure 4.4. Il est évident que la collecte des objets (du moins la première étape mark ) ne peut s effectuer que si tous les threads applicatifs sont arrêtés. Donc lorsque le GC se lance, l application s interrompt complètement. L algorithme Mark and Sweep est très simple, mais pose un certain nombre de problèmes : son temps d exécution est proportionnel à la taille du tas il laisse le tas fragmenté il fonctionne mal si les objets n ont pas une taille globalement uniforme Voilà pour la partie GC de dalvik, on va maintenant voir si la VM gère l ordonnancement temps-réel sous Android. La Dalvik VM gère-t-elle l ordonnancement sous Android? La machine virtuelle Dalvik ne supportant pas la compilation Just-in-Time (JIT) pour l instant (en cours de préparation pour une prochaine version), toute la partie ordonnancement est traitée par l ordonnanceur du noyau Linux d Android ainsi que la gestion de la mémoire et la gestion et la sécurité des processus. Pour information la compilation JIT, plus communément appelée compilation à la volée en français, est une technique visant à améliorer la performance de systèmes bytecode-compilés par la traduction de bytecode en code