Changes between Version 5 and Version 6 of MultiCourseTP10_QR

Timestamp:

Jun 10, 2020, 8:50:29 PM (4 years ago)

Author:

alain

Comment:

--

MultiCourseTP10_QR

@@ -28 +28 @@
 Dans un OS généraliste de type UNIX, ce n'est évidemment pas le code de boot qui lance les applications. Le scénario général est approximativement le suivant:
 * le code de boot (boot-loader) initialise au moins deux périphériques (TTY et IOC) et charge en mémoire le code du système d'exploitation. Le code binaire de l'OS est dans un fichier ''kernel.elf'' stocké sur disque. Puis le boot-loader se branche à la fonction kernel_init() de l'OS qui va initialiser les structures de données du kernel.
-* la fonction kernel_init() de l'OS initialise tous les périphériques disponibles dans l'architecture, initialise le système de fichiers (cache des fichiers), et crée un premier processus applicatif appelé ''init'' et lance l'exécution de ce processus. Le code binaire de cette première "application" est un fichier  ''init.elf'' stocké sur disque. 
-* Le process ''init'' utilise les appels système fork() rt exec() pour créer un ou plusieurs processus ''shell'', qui sont des processus inter-actifs permettant à l'utilisateur de demander à l'OS d'exécuter certaines commandes. Le code binaire du ''shell'' est un fichier  ''init.elf'' stocké sur disque. 
-* A travers le ''shell'', l'utilisateur peut demander à l'OS de lancer de façon interactive une ou plusieurs applications. Le code de chacune de ces applications doit être stocké dans un fichier ''appli.elf'' stocké sur disque. le processus ''shell'' utilise les appels système ''fork()'' & ''exec()'' le processus pour créer et lancer le processus applicatif appli.
-* Finalement, si le processus applicatif est un processus multi-threads, c'est l'exécution du thread ''main'' associé à chaque processus qui va créer les autres threads en utilisant l'appel système ''pthread_create()''. 
+* la fonction kernel_init() de l'OS initialise tous les périphériques disponibles dans l'architecture, initialise le système de fichiers (cache des fichiers), et crée un premier processus applicatif appelé ''init'', puis lance l'exécution de ce processus. Le code binaire de cette première "application" est un fichier  ''init.elf'' stocké sur disque. 
+* Le process ''init'' utilise les appels système fork() et exec() pour créer un ou plusieurs processus ''shell'', qui sont des processus inter-actifs permettant à l'utilisateur de demander à l'OS d'exécuter certaines commandes. Le code binaire de l'application ''shell'' est un fichier  ''init.elf'' stocké sur disque. 
+* A travers le ''shell'', l'utilisateur peut demander à l'OS de lancer de façon interactive une ou plusieurs applications. Le code de chacune de ces applications doit être stocké dans un fichier ''appli.elf'' stocké sur disque. le processus ''shell'' utilise les appels système ''fork()'' & ''exec()''  pour créer et lancer le processus applicatif ''appli''.
+* Finalement, si le processus applicatif est un processus multi-threads, c'est l'exécution du thread ''main'' associé à chaque processus applicatif qui va créer les autres threads en utilisant l'appel système ''pthread_create()''. 
 
 == Q5) Le GIET, comme la plupart des OS multi-tâches, permet qu'un changement de contexte se produise sur un coeur, alors que ce coeur est en train d'exécuter du code système (suite à un ''syscall''). Pourquoi les appels systèmes sont-il interruptibles ? ==
+
+Il existe moins deux raisons: La première est que certains appels système peuvent avoir des durées d'exécution très longues, alors que certaines requêtes d'interruption exigent des réactions rapides. La seconde raison est que dans un OS supportant des changements de contexte présomptifs, il est préférable que les interruptions TICK qui déclenchent les changements de contexte ne soient pas masquées, au risque de biaiser le partage de la ressource processeur entre les différentes tâches.
+
+Dans la plupart des OS, l'OS définit, de façon spécifique pour chaque appel système quand cet appel système est interruptible.