Projet système PC : 2017 - Nolwenn Forey, Benjamin Khenniche

De Ensiwiki
Aller à : navigation, rechercher
Dorit'OS
Dorit'OS.png
Projet Système d'Exploitation 2017

Développeurs FOREY Nolwenn
KHENNICHE Benjamin

Présentation

Introduction

Le but du projet système est de réaliser un OS par équipe de deux ou trois. Notre OS devra, entre autre, gérer les divers processus et faire en sorte qu'ils se passe la mains dans un ordre FIFO prenant en compte les priorités. Il devra également permettre aux processus de s'échanger des messages et isoler la zone mémoire kernel de la zone mémoire user.

Gestion de projet

Plannings

Planning prévisionnel

Nous n'avons pas vraiment fait de planning prévisionnel. Nous avons simplement considéré que le plus important pour nous était d'arriver à faire la phase 5 au maximum. En effet, la phase 5 étant la plus compliquée, c'était également la plus importante pour nous. Nous voulions également être sur que tous ce que nous avions codé avant la phase 5 était fonctionnel avant de commencer cette dernière. Ainsi, il nous fallait impérativement réussir à passer les tests fournis concernant les phase 1 à 4 avant de pouvoir aller plus loin.

Planning effectif

Gantt projet systeme BK-NF.png

Journal de bord

Jeudi 08 juin

  • Phase 1 : Done
  • Debut phase 2

Vendredi 09 juin

Matin

Phase 2

  • Changement de contexte

Après-Midi

Phase 2

  • Timer et interruption (Nolwenn)

Phase 3

  • Ordonnancement, début de la prise en compte des priorités.
  • Fonction start implémenté en partie

Lundi 12 Juin

Phase 3

  • Endormissement (Nolwenn)
  • Terminaison (Benjamin)
  • Attente du fils (Benjamin)
  • Ordonnancement (Benjamin, Nolwenn)

Mardi 13 Juin

Matin

Phase 3

  • Kill (Nolwenn)
  • Return les codes de process mort (Benj)

Après-midi

  • Test wait_clock (Nolwenn)
  • Passer la pile en alloc dynamic (Benj) -> Rollback
  • File de message commencé (Benj)

Mercredi 14 juin

Matin

  • File de message
  • Preset (Benj)
  • Psend (Nol)
  • Debug gestion des priorités (Nol)
  • Test priority (Nol)

Après-midi

  • Chprio (Nol)
  • Passer la pile en alloc dynamic (Benj)
  • Modifier push_process pour prendre en compte les priorités (Nol)
  • Add test (Benj)
  • Preceive (Nol)

Jeudi 15 Juin

Matin

  • Test et debbuging (Nol & Benj)
  • Faire pcount (Benj)

Après-midi

  • Test et debbuging (Benj)
  • Modifier kill pour qu’il retire le process de la file de message dans laquelle il attend (Nol)
  • Qreset : désallouer les personnes dans la file (Nol)
  • Modifier chprio pour prendre en compte les files de messages (Nol)

Vendredi 16 Juin

Matin

  • Modif réveille des processus bloqués dans une file de message (Nol)
  • Debbuging (Nol & Benj)

Après-midi

  • FIX error clock to fast (Nol)
  • Debbuging (Nol & Benj)

Lundi 19 juin

  • Debbuging (Nol & Benj)

Mardi 20 juin

Phase 5:

  • Création de la gestion des interruptions servant aux appelles systèmes
  • Passage du mode kernel au mode user

Mercredi 21 juin

Phase 5

  • Débuggage du passage au mode user
  • Tentative de passage du mode user au mode kernel par interruption 49

+ Préparation de plusieurs appels système

Jeudi 22 juin

  • Passage du mode user au mode kernel \o/
  • Syscalls implémenté

Vendredi 23 juin

Phase 5

  • Debugging (Nol & Benj)
  • Catch des erreurs 0E et 0D (Benj)

Phase 6

Lundi 26 juin

Phase 6

Phase 7

Extensions

Mardi 27 juin

Extensions

Détails du projet

Phase 1

La phase 1 consiste principalement à prendre en main l'environnement. Cependant, afin de pouvoir debugger plus facilement, nous avons également profiter de la phase 1 pour implémenter le printf.


Réalisation :

100 %

Phase 2

Dans la phase 2 nous avons dû gérer le changement de contexte ainsi que les interruptions liées à un timer. En raison d'une mauvaise compréhension du sujet, la gestion des interruptions en phase 2 a été bien plus poussé que ce qui nous était demandé. Ainsi, nous avons implémenté le wait_clock tel qui nous était demandé en phase 4.


Réalisation :

100 %

Phase 3

En phase 3 nous avons dû gérer l’ordonnancement, l'endormissement et la terminaison des processus (mort, renvoie d'une valeur de retour au père, etc...).


Réalisation :

100 %

Phase 4

En phase 4 nous avons dû ajouter les files de messages. Durant cette phase, nous avons eux beaucoup de mal à comprendre qu'elle était le comportement attendu par les spécifications. Au final, notre implémentation ne correspond sans doute pas parfaitement au spécification (et ce, malgré le fait que nous passons tous les tests fournis).

Dans cette phase, nous avons décidé que les processus en attente de lecture ou d'écriture passaient directement de l'état "Bloqué" à l'état "Actif". Cela permet à un processus de haute priorité de doubler un processus qui pouvait lire mais ne l'avait pas encore fait. À la lecture des test et des spécifications cela nous semblait correspondre à ce qui était attendu. Cependant, nous sommes conscient.e.s qu'il ne s'agit pas de la seule implémentation possible et que la notre ne correspond peut-être pas à ce qui été attendu par les professeurs.


Réalisation :

100 %

Phase 5

La phase 5 consiste à séparer le mode kernel du mode user. Il faut donc protéger le code kernel pour qu'il ne soit pas accessible à l'utilisateur puis il faut réussir à passer du mode kernel au mode user et inversement.

Pour réussir la phase 5 il faut d'abord bien comprendre les interactions qu'il y a entre le mode kernel et le mode user. Le plus difficile est ensuite de trouver quelle valeur il faut mettre dans quelle case mémoire pour que tout fonctionne.


Réalisation :

100 %

Phase 6

La phase 6 consiste à implémenter un pilote de clavier. Il faut donc que notre OS soit capable de lire des entrées claviers et d'afficher des sorties. Comme nous avions eu besoin d'afficher des sorties pour les tests précédents, il ne nous restait plus qu'à gérer la lecture des entrées.


Réalisation :

100 %

Phase 7

La phase 7 consiste à réaliser un interprète de commandes. Afin de pouvoir appeler des commandes prenant des arguments, nous avons implémenté la fonction atoi qui transforme un nombre entrée par un utilisateur en int.


Réalisation :

100 %

Extension

Pour la phase d'extension, nous avons opté pour créer plusieurs petites fonctionnalités.

  • Nous avons fait en sorte de récupérer les erreurs 0x0D (protection fault) et 0x0E (segmentation fault). Ainsi, lorsque ces erreurs surviennent, le processus les ayant levées est kill mais le processus parent ET LE NOYAU peut continuer à s’exécuter.
  • Une fonction atoi() est ajouté pour permettre de lire des nombre entré par l'utilisateur !
  • La combinaison Ctrl+C permet de tuer le dernier processus créé.
  • La combinaison Ctrl+L permet de nettoyer l'écran du shell.
  • La commande "doritos" permet de faire s'afficher un petit easter eggs.
  • La commande "test <n>" permet delancer le test <n>, si vous écrivez juste "test" ou "test 0", alors tous les tests seront lancés.
  • La commande "help" affiche la liste des commandes
  • La commande "random" permet de tirer au sort un nombre entre 1 et 10 (inclus). Il est possible de passer deux arguments à la commande "random" pour spécifier entre quels valeurs on souhaite tirer le nombre.

Sources

Voici une liste des documents qui nous ont été utiles pendant le projet. Notamment pour la phase 5: