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