Discussion :

[PyNub]

Bonsoir,

Alors si je comprends bien lors d'un appel system:
1. les arguments de l'appel sont placés sur la pile
2. le code de l'appel système est placé dans un registre (lequel ?)
3. le processus fait un TRAP

C'est là que je bloque : Comment se réalise du point de vue de la machine le TRAP ? Surement par une interuption dans ce cas laquelle ? Faut-il en conclure que ce sont les processus qui choisissent le moment de rendre la main au noyau ?

Serait il possible de voir le code source d'un TRAP ?(l'assembleur ne me fait pas peur)
J'ajoute que j'ai déjà regardé dans le code source du noyau Linux mais je ne sais pas trop où il faut chercher, donc s'il vous plait ne me renvoyer pas à son étude, c'est prévu mais chaque chose en sontemps.

Merci pour votre aide.

[6-MarViN]

J'ai trouvé de la doc qui pourrait t'interesser mais c'est en anglais. En gros il y a deux façon principales de gérer les appels systèmes sur un système linux : le int 80 et le sysenter.

voila les liens :
Doc sysenter
Doc génrérale

[PyNub]

Merci pour la doc !

J'ai un peu avancé sur la question de l'arrêt et de la suspension des processus.

En effet un processus peut s'arrêter de lui même, avec un exit(), c'est un arret et non une suspension cependant... Dans un système d'exploitation c'est l'ordonnanceur qui est en charge de la distribution des ressources UC aux différent processus. Chaque processus se voit attribuer un quantum et il y a différentes manières de calculer ce quantum (je ne connais pas encore la façon dont ce quantum est calculé dans un système Linux). Ce ne répond toujours pas à ma question comment l'ordonnanceur reprend la main ? Apparemment l'ordonnanceur est commandé par les tops d'horloge mais j'ai du mal à comprendre comment cela se passe au niveau de la machine...

De plus sur les ordinateurs modernes les processus passent le plus clair de leur temps a attendre des E/S (Lecture disque dur, Saisie ou clic de l'utilisateur) ce qui laisse autant de temps au noyau pour rerendre la main. Puisque : demande d'E/S => appel système => processus bloqué le temps de la lecture E/S.

Voilà pour la suspension, mais bon c'est pas encore très clair pour moi...

Le int80 me parle un peu... je crois que sous DOS un appelle système se fait de la même manière : code de la fonction dans un registre (je ne sais pas lequel, vos lumières sont bienvenues...) puis apelle de l'interuption 80.

quant à sysenter je ne le conaissais pas je vais voir la doc que tu m'as indiquée.

[Obsidian]

Bonjour,

« TRAP » est un terme assez générique très répandu en informatique et qui couvre une large palette de cas de figure. TRAP signifie « piège » en anglais. Il s'agit en fait de préempter le cours normal de l'exécution d'un programme, sur une condition donnée, et en général à l'initiative d'un composant extérieur.

Ce sont donc des « trap conditions » mais on parle aussi de « trap representations » pour parler de valeurs interdites (dans les pointeurs de certains processeurs dont la plage d'adressage n'est pas continue, par exemple) propres à déclencher un tel comportement.

Sous UNIX, il existe SIGTRAP, qui est utilisé par les outils de déboguage lorsqu'un programme atteint un breakpoint.

Dire que le processus « fait un TRAP » pour effectuer un appel système est donc en soi un abus de langage. En plus, n'importe quelle méthode pourrait être employée pour y parvenir. Cela dit, il utilise quand même très souvent soit une interruption logicielle donnée, soit une condition similaire provoquant une trap condition pour arriver à ses fins parce que ça permet de faire tout ce qui suit en une seule fois :

— Garantir une taille limitée pour les appels, ce qui est d'autant plus souhaitable qu'ils sont nombreux : une interruption logicielle tient en général en deux octets quand un CALL ordinaire peut atteindre dix octets sur une machine 64 bits ;
— Passer automatiquement en mode privilégié ;
— Sauvegarder automatiquement l'état de la machine (par la machine, on entend l'unité centrale, c'est-à-dire le CPU, ce qui revient en fait à empiler automatiquement tous les registres) ;
— S'affranchir complètement de la notion d'emplacement en mémoire. Ce serait très pénible aujourd'hui si tous les points d'entrée système devaient avoir une position fixe ;
— Restaurer l'état initial encore plus simplement qu'on est entré en mode noyau.

Pour répondre à ton autre question, la méthode la plus naturelle est effectivement de charger un registre avec le code de l'appel à effectuer mais, là encore, il n'y a rien d'obligatoire. La plupart du temps, c'est EAX (ou ce qui en tient lieu), tout simplement.

[PyNub]

OK TRAP est plus un concept qu'une procédure a proprement dite...
Je relis ton post a tête reposée ce soir et je pense avoir pas mal de question a poser.

Grand Merci...

[PyNub]

Il s'agit en fait de préempter le cours normal de l'exécution d'un programme, sur une condition donnée, et en général à l'initiative d'un composant extérieur.

Un composant extérieur genre la fin d'une lecture sur disque dur par exemple ?

Sous UNIX, il existe SIGTRAP, qui est utilisé par les outils de déboguage lorsqu'un programme atteint un breakpoint.

Que fait SIGTRAP exactement ?

Cela dit, il utilise quand même très souvent soit une interruption logicielle donnée, soit une condition similaire provoquant une trap condition

Ok ça c'est quand le processus décide de faire un appel système.
Mais que ce passe-t-il quand le SE décide qu'un processus a eu assez de temps processeur et décide de passer a un autre ? Ce qui m'interroge surtout c'est comment le SE reprends la main pour exécuter l'ordonnanceur de processus une fois qu'un processus est en train de s'exécuter ? J'ai du mal a voir comment le système passe de l'exécution d'un programme à l'exécution du SE. Le fait que le SE reprenne la main seulement au moment d'un appel système ou au moment d'une interuption matérielle me semble trop soumis au aléas des activités des processus et du matériel...

— Garantir une taille limitée pour les appels, ce qui est d'autant plus souhaitable qu'ils sont nombreux : une interruption logicielle tient en général en deux octets quand un CALL ordinaire peut atteindre dix octets sur une machine 64 bits ;

Oui et puis pour faire un CALL le processus doit savoir quoi appeler or il n'est pas censé savoir où se trouve l'appel système puisque celui-ci fait parti du système d'exploitation...

— Passer automatiquement en mode privilégié ;

— Sauvegarder automatiquement l'état de la machine (par la machine, on entend l'unité centrale, c'est-à-dire le CPU, ce qui revient en fait à empiler automatiquement tous les registres) ;

C'est exactement là que je bloque... Le fait de devoir sauvegarder le contexte à chaque fois que le proc passe du mode noyau au mode utilisateur doit être couteux en terme de ressources. Pourtant l'ordonnanceur a besoin de s'exécuter à intervalles réguliers, sur quel rythmes et selon quelles modalités ce basculement se fait ? le passage noyau se fait-il selon des interuptions d'horloge quand aucun appel système n'est demandé par le processus en cours d'exécution ou qu'aucune interuption matérielle ne se produit ? Bien que çela soit difficile a imaginer sur un ordinateur moderne...

Pour répondre à ton autre question, la méthode la plus naturelle est effectivement de charger un registre avec le code de l'appel à effectuer mais, là encore, il n'y a rien d'obligatoire. La plupart du temps, c'est EAX (ou ce qui en tient lieu), tout simplement.

ok...


Merci

[Obsidian]

Un composant extérieur genre la fin d'une lecture sur disque dur par exemple ?

Non, je pensais plutôt à un dispositif de surveillance. Soit, c'est le système d'exploitation qui refuse d'honorer certains appels, soit c'est le micro-processeur qui déclenche une exception en cas d'instruction illégale ou de segfault.

Que fait SIGTRAP exactement ?

http://en.wikipedia.org/wiki/SIGTRAP

Utilisé principalement dans le cadre d'un déboguage, où on force l'interruption d'un programme même dans des conditions normales parce que le développeur a explicitement posé un point d'arrêt à cet endroit. Ça permet surtout au programme de savoir pourquoi il a été interrompu, ce qui peut parfois s'avérer nécessaire.

Le terme TRAP se justifie dans le cadre de la préemption dont on a parlé et parce que certains micro-processeurs proposent des registres dédiés au déboguage, déclenchant automatiquement une exception lorsque le pointeur de programme atteint une adresse donnée.

Ok ça c'est quand le processus décide de faire un appel système.
Mais que ce passe-t-il quand le SE décide qu'un processus a eu assez de temps processeur et décide de passer a un autre ? Ce qui m'interroge surtout c'est comment le SE reprends la main pour exécuter l'ordonnanceur de processus une fois qu'un processus est en train de s'exécuter ? J'ai du mal a voir comment le système passe de l'exécution d'un programme à l'exécution du SE.

Le système d'exploitation utilise un timer matériel qui déclenche une IRQ à intervalles réguliers. De là, c'est le système qui décide de ce qu'il veut faire. Il peut ou non donner la main à un autre processus, mais en profiter pour faire d'autres tâches, également.

Le fait que le SE reprenne la main seulement au moment d'un appel système ou au moment d'une interuption matérielle me semble trop soumis au aléas des activités des processus et du matériel...

C'est-à-dire que, d'une part, il faut se rendre compte des cadences auxquelles fonctionne un ordinateur : aujourd'hui, un timer milliseconde reste un million de fois (!) plus lent que la cadence d'un processeur à n GHz. Mais calculer le juste milieu d'un tel système a toujours été un sujet d'étude. Il y a trente ans, les ordinateurs fonctionnaient entre 1 et 8 Mhz en moyenne (mille fois moins vite) et ils étaient quand même très utiles.

D'autre part, la majorité des processus d'un système passe généralement son temps en sommeil : lorsqu'un programme demande à l'utilisateur de saisir une touche, par exemple, il demande au système à lire l'entrée standard. La main est alors passée au système d'exploitation, qui peut alors en profiter pour la passer directement à un autre processus et ne la lui rendre que lorsque des données seront effectivement arrivées dans la pile.

C'est exactement là que je bloque... Le fait de devoir sauvegarder le contexte à chaque fois que le proc passe du mode noyau au mode utilisateur doit être couteux en terme de ressources. Pourtant l'ordonnanceur a besoin de s'exécuter à intervalles réguliers, sur quel rythmes et selon quelles modalités ce basculement se fait ? le passage noyau se fait-il selon des interuptions d'horloge quand aucun appel système n'est demandé par le processus en cours d'exécution ou qu'aucune interuption matérielle ne se produit ? Bien que çela soit difficile a imaginer sur un ordinateur moderne...

Encore une fois, quand on dit « sauvegarder le contexte », ça veut dire « préserver le minimum vital pour pouvoir revenir à l'état antérieur ». Il s'agit simplement, en général, d'enregistrer les registres du processeur dans la pile. Ça se fait d'ailleurs automatiquement sur une interruption.

Pour le reste, passer en mode noyau est effectivement très coûteux en cycles machine et c'est pour cela qu'on essaie de le faire le moins souvent possible. Jadis, tout était plus un moins synchrone dans un ordinateur, les wait states ne se faisaient pas souvent sentir et ce genre de considérations était secondaire. Aujourd'hui, avec la course permanente à la puissance, il n'y a plus un composant qui puisse se permettre d'en attendre un autre. C'est vrai sur la carte-mère, mais aussi au niveau logiciel. Par exemple, sous Linux, tous les appels systèmes sont désormais tamponnés par la bibliothèque standard, avant d'être réellement effectués si nécessaire.

[PyNub]

Non, je pensais plutôt à un dispositif de surveillance. Soit, c'est le système d'exploitation qui refuse d'honorer certains appels, soit c'est le micro-processeur qui déclenche une exception en cas d'instruction illégale ou de segfault.

D'accord je vois.

http://en.wikipedia.org/wiki/SIGTRAP

Utilisé principalement dans le cadre d'un déboguage, où on force l'interruption d'un programme même dans des conditions normales parce que le développeur a explicitement posé un point d'arrêt à cet endroit. Ça permet surtout au programme de savoir pourquoi il a été interrompu, ce qui peut parfois s'avérer nécessaire.

Le terme TRAP se justifie dans le cadre de la préemption dont on a parlé et parce que certains micro-processeurs proposent des registres dédiés au déboguage, déclenchant automatiquement une exception lorsque le pointeur de programme atteint une adresse donnée.

D'accord c'est un arrêt volontaire du processus au moyen d'une interuption, cela permet de ne pas attendre un erreur du programme pour suspendre le cours d'un processus.

Le système d'exploitation utilise un timer matériel qui déclenche une IRQ à intervalles réguliers. De là, c'est le système qui décide de ce qu'il veut faire. Il peut ou non donner la main à un autre processus, mais en profiter pour faire d'autres tâches, également.

Ok... C'est ce que je supposais en effet... Je ne connais pas très bien le fonctionnement des timers Comment se programme-t-il au niveau assembleur ? Ce que je veux dire c'est qu'il faut bien dire au processeur a tel moment tu déclenche telle interuption comment cela se réalise t il ?

C'est-à-dire que, d'une part, il faut se rendre compte des cadences auxquelles fonctionne un ordinateur : aujourd'hui, un timer milliseconde reste un million de fois (!) plus lent que la cadence d'un processeur à n GHz. Mais calculer le juste milieu d'un tel système a toujours été un sujet d'étude. Il y a trente ans, les ordinateurs fonctionnaient entre 1 et 8 Mhz en moyenne (mille fois moins vite) et ils étaient quand même très utiles.

a quelle vitesse le passage entre le mode noyau et le mode utilisateur se fait il aujourd'hui ? mise à part les appels système et les autres interuptions matérielles. Autrement dit sur quel temps le timer évoqué plus haut est-il réglé ?

Encore une fois, quand on dit « sauvegarder le contexte », ça veut dire « préserver le minimum vital pour pouvoir revenir à l'état antérieur ». Il s'agit simplement, en général, d'enregistrer les registres du processeur dans la pile. Ça se fait d'ailleurs automatiquement sur une interruption.

Tu veux dire qu'il existe une interuption spéciale permettant la sauvegarde du contexte ?

C'est vrai sur la carte-mère, mais aussi au niveau logiciel. Par exemple, sous Linux, tous les appels systèmes sont désormais tamponnés par la bibliothèque standard, avant d'être réellement effectués si nécessaire.

Je ne comprends pas trop le "si nécessaire", si le processus fait un appel système c'est qu'il en a besoin il est au moins nécessaire pour lui, non ?


Merci pour toutes ces explications

[Obsidian]

D'accord c'est un arrêt volontaire du processus au moyen d'une interuption, cela permet de ne pas attendre un erreur du programme pour suspendre le cours d'un processus.

Pas tout-à-fait. Les interruptions servent en général à appeler une routine au bon moment. Lors d'un déboguage, sur un breakpoint ou « point d'arrêt », le programme est réellement mis en suspens jusqu'à ce que le programmeur donne l'ordre explicite au débogueur de poursuivre.

Ok... C'est ce que je supposais en effet... Je ne connais pas très bien le fonctionnement des timers Comment se programme-t-il au niveau assembleur ? Ce que je veux dire c'est qu'il faut bien dire au processeur a tel moment tu déclenche telle interuption comment cela se réalise t il ?

C'est un périphérique extérieur à ton micro-processeur et, à ce titre, il se pilote à travers des ports d'entrées-sorties, comme ton lecteur de disquettes ou ton port parallèle. Il déclenche une interruption matérielle IRQ chaque fois qu'il arrive à échéance, comme le minuteur que tu utilises pour faire des œufs à la coque.

Les IRQ, maintenant, se provoquent en changeant l'état électrique d'une des broches du boîtier de ton micro-processeur (plus précisement, c'est vrai sur les petits micro-processeurs. C'est vrai aussi sur les gros, mais il y a un gros contrôleur d'interruptions intercalé entre le CPU et les périphériques).

a quelle vitesse le passage entre le mode noyau et le mode utilisateur se fait il aujourd'hui ? mise à part les appels système et les autres interuptions matérielles. Autrement dit sur quel temps le timer évoqué plus haut est-il réglé ?

Ça dépend de ta machine et de ton système d'exploitation. La plupart du temps, cette valeur est fixe et inconnue du commun des mortels. Sur les noyaux Linux relativement récents, tu peux configurer cette valeur parmi 100, 250, 300 ou 1000 Hz. Tu peux aussi faire un système Tickless pour éviter que le timer interrompe ton système inutilement. Mais c'est du réglage fin, pas vraiment utile si on ne sait pas ce que l'on fait.

Tu veux dire qu'il existe une interuption spéciale permettant la sauvegarde du contexte ?

Non. Je dis que lorsqu'interruption il y a, le micro-processeur empile de lui-même ses registres. Et heureusement, parce que le programme ne peut pas savoir à l'avance qu'il va être interrompu.

Je ne comprends pas trop le "si nécessaire", si le processus fait un appel système c'est qu'il en a besoin il est au moins nécessaire pour lui, non ?

Oui, mais le fait qu'il y ait un intermédiaire permet de rendre ces appels un peu plus efficaces. Je ne suis pas allé voir en détails comment fonctionne cette couche mais on peut imaginer, par exemple, qu'il se produise un « appel groupé » rapatriant en une seule fois les données nécessaires à plusieurs processus, mais ce n'est qu'une hypothèse.

[PyNub]

C'est un périphérique extérieur à ton micro-processeur et, à ce titre, il se pilote à travers des ports d'entrées-sorties, comme ton lecteur de disquettes ou ton port parallèle. Il déclenche une interruption matérielle IRQ chaque fois qu'il arrive à échéance, comme le minuteur que tu utilises pour faire des œufs à la coque.

Ok ok...

Les IRQ, maintenant, se provoquent en changeant l'état électrique d'une des broches du boîtier de ton micro-processeur (plus précisement, c'est vrai sur les petits micro-processeurs. C'est vrai aussi sur les gros, mais il y a un gros contrôleur d'interruptions intercalé entre le CPU et les périphériques).

oui ça je le savais. par contre je ne sais pas combien il en existe sur les nouveaux proc 64bits... Je pensais que le timer était interne au microprocesseur en fait...

Ça dépend de ta machine et de ton système d'exploitation. La plupart du temps, cette valeur est fixe et inconnue du commun des mortels. Sur les noyaux Linux relativement récents, tu peux configurer cette valeur parmi 100, 250, 300 ou 1000 Hz. Tu peux aussi faire un système Tickless pour éviter que le timer interrompe ton système inutilement. Mais c'est du réglage fin, pas vraiment utile si on ne sait pas ce que l'on fait.

En fait ça dépend (entre autre ) de la proportion des opérations de traitement par rapport a celles d'E/S. Un système effectuant beaucoup d'E/S n'a pas besoin d'être interompu puisque les processus sont souvent bloqués à attendre ces dernières par contre un système effectuant de gros traitement nécessitant de longue périodes UC a besoin d'avoir ses processus organisés de la manière la plus optimale et a donc besoin de soliciter plus souvent l'ordonnanceur. Si j'ai bien compris le bouquin que je suis en train de lire...

Oui, mais le fait qu'il y ait un intermédiaire permet de rendre ces appels un peu plus efficaces. Je ne suis pas allé voir en détails comment fonctionne cette couche mais on peut imaginer, par exemple, qu'il se produise un « appel groupé » rapatriant en une seule fois les données nécessaires à plusieurs processus, mais ce n'est qu'une hypothèse.

Oui en effet vu comme ça je comprends mieux bien que cela doit ajouter un degré de compléxité supplémentaire...


Merci pour toutes ces réponses elle m'aide vraiment

[Obsidian]

En fait ça dépend (entre autre ) de la proportion des opérations de traitement par rapport a celles d'E/S. Un système effectuant beaucoup d'E/S n'a pas besoin d'être interompu puisque les processus sont souvent bloqués à attendre ces dernières par contre un système effectuant de gros traitement nécessitant de longue périodes UC a besoin d'avoir ses processus organisés de la manière la plus optimale et a donc besoin de soliciter plus souvent l'ordonnanceur. Si j'ai bien compris le bouquin que je suis en train de lire...

C'est un poil plus subtil. En fait, peu importe que ton noyau soit interrompu 100 fois ou 1000 fois par seconde si le quantum de temps est multiple de la plus longue période (donc 100 Hz, ici). C'est surtout l'usage que tu en fais qui va être déterminant. Si la machine est une machine de bureau avec laquelle l'utilisateur interagit beaucoup, tu auras intérêt à mettre une fréquence élevée pour que la machine soit très réactive. Par contre, si la machine est un serveur, bien tranquille dans une salle, effectuant un travail de fond comme du calcul en parallèle, tu as tout intérêt à le laisser travailler.

[PyNub]

C'est un poil plus subtil. En fait, peu importe que ton noyau soit interrompu 100 fois ou 1000 fois par seconde si le quantum de temps est multiple de la plus longue période (donc 100 Hz, ici).

multiple de 10ms tu veux dire. Il faut donc que le quantum soit supérieur a la plus longue période pendant laquelle le processeur n'est pas interompu. ou peut être veux tu dire le contraire : si la plus longue période sans interuption est 10ms alors le quantum doit être inférieur à 10ms ? ce que je comprends mieux, sinon pourquoi le quantum doit être supérieur a 10ms dans ce cas il n'y a aucune chance qu'il aille jusqu'au bout...

C'est surtout l'usage que tu en fais qui va être déterminant. Si la machine est une machine de bureau avec laquelle l'utilisateur interagit beaucoup, tu auras intérêt à mettre une fréquence élevée pour que la machine soit très réactive.

Tout dépend aussi du nombre d'utilisateurs qui interagit...

Par contre, si la machine est un serveur, bien tranquille dans une salle, effectuant un travail de fond comme du calcul en parallèle, tu as tout intérêt à le laisser travailler.

ah ok je ne pensais pas justement... Enfin tout dépend si les jobs sont prévisibles et qu'ils arrivent a un moment précis... Moi je pensais un serveur qui recevrait des job de durée variables au fil de l'eau... Si celui-ci est partis dans un job très long peut être vaut il mieux interrompre le job en cours pour exécuter les jobs plus court... Mais bon de toutes façons il faudrait savoir le temps que peut prendre un travail qui n'est pas encore lancé ce qui en général n'est pas le cas.

Bon je vais relire un peu le chapitre sur l'ordonnancement

Merci