Projet système PC : 2020 : SAURET-BOURIN Hildéric, DELMAS Morgane : Différence entre versions

De Ensiwiki
Aller à : navigation, rechercher
 
Ligne 1 : Ligne 1 :
 
{{Projet Étudiant
 
{{Projet Étudiant
 
  |cadre=Projet système
 
  |cadre=Projet système
−
  |titre=Projet système PC : 2020 - SAURET-BOURIN Hildéric, DELMAS Morgane
+
  |titre=JaackOS
 
  |equipe=[mailto:hilderic.sauret--bourin@grenoble-inp.org Hildéric SAURET-BOURIN], [mailto:morgane.delmas@grenoble-inp.org Morgane DELMAS]
 
  |equipe=[mailto:hilderic.sauret--bourin@grenoble-inp.org Hildéric SAURET-BOURIN], [mailto:morgane.delmas@grenoble-inp.org Morgane DELMAS]
 
  |encadrants=[mailto:yves.denneulin@univ-grenoble-alpes.fr Yves Denneulin ], [mailto:Gregory.Mounie@imag.fr Gregory Mounie], [mailto:Patrick.Reignier@imag.fr Patrick Reignier ]
 
  |encadrants=[mailto:yves.denneulin@univ-grenoble-alpes.fr Yves Denneulin ], [mailto:Gregory.Mounie@imag.fr Gregory Mounie], [mailto:Patrick.Reignier@imag.fr Patrick Reignier ]
Ligne 15 : Ligne 15 :
 
Travail en pair programming 90% du temps. La qualité du code était critique lors de ce projet, une simple erreur était couteuse en temps.
 
Travail en pair programming 90% du temps. La qualité du code était critique lors de ce projet, une simple erreur était couteuse en temps.
 
De plus les fonctionnalités étaient très dépendantes; séparer notre force de travail ne nous a pas semblé cohérent.
 
De plus les fonctionnalités étaient très dépendantes; séparer notre force de travail ne nous a pas semblé cohérent.
−
 
  
 
==Phases de développement==
 
==Phases de développement==
Ligne 29 : Ligne 28 :
 
A la fin de la semaine nous sommes arrivés au test 13. (sans le 11 qui est sur les mutex).
 
A la fin de la semaine nous sommes arrivés au test 13. (sans le 11 qui est sur les mutex).
  
 +
'''3è semaine :'''
 +
Finalisation de la partie kernel jusqu'au test 20.
 +
Analyse de la partie user, mais la tâche était trop importante en vue de la deadline.
 +
Notre attention a donc été porté sur la qualité du rendu de ce que nous avions.
 +
La majeur partie de notre temps a été dédié cette semaine aux files de messages.
  
 
=== Phase 1 : prise en main de l'environnement ===
 
=== Phase 1 : prise en main de l'environnement ===
Ligne 53 : Ligne 57 :
  
 
=== Tests Kernel ===
 
=== Tests Kernel ===
−
{{Avancement | 90}}
+
{{Avancement | 100}}
  
 
=== Tests User ===
 
=== Tests User ===
Ligne 112 : Ligne 116 :
  
 
====23 Juin 2020====
 
====23 Juin 2020====
−
* Passage des tests sur les files de message
+
* Passage des quelques tests sur les files de message
 
* Nettoyage et factorisation du code
 
* Nettoyage et factorisation du code
  
 +
====24 Juin 2020====
 +
* Analyse de la partie user
 +
 +
====25 Juin 2020====
 +
* Abandon de la partie user par manque de temps
 +
* Fix des file de messages, test 20 OK
 +
 +
====26 Juin 2020====
 +
* Verification du rendu
  
 
==Difficultés rencontrées==
 
==Difficultés rencontrées==
Ligne 123 : Ligne 136 :
 
'''Problème de mem_alloc imbriqué'''
 
'''Problème de mem_alloc imbriqué'''
 
Le problème qui nous a certainement le plus couté en temps, plusieurs jours de debug.
 
Le problème qui nous a certainement le plus couté en temps, plusieurs jours de debug.
−
Dans un processus, il nous était impossible de faire 3 start de processus avec un taille supérieur a 5000 ET égale, alors qu'aucun des 3 fils n'avait encore commencé son exécution. Même si nous avons continué à chercher une solution à ce bug, nous avons mis en place un fix temporaire, en pré-allouant les piles des le début de notre kernel, afin de pouvoir avancer sur les autres fonctionnalités demandées.
+
Dans un processus, il nous était impossible de faire 3 start de processus avec un taille supérieur a 5000 ET égale, alors qu'aucun des 3 fils n'avait encore commencé son exécution. Même si nous avons continué à chercher une solution à ce bug, nous avons mis en place un fix en pré-allouant les piles des le début de notre kernel, afin de pouvoir avancer sur les autres fonctionnalités demandées.
  
 
'''Mauvaise compréhension des spécifications des files de message'''
 
'''Mauvaise compréhension des spécifications des files de message'''

Version actuelle en date du 25 juin 2020 à 15:29

Titre du projet JaackOS
Cadre Projet système

Équipe Hildéric SAURET-BOURIN, Morgane DELMAS
Encadrants Yves Denneulin , Gregory Mounie, Patrick Reignier


Présentation

Création d'un système d'exploitation pour un x86.


Organisation

Travail en pair programming 90% du temps. La qualité du code était critique lors de ce projet, une simple erreur était couteuse en temps. De plus les fonctionnalités étaient très dépendantes; séparer notre force de travail ne nous a pas semblé cohérent.

Phases de développement

1è semaine : Travail de compréhension et de lecture de documentation. On a repris: les bases des cours de système d'exploitation, nos cours de logiciel de base pour le x86, repris le TP sur le timer, ... Pendant cette analyse, nous avons remarqué qu'une des étapes critiques et complexe de ce projet était le context switch. Nous avons donc directement commencé par ca, pour écarter ce point critique au plus tôt.

2è semaine : Nous avons orienté le développement vers les primitives demandés : start, waitpid, ... Et ceci en faisant du Test Driven Development, dès qu'un des test était OK, nous passions au test suivant. A la fin de la semaine nous sommes arrivés au test 13. (sans le 11 qui est sur les mutex).

3è semaine : Finalisation de la partie kernel jusqu'au test 20. Analyse de la partie user, mais la tâche était trop importante en vue de la deadline. Notre attention a donc été porté sur la qualité du rendu de ce que nous avions. La majeur partie de notre temps a été dédié cette semaine aux files de messages.

Phase 1 : prise en main de l'environnement

100 %

Phase 2 : Création et lancement de processus de niveau noyau

100 %

Phase 3 : Ordonnancement, création dynamique et terminaison de processus de niveau noyau

100 %

Phase 4 : Gestion des communications et synchronisation de processus de niveau noyau

100 %

Phase 5 : Séparation des espaces mémoire noyau et utilisateur : gestion de processus utilisateur

0 %

Phase 6 : Gestion du clavier et implémentation d'un pilote de console

0 %

Phase 7 : Implémentation d'un interprète de commandes

0 %


Tests Kernel

100 %

Tests User

0 %


Journal de bord

Semaine 1

07 Juin 2020

  • Analyse de la roadmap et des spécifications

08 Juin 2020

  • Mise en place de l'environnement de dev.
  • Setup de VScode avec GDB

09 Juin 2020

  • Reprise TP ecran pour avoir console_putbytes
  • Première utilisation de ctx_swt

10 Juin 2020

  • Travail sur ctx_swt
  • Debug de mem_alloc

11 Juin 2020

  • Debug de mem_alloc, prb : no-pie
  • Reprise tu TP avec le timer pour revoir les interruptions et avoir un horloge

12 Juin 2020

  • Mise en place de l'ordonnanceur.
  • ctx_swt effectué en fn de la priorité des processus


Semaine 2

15 Juin 2020

  • Mise en place de sleeping processus

16 Juin 2020

  • Ecriture des primitives de gestion des processus : wait, kill, chrpio, ...

17 Juin 2020

  • Bugfix + fix mem_alloc with preallocated stack

18 Juin 2020

  • File de message : pcreate, precive, psend

19 Juin 2020

  • File de message : Bugfix


Semaine 3

22 Juin 2020

  • Ecriture wiki
  • File de message : pcount , pdelete, preset
  • Gestion du kill et du chprio pour les processus dans des files de message

23 Juin 2020

  • Passage des quelques tests sur les files de message
  • Nettoyage et factorisation du code

24 Juin 2020

  • Analyse de la partie user

25 Juin 2020

  • Abandon de la partie user par manque de temps
  • Fix des file de messages, test 20 OK

26 Juin 2020

  • Verification du rendu

Difficultés rencontrées

Oubli de configuration du makefile Comprendre que le dysfonctionnement du mem_alloc venait du manque de l'option --nopie dans le Makefile nous a pris un certains moment. Nous avons d'ailleurs pensé un moment que cela venait du fait que nous travaillions sur un Linux live USB. Ce qui n'était pas le cas

Problème de mem_alloc imbriqué Le problème qui nous a certainement le plus couté en temps, plusieurs jours de debug. Dans un processus, il nous était impossible de faire 3 start de processus avec un taille supérieur a 5000 ET égale, alors qu'aucun des 3 fils n'avait encore commencé son exécution. Même si nous avons continué à chercher une solution à ce bug, nous avons mis en place un fix en pré-allouant les piles des le début de notre kernel, afin de pouvoir avancer sur les autres fonctionnalités demandées.

Mauvaise compréhension des spécifications des files de message Nous n'avons pas tout de suite compris l'ordre attendu dans la lecture et l'écriture des files de messages. Nous avons donc perdu du temps à essayer de comprendre ce que les tests faisaient et les résulats attendus.

Ressources

Récupérée de « https://ensiwiki.ensimag.fr/index.php?title=Projet_système_PC_:_2020_:_SAURET-BOURIN_Hildéric,_DELMAS_Morgane&oldid=72523 »