Changes between Version 2 and Version 3 of MultiCourseTP7_QR

Timestamp:

Jun 9, 2020, 12:07:14 PM (4 years ago)

Author:

alain

Comment:

--

MultiCourseTP7_QR

@@ -8 +8 @@
 == Q2) Pourquoi l'interruption DMA est-elle débrayable par logiciel en utilisant le registre DMA_IRQ_ENABLE ? ==
 
-La plupart des périphériques sont conçus pour être utilisés par différents OS, qui peuvent avoir des politiques différentes pour détecter la fin d'une opération d'entrée/sortie. La technique des interruptions, est efficace quand l'OS supporte le fonctionnement multi-tâches sur un seul processeur, mais la technique de scrutait directe du registre status par l'OS peut être très efficace dans un contexte de sytème embarqué mono-tâche. C'est pourquoi le  coprocesseur DMA ne rend pas obligatoire l'interruption pour signaler la fin de transfert.
+La plupart des périphériques sont conçus pour être utilisés par différents OS, qui peuvent avoir des politiques différentes pour la signalisation de fin d'une opération d'entrée/sortie. La technique des interruptions, est efficace quand l'OS supporte le fonctionnement multi-tâches sur un seul processeur, mais la technique de scrutation directe du registre status par l'OS peut être très efficace dans un contexte de sytème embarqué mono-tâche. C'est pourquoi le  composant matériel DMA, comme les autres, ne rend pas obligatoire l'interruption pour signaler la fin de transfert.
 
 == Q3) Comment le coprocesseur DMA peut-il être partagé par plusieurs tâches dans une architecture multi-coeurs ? == 
@@ -14 +14 @@
 Toute ressource partagée doit être protégée en accès exclusif, comme c'est le cas pour le contrôleur IOC. Le coprocesseur DMA ne fait pas exception, etl doit donc être protégé par un verrou. SI on utilise un coprocesseur DMA multi-canaux, on peut associer un canal privé à chaque coeur. Mais si chaque coeur peut exécuter plusieurs applications (par multiplexage temporel et commutation de contexte), il faut un verrou par canal, pour garantir l'exclusivité entre les différentes applications s'exécutant sur le même coeur
 
-== Q4) Pourquoi dit-on que l'appel système fb_write() est non-bloquant, alors que cette fonction peut se bloquer pour attendre la fin d'un autre transfert déjà en cours ? ==
+== Q4) Pourquoi dit-on que l'appel système fb_write() est non-bloquant, alors que cette fonction peut se bloquer s'il faut attendre la fin d'un autre transfert déjà en cours ? ==
 
 Dire qu'une fonction est non-bloquante ne signifie pas qu'elle ne peut pas se bloquer. Cela signifie que la fonction peut rendre la main au programme appelant avant que  le travail demandé (c'est à dire la copie d'un buffet utilisateur source vers le frame bouffer destination) n'est pas encore réalisé. On peut faire la même réponse pour l'appel système ioc_write().