Conduite du Projet Système

Transcription

1 Conduite du Projet Système Département Télécom 2ème Année Enseignants : Yves Denneulin, Jacques Mossière, Grégory Mounié, Simon Nieuviarts, Franck Rousseau, Sébastien Viardot Résumé Ce document est complémentaire aux spécifications du mini système d exploitation que vous devrez programmer. Il vise à vous aider en vous fournissant une méthode de développement bien précise. 1 Introduction Habituellement, la conduite d un projet consiste à passer par les phases d analyse du problème, de conception de l architecture, de codage et de débogage. Cette méthode ne peut être strictement appliquée dans le cadre du projet système à cause du trop court laps de temps imparti. En effet, si on vous demandait de la respecter, il est probable que vous ne seriez en mesure de produire les premières lignes de code que très tard dans le calendrier, et qu à la fin du projet, très peu de choses fonctionneraient. Or, nous considérons que le principal apport du projet système réside dans l expérience que vous apportera le fait de faire fonctionner votre noyau. Nous vous demandons donc de suivre un plan de développement en sept phases, de bien respecter dans chaque étape le cycle analyse-architecture-codage-débogage, mais d accepter de faire chaque phase sans avoir une vision très détaillée du fonctionnement final de votre noyau. Par exemple, les phases 2 à 5 visent à vous guider pas à pas dans l implémentation d un noyau de processus, en raffinant progressivement le cahier des charges. Cette méthodologie ne doit pas être perçue comme une contrainte, son unique but est de vous aider à organiser le développement de votre projet. 2 Plan de développement Le développement du projet système s effectue en sept phases obligatoires et une partie facultative. En quelques mots, les différentes étapes consistent à : phase 1 : prendre en main l environnement de développement (chargement et débogage de noyau) et gérer l affichage ; Revision : Date :

2 phase 2 : gérer la notion de processus, et le changement de contexte entre deux processus (au niveau noyau) ; phase 3 : gérer l ordonnancement, la création dynamique, la terminaison et la filiation des processus (toujours au niveau noyau) ; phase 4 : gérer la communication (via l emploi de sémaphores) et l endormissement (appel wait clock) des processus ; phase 5 : développer le chargeur de noyau, et mettre en place une séparation des codes noyau et utilisateur, en s inspirant du mode utilisateur (sur PC) ; phase 6 : développer un pilote de console ; phase 7 : développer un interprète de commandes, shell ; partie facultative : ajout de nouvelles fonctionnalités (par exemple, espaces virtuels d adressage). Toutes les phases ne sont pas équivalentes en termes de difficulté et de temps de développement/mise au point. En particulier, les phases 2 et 5 concernent des concepts clés du projet et sont délicates à déboguer. Pour bien maîtriser l évolution de votre travail au fil du projet, nous vous invitons à conserver une version de votre code pour au moins chacune des phases validées, en utilisant l outil de gestion de versions svn, et nous vous demandons de faire un point régulier chaque semaine avec un enseignant. 3 Phase 1 Cette partie consiste à prendre en main l environnement de travail qui vous sera nécessaire tout au long du projet. La principale différence avec les projets précédents concerne la façon de tester et déboguer le code que vous produisez. Passer de l environnement d exécution Unix, que vous avez l habitude d utiliser pour vos projets, à un PC quasiment nu change beaucoup de choses : le démarrage du programme, le support des entrées/sorties, le support de la libc, les facilités de débogage. Ce n est plus un shell qui lance votre programme mais le debugger qui charge la mémoire (dans un premier temps), puis un chargeur que vous développerez en phase 5. L absence du support usuellement fourni par le noyau Unix nous prive des E/S. L absence de gestion des entrées n est pas un handicap majeur pour les cinq premières phases du projet mais les sorties sont bien évidemment nécessaires dès le début pour pouvoir déboguer. La sortie se faisant par le port série, la visualisation des messages envoyés par le système sera visible sur un terminal série connecté au système (par exemple avec l utilitaire cu, si on utilise la carte avec un câble série connecté au PC de développement, ou avec vpio lancé depuis xmd si on utilise la plateforme virtuelle). Au niveau de cette phase, la gestion de l interface série, se fera sans interruption (attente active). Il est important de vérifier le bon fonctionnement de vos primitives d affichage car c est sur elles que reposeront vos tests tout au long du projet. 2

3 L absence de support de la libc, nous prive notamment d E/S formatées, de gestion de la mémoire, d exit. Pour la gestion de la mémoire, nous vous fournissons un allocateur pour la mémoire du noyau, nécessaire dès la phase 3, ainsi qu un allocateur pour les piles utilisateur des processus, nécessaire à partir de la phase 5. Pour pallier le manque de libc en ce qui concerne les sorties, nous vous fournissons une mini bibliothèque, incluant notamment printf, à interfacer avec vos primitives de gestion de l écran pour faciliter votre débogage. Pour la terminaison d un programme, vous pouvez faire un appel à void reboot() qui a pour effet de redémarrer le système. Au niveau du débogage, vous avez toujours la possibilité d utiliser mb-gdb. Il y a quelques petites différences d utilisation liées au fait que le code à déboguer s exécute sur une machine distante mais les fonctionnalités offertes par le débogueur sont les mêmes. Par ailleurs, vous êtes privés de la mémorisation de l interaction faite par un xterm ainsi que de la possibilité de rediriger les sorties de votre programme dans un fichier. 4 Phase 2 C est une phase importante car elle introduit des concepts clés pour le projet. Il y a peu de code à produire mais il faut prendre le temps de bien cerner et comprendre tout ce qu elle implique. Elle consiste à gérer : dans un premier temps, la notion de processus et de changement de contexte entre deux processus ; dans un second temps, le timer et les interruptions, pour obtenir un système à temps partagé. Jusqu à la phase 4 inclue, les processus à gérer s exécutent uniquement en mode superviseur. Ils ont une pile chacun pour leur exécution. Nous vous conseillons de commencer avec deux processus infinis, créés statiquement, qui se passent la main à tour de rôle, par un appel direct à context switch. Les piles peuvent être allouées statiquement ou par appel à l allocateur de mémoire. Le code de la figure 1 propose un exemple minimaliste de processus de test. Une fois le mécanisme de base opérationnel, vous pouvez ajouter la gestion des interruptions et partager le temps d exécution entre deux processus. Pour gérer le temps partagé, vous devez programmer le timer, ce qui ne présente aucune difficulté majeure, et gérer les interruptions matérielles qu il génère. Pour répondre aux interruptions du timer, il est nécessaire d écrire un traitant en assembleur qui se termine par une instruction iret. Ce programme en assembleur ne doit faire que le strict nécessaire pour déléguer le gros du travail à une fonction écrite en C appelée par une instruction call. Dans un premier temps cette fonction fera toujours un changement de contexte entre les deux processus. Dans un deuxième temps, il faudra suivre le compte du temps écoulé afin de changer de contexte à une fréquence SCHEDFREQ (=50) différente de CLOCKFREQ (=100). Le code de la figure 2 propose un exemple de processus test pour le temps partagé. Le démasquage des interruptions après l appel à printf est nécessaire pour que le processus courant puisse être interrompu. En principe, à cette exception près, tout votre code noyau 3

4 int tsta(void *arg) { unsigned long i; while (1){ printf("a"); /* l autre processus doit afficher des B */ /* boucle d attente pour ne pas afficher trop de caractères */ for (i = 0; i < ; i++); context_switch(); } } Fig. 1 Programme de test pour le changement de contexte doit toujours tourner en mode masqué. int tsta(void *arg) { unsigned long i; while (1){ printf("a"); /* l autre processus doit afficher des B */ asm volatile ("sti"); /* demasquage des interruptions */ /* une ou plusieurs it du timer peuvent survenir pendant cette boucle d attente */ for (i = 0; i < ; i++); asm volatile ("cli"); /* masquage des interruptions */ } } Fig. 2 Programme de test pour le changement de contexte en temps partagé 5 Phase 3 Cette étape est la suite directe de la phase précédente. Elle consiste à gérer tout ce qui concerne le cycle de vie des processus, toujours en mode superviseur. Nous vous conseillons de procéder par étapes, dans l ordre qui suit : gestion de l ordonnancement par le scheduler, et de la création dynamique des processus ; gestion de la terminaison des processus ; gestion de la filiation. Vérifiez bien que vos fonctions ont un comportement conforme à la sémantique de l énoncé. 4

5 6 Phase 4 Cette phase consiste à implémenter les sémaphores et le cas échéant la gestion de l endormissement de processus. Les tests minimaux à valider à la fin de cette phase sont : sémaphores : un système producteur/consommateur(s). wait clock : le programme principal lance 4 processus P1 à P4 et exécute un wait clock d une minute ; le processus P1 imprime le caractère. à raison de un par seconde ; le processus P2 imprime le caractère - toutes les 2 secondes ; le processus P3 imprime le caractère + toutes les 5 secondes ; le processus P4 imprime le caractère * toutes les 10 secondes ; la périodicité est gérée par un appel à wait clock dans tous les cas ; à son réveil, le processus principal tue ses fils et se termine. On doit voir une alternance correcte des différents caractères. Il est important de bien déboguer cette partie, en envisageant le maximum de cas de figure. Bien penser que ces fonctionnalités de synchronisation seront utilisées dans de nombreux tests jusqu à la fin du projet. 7 Phase 5 C est une phase délicate. L ensemble des problèmes qu elle pose doit être pensé comme un tout. 7.1 Tour des problèmes Séparation physique du noyau et de l application Dans les phases précédentes, les programmes de tests étaient inclus directement dans le noyau, sous forme de fonctions. L application en mode utilisateur, elle, n est pas liée avec le noyau. Elle est liée séparément et chargée à l adresse 0x Il faut donc bien avoir conscience que le noyau et l application sont deux programmes indépendants qui ne partagent pas de mémoire. Si le processeur le permettait il serait possible de mettre en place une protection qui empêche l application de lire ou écrire des données du noyau dans le crt0 du noyau. Pour cette raison (et se placer dans ce contexte), on s interdira d appeler directement des fonctions du noyau depuis l application. Réalisation d une bibliothèque des appels noyau Dans les étapes précédentes, l application appelait les services du noyau par pur appel procédural. Dès que le noyau et l application sont séparés, ceci n est plus possible. En outre, on réalisera un appel simulant la transition d un mode esclave (interruptible) vers 5

6 un mode maître (non interruptible). L application le fera en exécutant un appel à une routine placée dans USER VECTOR. (Cf. documentation du Microblaze p.31) Comme on veut laisser au programmeur la facilité d écrire dans son source des appels au noyau par appel de fonction, il faut écrire tout un ensemble de fonctions 1 qui auront pour but de faire appel à la routine placée dans USER VECTOR. Ces fonctions seront écrites en assembleur et mises dans une bibliothèque qui jouera donc pour vos applications le rôle que joue la libc dans le système Unix. Ecriture du module de récupération de l appel à USER VECTOR Puisque l application déclenche un appel noyau, il faut bien la récupérer dans le noyau. Il est donc nécessaire d écrire un traitant pour gérer ces interruptions logicielles. Les remarques évoquées au sujet du traitant des interruptions timer en phase 2, quant au découpage assembleur / C, restent valables ici (il faudra mettre en place le masquage des interruptions non prévu dans le cas de l appel à USER VECTOR). Le point délicat ajouté dans leur gestion est de retrouver les paramètres de l appel noyau pour les passer à la routine du noyau qui en a besoin. La stratégie à adopter pour transmettre les paramètres est la suivante : utiliser les registres du processeur. Lancement des processus de l application en mode esclave Dans les phases précédentes, le noyau pouvait lancer un processus de l application par un appel procédural. Ceci n est plus possible lorsque le noyau s exécute en mode maître et l application en mode esclave puisque le lancement d un processus par le noyau correspond à une transition de mode. Pour faire comme si le processeur était capable de gérer les transitions de mode, il faut donc trouver un moyen de lancer un processus en faisant une transition de mode. Il faut pour cela utiliser une instruction retid. Une application doit s exécuter avec les interruptions démasquées. Gestion de deux piles par processus : spécifique x86 Lorsque le processeur x86 réalise une transition du mode esclave vers le mode maître, il procède également à un changement de pile. Lors de la transition esclave vers maître, le pointeur de pile est chargé avec une valeur prise dans la structure TSS, et lors de la transition maître vers esclave, le registre esp est chargé avec la valeur sauvegardée dans la pile maître. Ce mécanisme est imposé par le processeur, il est impossible d y échapper. À partir de cette phase, il faut donc gérer deux piles par processus, une pour le mode maître et une pour le mode esclave. Le principe des 2 piles est à mettre en place pour l implémentation sur le microblaze. 1 une par appel noyau 6

7 Protection de l espace des entrées/sorties : spécifique x86 L espace des registres d E/S ne doit être accessible qu en mode maître. Cette protection peut être mise en oeuvre en affectant un iopl de 0 dans les flags de l application. Lorsque cette protection est mise en place, l application ne peut donc pas écrire directement. Pour les besoins des sorties des programmes de test, vous devrez donc créer un appel système cons write pour gérér l affichage à l écran. Le formatage des sorties effectué par printf doit quant à lui rester en mode utilisateur. 7.2 Chargeur du noyau A partir de cette phase, on demande de mettre en place un chargeur du noyau. Ce programme sera mis dans la bram (0x0000 à 0x1FFF). Au reset du système, la carte envoie sur le port série un message du type : Attente du noyau. A partir de ce moment, les octets du noyau pourront être envoyés à la carte (via le port série) afin d être placés aux adresses 0x et suivantes. Un fois le noyau chargé en mémoire, le système démarre. 8 Phase 6 Cette partie consiste à implémenter une console. Il faut coder un pilote d entrée (entrée Rx du port série). Il faut réaliser un vrai pilote, c est-à-dire fonctionnant par interruptions. Ce qui vous est principalement demandé ici, c est de gérer les événements liés aux caractères arrivant sur le port série et d implémenter les appels système cons read et cons write. Le travail qui vous est demandé concerne les mécanismes de base de gestion des E/S. A ce niveau vous est demandé aussi de mettre en place également, un affichage par interruption, avec un buffer d une taille paramétrable (qu on fixera à 1000). 9 Phase 7 Cette partie consiste à implémenter un interprète de commandes, qui vous sera utile pour tester et démontrer le bon fonctionnement de votre système. Il est important de comprendre que ce shell doit être un programme utilisateur. Il ne doit pas accéder aux structures de données du noyau, la protection mémoire mise en place par le crt0 qui vous est fourni l en empêchera. Si votre shell doit récupérer des informations auprès du noyau, par exemple la liste des processus existants pour la commande ps, cela doit se faire par le biais d appels systèmes. Vous pouvez définir tous les appels systèmes qui vous semblent nécessaires. 7

8 10 Phase optionnelle Cette phase n est proposée qu à ceux qui, avant la fin du temps imparti, ont une réalisation impeccable de la partie obligatoire et souhaitent approfondir certains aspects de l implémentation d un système d exploitation. Avant de vous lancer dans cette phase, nous vous demandons de faire le point avec un enseignant pour : vérifier l état courant de votre implémentation ; déterminer, en fonction du temps restant et de vos intérêts, sur quel(s) aspect(s) travailler. Des idées de réalisations sont proposées à la fin de la spécification du noyau. 8