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 à l écran ; Revision : 319 Date : : 57 : (Lun, 04fà c v2008)

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 : ajouter le mode utilisateur ; 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 un chargeur développé spécifiquement pour cette tâche. Il faut donc respecter sa convention de chargement basée sur le standard multiboot (ceci est déjà implanté dans le code de base qui vous est fourni). 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 mémoire vidéo étant couplée en mémoire principale, les écritures à l écran se font sans faire intervenir les interruptions. Ceci peut donc se faire sans problème dans cette phase. 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. 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 2

3 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 la machine. Au niveau du débogage, vous avez toujours la possibilité d utiliser gdb/ddd. 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. Vous êtes donc limités à ne pouvoir inspecter à un instant donné que les 25 lignes affichables sur l écran. 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?? propose un exemple minimaliste de processus de test. 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 3

4 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?? 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 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 16 M. Il faut donc bien avoir conscience que le noyau et l application sont deux programmes indépendants qui ne partagent pas de mémoire. Le crt0 du noyau a mis en place une protection qui empêche l application de lire ou écrire des données du noyau. Pour la même raison, il est impossible pour l application d appeler des fonctions du noyau. 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, il faut réaliser une transition du mode esclave vers le mode maître. L application ne peut le faire qu en exécutant une instruction int. Comme on veut laisser au programmeur la facilité d écrire dans son source des appels au noyau par appel de fonction, il faut écrire 5

6 tout un ensemble de fonctions 1 qui auront pour but d exécuter une instruction int. 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 int Puisque l application déclenche une interruption par int, 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. 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. Il y a deux stratégies possibles pour transmettre les paramètres : les stocker sur la pile utilisateur ; utiliser les registres du processeur. La première solution est assez compliquée, en particulier parce qu elle oblige à gérer d éventuels défauts de page. Il est beaucoup plus simple et élégant de recourir à la seconde solution. Cela limite le nombre de paramètres à six, mais ce n est pas un problème. Nous vous demandons d utiliser la solution basée sur les registres. 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. Il faut donc trouver un moyen de lancer un processus en faisant une transition de mode. Il faut pour cela utiliser une instruction iret. Une application doit s exécuter avec les interruptions démasquées. Gestion de deux piles par processus 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. Protection de l espace des entrées/sorties 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. 1 une par appel noyau 6

7 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 Tests En fin de phase 5, vous devez au minimum valider les tests suivants : Test du mode utilisateur Écrire et faire fonctionner le programme suivant : 1. imprimer le message Je démarre 2. exécuter une instruction privilégiée 3. imprimer le message Je stoppe 4. terminer À l exécution, on doit voir le premier message mais pas le second car lors de l exécution de l instruction privilégiée, il doit se produire une exception, que le noyau pourra récupérer pour tuer le programme fautif. Cette gestion des exceptions n est pas obligatoire dans le cahier de charges de base du projet, et si elle n est pas implémentée, votre noyau plantera en cas d exception. Test de la protection de la mémoire et de l espace d E/S C est une variation du programme précédent : au lieu d exécuter une instruction privilégiée, le programme essaye d accéder à l espace d E/S, par exemple en tentant de modifier la position du curseur, ou à une zone mémoire protégée, par exemple la mémoire vidéo. Là aussi, le noyau pourra récupérer l exception et tuer le programme fautif. Test du passage de paramètres Ecrire un programme qui crée plusieurs processus en leur passant des paramètres différents. Les processus se contentent d imprimer les paramètres reçus et se terminent. 8 Phase 6 Cette partie consiste à implémenter une console. Les sorties sur écran étant normalement opérationnelles depuis la phase 1, il reste à coder un pilote de clavier. 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 au clavier et d implémenter les appels système cons read et cons write. Tout ce qui concerne la 7

8 reconnaissance des scancodes vous est fourni. Le travail qui vous est demandé concerne les mécanismes de base de gestion des E/S. 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. 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