Interruption et Signaux Linux
Fermé
maranello
Messages postés
1
Date d'inscription
samedi 3 mai 2008
Statut
Membre
Dernière intervention
3 mai 2008
-
3 mai 2008 à 13:37
kilian Messages postés 8731 Date d'inscription vendredi 19 septembre 2003 Statut Modérateur Dernière intervention 20 août 2016 - 7 mai 2008 à 17:24
kilian Messages postés 8731 Date d'inscription vendredi 19 septembre 2003 Statut Modérateur Dernière intervention 20 août 2016 - 7 mai 2008 à 17:24
A voir également:
- Interruption et Signaux Linux
- Linux mint - Télécharger - Systèmes d'exploitation
- Diskinternals linux reader - Télécharger - Stockage
- Linux live usb creator - Télécharger - Outils Internet
- Distribution linux - Guide
- Play on linux - Télécharger - Divers Utilitaires
3 réponses
kilian
Messages postés
8731
Date d'inscription
vendredi 19 septembre 2003
Statut
Modérateur
Dernière intervention
20 août 2016
1 527
3 mai 2008 à 15:53
3 mai 2008 à 15:53
Salut,
Il faudrait une dissertation complète pour te répondre.
Je peux peut être répondre à quelques trucs, vaguement.
2) Analogie et différences entre interruption et déroutement
...euh pour moi ce sont des synonymes. Aprèsd peut être que tu veux la différence entre softirq et hardirq.
Le premier c'est l'interruption logicielle, délenchée depuis un programme, l'autre c'est l'interruption matérielle, déclenchée...depuis le materiel :-)
Les softirq sont déclenchés par des appels système (autrement appelés syscalls) par exemple.
Et pour le coup il y a une grande différence de contexte entre syscalls et hardirq. Les syscalls s'éxécutent dans un contexte particulier, souvent un contexte utilisateur (la table des pages chargée est celle d'un programme spécifique) tandis qu'une hardirq n'est généralement pas chargée dans un contexte particulier, ou plutôt on n'en sait rien, donc on ne peut que faire confiance à la mémoire du noyau non paginée (non sauvegardée sur disque).
Le gros problème avec les hardirq c'est qu'ils ne sont pas considérés comme des processus. Ce qui implique qu'une hardirq ne peut pas faire certaines choses en particulier une chose: appeler la fonction schedule() qui planifie une tâche. On ne peut planifier une tâche que depuis une autre tâche (car il faut sauvegarder le contexte de l'ancienne tâche), or les interruptions ne sont pas des tâches.
Ne pas pouvoir appeler la fonction schedule() implique énormément de choses: on ne peux pas appeler d'autres fonctions qui appellent elles-mêmes schedule(). Et de ces fonctions il y en a beaucoup: les fonctions de sémaphores, certaines fonctions d'allocation de mémoire etc... D'ailleurs comme on ne peut utiliser les sémaphores, les conditions de concurrence au niveau interruption sont gérées par des spinlocks.
En bref une interruption doit s'executer de manière atomique au niveau de la préemption (par contre une interruption peut être déroutée par une autre interruption souvent).
Sous windows ces soucis de contextes et de tâches sont traduits avec la notion d'IRQL.
Bigre...c'est compliqué à expliquer... :-/
5) Déroulement d'une interruption
Le gestionnaire d'interruption reçoit une requête irq (activation d'une ligne irq) puis il décide ou pas de dérouter le processeur selon certains cas (interruptions masquées, priorités d'interruptions etc...). En cas de déroutement j'imagine que c'est selon le processeur. Mais je pense qu'on retrouve certaines actions constantes entre les différents processeurs:
* sauvegarde du compteur ordinal (le pointeur d'instruction du programme interrompu)
* sauvegarde du mot d'état du programme interrompu
* chargement du compteur ordinal avec l'adresse de la routine de traitement d'interruption
Selon les processeurs ça peut être complété par d'autres trucs.
Et pour finir je vous demande quelle est la différence ou le rapport entre les signaux unix (genre SIGALRM, ...) et es interruptions unix
L'interruption est un déroutement au niveau noyau, alors que les signaux (artifices gérés par le noyau Unix) sont des déroutements au niveau utilisateur. Mais c'est vrai que le comportement des deux est assez similaires.
Il faudrait une dissertation complète pour te répondre.
Je peux peut être répondre à quelques trucs, vaguement.
2) Analogie et différences entre interruption et déroutement
...euh pour moi ce sont des synonymes. Aprèsd peut être que tu veux la différence entre softirq et hardirq.
Le premier c'est l'interruption logicielle, délenchée depuis un programme, l'autre c'est l'interruption matérielle, déclenchée...depuis le materiel :-)
Les softirq sont déclenchés par des appels système (autrement appelés syscalls) par exemple.
Et pour le coup il y a une grande différence de contexte entre syscalls et hardirq. Les syscalls s'éxécutent dans un contexte particulier, souvent un contexte utilisateur (la table des pages chargée est celle d'un programme spécifique) tandis qu'une hardirq n'est généralement pas chargée dans un contexte particulier, ou plutôt on n'en sait rien, donc on ne peut que faire confiance à la mémoire du noyau non paginée (non sauvegardée sur disque).
Le gros problème avec les hardirq c'est qu'ils ne sont pas considérés comme des processus. Ce qui implique qu'une hardirq ne peut pas faire certaines choses en particulier une chose: appeler la fonction schedule() qui planifie une tâche. On ne peut planifier une tâche que depuis une autre tâche (car il faut sauvegarder le contexte de l'ancienne tâche), or les interruptions ne sont pas des tâches.
Ne pas pouvoir appeler la fonction schedule() implique énormément de choses: on ne peux pas appeler d'autres fonctions qui appellent elles-mêmes schedule(). Et de ces fonctions il y en a beaucoup: les fonctions de sémaphores, certaines fonctions d'allocation de mémoire etc... D'ailleurs comme on ne peut utiliser les sémaphores, les conditions de concurrence au niveau interruption sont gérées par des spinlocks.
En bref une interruption doit s'executer de manière atomique au niveau de la préemption (par contre une interruption peut être déroutée par une autre interruption souvent).
Sous windows ces soucis de contextes et de tâches sont traduits avec la notion d'IRQL.
Bigre...c'est compliqué à expliquer... :-/
5) Déroulement d'une interruption
Le gestionnaire d'interruption reçoit une requête irq (activation d'une ligne irq) puis il décide ou pas de dérouter le processeur selon certains cas (interruptions masquées, priorités d'interruptions etc...). En cas de déroutement j'imagine que c'est selon le processeur. Mais je pense qu'on retrouve certaines actions constantes entre les différents processeurs:
* sauvegarde du compteur ordinal (le pointeur d'instruction du programme interrompu)
* sauvegarde du mot d'état du programme interrompu
* chargement du compteur ordinal avec l'adresse de la routine de traitement d'interruption
Selon les processeurs ça peut être complété par d'autres trucs.
Et pour finir je vous demande quelle est la différence ou le rapport entre les signaux unix (genre SIGALRM, ...) et es interruptions unix
L'interruption est un déroutement au niveau noyau, alors que les signaux (artifices gérés par le noyau Unix) sont des déroutements au niveau utilisateur. Mais c'est vrai que le comportement des deux est assez similaires.
kilian
Messages postés
8731
Date d'inscription
vendredi 19 septembre 2003
Statut
Modérateur
Dernière intervention
20 août 2016
1 527
6 mai 2008 à 19:53
6 mai 2008 à 19:53
bon courage et merci à celui qui nous répondra.
Youhouuuu! Ya déjà une réponse depuis trois jours!
http://www.commentcamarche.net/forum/affich 6233378 interruption et signaux linux#1
Et puis zut débrouillez vous, entre celui qui poste une question et ne revient jamais (alors que certains se démènent pendant plus d'un quart d'heure pour leur fournir une réponse) et celui qui ne voit pas la réponse un message au dessus de lui....
Sachez que si vous posez une question à une personne qui vous parait virtuelle (vu que c'est un forum), les efforts fournis par cette personne ne sont pas virtuels eux!!
Bon courage à vous, pour ma part je lache cette discussion.
Youhouuuu! Ya déjà une réponse depuis trois jours!
http://www.commentcamarche.net/forum/affich 6233378 interruption et signaux linux#1
Et puis zut débrouillez vous, entre celui qui poste une question et ne revient jamais (alors que certains se démènent pendant plus d'un quart d'heure pour leur fournir une réponse) et celui qui ne voit pas la réponse un message au dessus de lui....
Sachez que si vous posez une question à une personne qui vous parait virtuelle (vu que c'est un forum), les efforts fournis par cette personne ne sont pas virtuels eux!!
Bon courage à vous, pour ma part je lache cette discussion.
kilian
Messages postés
8731
Date d'inscription
vendredi 19 septembre 2003
Statut
Modérateur
Dernière intervention
20 août 2016
1 527
>
auris
7 mai 2008 à 17:24
7 mai 2008 à 17:24
Bon allez ya pas de soucis.
Merci ;-)
Merci ;-)
