Context Navigation

Changes between Version 94 and Version 95 of SoclibCourseTp4

Timestamp:: Dec 11, 2013, 8:37:33 PM (11 years ago)
Author:: alain
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

SoclibCourseTp4

-                      v94
+                      v95
+.
 = 2. Architecture mono-processeur =
+= 2. Périphériques =
 Il existe deux types de périphériques:
 …
 Cet appel système contient une boucle de scrutation dans laquelle, à chaque tour de boucle,
 le processeur effectue une transaction sur le bus pour lire la valeur du registre STATUS du terminal TTY concerné.
 On ne sort de cette boucle que lorsqu'un caractère a effectivement été saisi au clavier.
+On ne sort de cette boucle que lorsque la valeur lue indique qu'un caractère a effectivement été saisi au clavier.
 Dans ce TP4, le programme utilisateur utilisera l'appel système '''tty_getc_irq()''' pour lire un caractère.
+Cet appel système utilise un tampon mémoire partagé '''_tty_get_buf''', protégé par une variable de synchronisation '''-tty_get_full'''.
+Ces deux variables appartiennent au système d'exploitation et sont stockées en mémoire dans le segment ''seg_kunc'', qui est à la fois protégé (non accessible par les programmes utilisateur) et non cachable.
+Plutôt que d'accéder directement au registre STATUS du contrôleur TTY, l'appel système '''tty_get_irq()'''
+teste la variable '''_tty_get_full''' rangée en mémoire. C'est la routine d'interruption (ISR) associée au terminal TTY qui se charge d'écrire le code ASCII du caractère dans le tampon  '''_tty_get_buf''', et de forcer à 1 la variable de synchronsation '''_tty_get_full''' pour signaler que le tampon est plein. Cette variable de synchronisation est remise à 0 par l'appel système ''tty_getc_irq()'' lorsque le caractère est transféré du tampon système '''tty_get_buf'''  vers le tampon mémoire défini par l'utilisateur.
+Le processeur peut exécuter plusieurs tâches (plusieurs programmes utilisateurs) en pseudo-paralléliseme, par multiplexage temporel.
+Chaque tâche possède alors son propre terminal écran/clavier, mais ces
+différents terminaux sont tous contrôlés par le même contrôleur TTY : Chaque terminal possède donc son propre jeu de 4 registres, pour communiquer avec l'OS.
+Le GIET supporte au plus 8 processeurs, et au plus 4 tâches par processeur. Le GIET supporte donc au plus 32 terminaux ecran/clavier, et définit donc deux tableaux '''_tty_get_buf[32]''' et '''_tty_get_full[32]''', indexés par le numéro du terminal concerné.
+'''Question''' : Comment les deux entités communicantes (l'ISR et l'appel système) calculent-elles l'index du terminal concerné ? La réponse se trouve dans les fichier '''drivers.c''' et '''isr.s'''.
+'''Question''' : Que fait la routine d'interruption ISR déclenchée par le périphérique TTY lorsqu'un caractère est frappé alors que  la variable '''_tty_get_full[i]''' vaut 1 ?   La réponse se trouve dans le fichier '''isr.s'''.
+Cet appel système utilise un tampon mémoire partagé '''_tty_get_buf''', protégé par une variable de synchronisation '''_tty_get_full'''.
+Ces deux variables appartiennent au système d'exploitation et sont stockées en mémoire dans le segment ''seg_kunc'', qui est à la fois protégé
+(non directement accessible par un programmes utilisateur) et non cachable.
+Plutôt que d'accéder directement au registre STATUS du contrôleur TTY, l'appel système '''tty_getc_irq()'''
+teste la variable '''_tty_get_full''' rangée en mémoire pour savoir si un caractère est disponible. C'est la routine d'interruption (ISR) associée au terminal TTY qui se charge d'écrire le code ASCII du caractère dans le tampon  '''_tty_get_buf''', et de forcer à 1 la variable de synchronsation '''_tty_get_full''' pour signaler que le tampon est plein. Cette variable de synchronisation est remise à 0 par l'appel système ''tty_getc_irq()'' lorsque le caractère est transféré du tampon système '''tty_get_buf'''  vers le tampon mémoire défini par l'utilisateur.
+Une architecture peut contenir plusieurs processeurs et chaque processeur peut exécuter plusieurs tâches (plusieurs programmes utilisateurs) en pseudo-paralléliseme, par multiplexage temporel. Le GIET supporte au plus 8 processeurs, et au plus 4 tâches par processeur. Le GIET supporte donc au plus 32 tâches.
+Comme chaque tâche possède son propre terminal écran/clavier, Il peut exister jusque 32 terminaux indépendants, qui sont tous
+contrôlés par le même contrôleur TTY : Chaque terminal possède donc son propre jeu de 4 registres, pour communiquer avec l'OS.
+On dit que le contrôleur TTY est un périohérique multi-canaux.
+Le GIET définit donc deux tableaux '''_tty_get_buf[32]''' et '''_tty_get_full[32]''', indexés par le numéro du terminal concerné.
+'''Question''' : Comment les appels système ''tty_getc_irq()'' et ''tty_pus()'' calculent-ils l'index du terminal associé à la tâche qui effectue l'appel système ? La réponse se trouve dans le fichier '''sys/drivers.c'''.
+'''Question''' : Comment le code de l'ISR associée à l'interruption générée par le TTY calcule-il l'index de l'entrée qui doit être modifiée dans les tableaux '''_tty_get_buf[32]''' et '''_tty_get_full[32] ? La réponse se trouve dans le fichier '''sys/irq_handler.c'''.
+'''Question''' : Que fait la routine d'interruption ISR déclenchée par le périphérique TTY lorsqu'un caractère est frappé au clavier et que  la variable '''_tty_get_full[i]''' vaut 1 (ce qui signifie que le tampon '''_tty_get_buf[i]''' est plein ?   La réponse se trouve dans le fichier '''sys/irq_handler.c'''.
 '''Question''' : Quel est l'avantage de ce type de communication par interruption, comparé au mécanisme de scrutation utilisé dans le TP3 ?
 …
 L'appel système '''ioc_completed()''', qui appelle lui-même la fonction système '''_ioc_completed()''' permet au programme utilisateur de se mettre en attente sur la fin d'un transfert. C'est donc une fonction bloquante qui ne rend la main au programme utilisateur que lorsque le transfert est effectivement terminé.
 '''Question''' : Le contrôleur de disque utilisé ici ne peut effectuer qu'un seul transfert de données à la fois.
+'''Question''' : Le contrôleur de disque utilisé ici ne peut effectuer qu'un seul transfert de données à la fois. Ce n'est donc pas un périphérique multi-canaux.
 Que se passe-t-il si un programme utilisateur A effectue un appel système '''_ioc_read()''' alors que le contrôleur de disque est déjà en train d'exécuter un transfert à la demande d'un autre programme utilisateur B?