question sur le principe d un system d exploitation [os] - Divers - Linux et OS Alternatifs
Marsh Posté le 01-06-2003 à 17:50:32
mmm.. c un peu plus compliqué. Je suis loin d'être un spécialiste mais dans un un OS multitaches (Linux/Unix, NT), chaque processus (tache) possède son propre environement de travail soit autant d'environnements que de tache. C'est pour ça que sur un OS multitache quand un programme est planté, il est planté dans son envirronement et tu as toujours la main (c pour ça que 98 était si plantogène). Tu ne récupère pas la main, tu ne la perd pas.
Après, bien sur si il n'y a pas assez de place pour tous les process, on ralenti le système mais les taches déjà en place ont toujours leur envirronement et reste en vie. Par exemple un serveur avec un samba qui tourne et qui commence à monter en charge pour une raison quelconque. Samba reste étonnament vivace jusqu'à la mort de la machine bien sur.
Citation : et puis comment prevoit il que le processus ne sorte pas de l espace memoire allouee |
Ben il ne sort pas de l'espace alloué, sinon c'est un bug.
En fait des fois on a l'impression que son PC est totallement planté (aucune réponse souris clavier) et on s'apercoit qu'en y accédant en ssh et en tuant X ça repart....
Marsh Posté le 01-06-2003 à 18:34:40
Slvn a écrit : |
je crois que c'est le scheduler qui s'occupe de ça
il alloue un temps d'exécution à chaque processus
ça tourne entre tous les processus, chacun leur tour (tu peux établir des priorités pour qu'un processus garde la main plus souvent, ou pour qu'il prenne la main plus souvent ... c'est selon l'algo utilisé)
mais quoiqu'il arrive, tu récupères toujours la main, sauf si c'est le kernel lui-même (ou un driver) qui est buggé
Marsh Posté le 01-06-2003 à 18:43:24
udok a écrit : |
tout à fait. Je me positionnais sur le plan purement théorique. Maintenant le proc il fait une chose à la fois , d'où l'ordonanceur...
Marsh Posté le 01-06-2003 à 18:46:14
je crois qu'au niveau materiel il y a une intetuption qui permet de rendre la main a l'ordonaceur
Marsh Posté le 01-06-2003 à 18:54:45
ganjo a écrit : je crois qu'au niveau materiel il y a une intetuption qui permet de rendre la main a l'ordonaceur |
oui c est plutot de se cote la que ca m interesse
mais si y a une interruption, elle se declenche sur quoi ??
sur une temps de xx milisec??
dans ce cas, comment ca peut tester si des pointeurs touches un autre espace memoire??
Marsh Posté le 01-06-2003 à 18:58:49
Slvn a écrit : |
ça dépend de l'algo de l'ordonnanceur, des priorités des processus, etc...
fait un "nice -n -20 mon_prog" (man nice pour plus d'info) et tu verras que ta souris va bien ramer, les caractères dans le terminal vont s'afficher moins vite, etc...
et je pense aussi que c'est une interruption qui permet à l'ordonnanceur de reprendre la main (de toute façon y-a pas bcp d'autres solutions qui permettraient ça )
Slvn a écrit : dans ce cas, comment ca peut tester si des pointeurs touches un autre espace memoire?? |
gni ?
Marsh Posté le 01-06-2003 à 19:05:56
oups, exucuse moi, je rend compte que je me suis mal exprime. je tache d etre plus clair:
1/ comment l OS decide il qu un processus en cours ne soit plus en cours. (c est a dire qu il rend la main)
2/ comment l OS s assure t il qu un processus en cours ne touche qu a la memoire RAM qui lui est reservée.(et donc qu il touche pas a la RAM d un autre processus)
je parle de maniere bas niveau:
une fois qu un prog s execute, c est a dire que le processeur execute une par une les instruction de ce prog. qu est ce qu il fait qu il s arrete a un moment, et que le processeur change le processus a executer.
Marsh Posté le 01-06-2003 à 19:14:25
Slvn a écrit : oups, exucuse moi, je rend compte que je me suis mal exprime. je tache d etre plus clair: |
1/ déjà dit : c'est l'ordonnanceur qui fait ça : apès un laps de temps prédéfini, l'os reprend la main (enfin l'ordonnanceur reprend la main), et autorise un autre processus à continuer là où il en était la derniere fois qu'on l'a arrété
2/ l'os mémorise quels segments de mémoire sont alloués à un processus
si elle veut accéder en dehors de cette mémoire => segmentation fault
par contre il y a l'histoire de buffer overflow que j'ai pas vraiment comprite
Marsh Posté le 01-06-2003 à 20:00:47
Oui tu a repondu en parti. le role de l ordonnanceur est important dans la reaprtiion du processeur pour les processus.
La je parle pour la reprise de la "main".
L ordonnanceur ne reprend pas la main lui meme vu qu il n est pas en cours d execution.
=> donc comment se fait la reprise de la main??
je pense pas que ca soit fait par une interruption...
Marsh Posté le 01-06-2003 à 20:02:43
Slvn a écrit : Oui tu a repondu en parti. le role de l ordonnanceur est important dans la reaprtiion du processeur pour les processus. |
bah ça je ne suis pas sur mais je ne vois pas vraiment d'autre solution ...
attendons un expert en la matière qui pourra nous éclairer
Marsh Posté le 02-06-2003 à 09:42:28
Dns le cas du segfault, cest directement géré par le proc (pour les x86 en tout cas)
En effet le proc gère 20 exceptions possibles, de la division par zero a l'instruction non valide en passant par le point d'arret pour le debogage).
Marsh Posté le 02-06-2003 à 12:36:24
donc pour le seg fault, il doit y avoir deux registres contenant les "bornes" de l espace qu il peut adresser.
et quand il utilise une memoire partage...
c compliquer ces choses
Marsh Posté le 02-06-2003 à 13:23:06
Slvn a écrit : donc pour le seg fault, il doit y avoir deux registres contenant les "bornes" de l espace qu il peut adresser. |
meme chose je pense, après tout le proc pourrait avoir plusieurs bout de code qui est doit a la meme memoire
A moin que ca ne soit géré par le kernel, qui peut tenir compte d'ignorer le segfault dans certains cas
Marsh Posté le 02-06-2003 à 13:36:20
ouai mais la chose compliqué, c'est de comprendre le mécanisme du buffer overflow, si le segmentation fault est géré .... c'est bizarre quand même
Marsh Posté le 02-06-2003 à 14:05:12
pour la memoire partage. ca passe par le system de fichier. donc le mecanisme n a surement rien a voir.
pour le buffer overflow, le but est de depasser le contenu de sa propre memoire. et de changer la valeur de retour de la fonction dans la pile.
donc le tout se faire "proprement" si on peut dire, pour bluffer le processeur...
Marsh Posté le 02-06-2003 à 14:09:07
Slvn a écrit : pour la memoire partage. ca passe par le system de fichier. donc le mecanisme n a surement rien a voir. |
mais comment bluffer le processeur justement ? vous êtes sur que la mémoire est protéger sous linux ? c'est bizarre qu'il ne fasse pas un segfault ... dans quel cas il en fait un, et dans quel cas il y a faille ?
Marsh Posté le 02-06-2003 à 14:10:39
segfault, quand tu sort de TA memoire.
le buffer overflow y a pas de segfault car tu reste dans ta propre memoire, en fait tu vient modifier une valeur dans la pile. l adresse de retour d une fonction.
comme ca, quand le proc execute le retour de fonction. il va executer une autre prog
Marsh Posté le 02-06-2003 à 14:17:29
Slvn a écrit : Oui tu a repondu en parti. le role de l ordonnanceur est important dans la reaprtiion du processeur pour les processus. |
hehe j'ai exam la desus samedi
Ya surement plein de facons de faire mais une qu'on a vu c'est que chaque process dispose d'un quantum de temps q. Pdt son quantum, le process dispose du processeur pour travailler.
2 possibilités:
- soit le process rend la main avant la fin de son quantum, par ex il attends un I/O. Auquel cas il fait une demande au superviseur, ce qui a pour effet de provoquer une interuption et d'etre propulser dans l'OS. Pdt que le process attend son I/O, l'OS peut donner la main a un autre process.
- soit le process consumme tout son quantum sans rendre la main, auquel cas une interuption horloge est déclenchée ce qui a pour effet de rendre la main à l'OS qui peut donner un quantum au process suivant.
Ca crée un sytème de tourniquet appelé 'Round Robin' qui donne la main à chaque process chacun à son tour.
C'est assez simplifié mais j'espère avoir été clair.
Marsh Posté le 02-06-2003 à 14:56:35
Slvn a écrit : segfault, quand tu sort de TA memoire. |
ah mais oui exact
je confonds tout moi, je croyais qu'on pouvait obtenir les droits root avec ça, mais en fait non, et c'est là tout l'interet de ne pas démarrer quoi que ce soit en root
Marsh Posté le 02-06-2003 à 15:38:09
Cassidy a écrit : |
Théoriquement OK, c'est comme ça que je voyais la chose, mais en pratique, pour qu'une interruption extérieure stoppe l'exécution, il faut qu'elle ait été prévue avant?
Qqch comme "Dans tant de ms, déclencher telle interruption et maintenant passer la main à tel processus dont c'est le tour"?
Marsh Posté le 02-06-2003 à 15:43:50
Pour la protection de la mémoire extérieure à un programme, les anciens processeurs type Motorola 68000 ne le pouvaient pas.
Le 68030 par contre oui.
La différence, c'est qu'un code a 2 manières d'être exécuté; avec ou sans le bit S système. Sans le bit système, il a bcp de limitations et ne peut physiquement pas sortir d'un certain adressage.
(j'ai pas un souvenir très clair du bit système et de la pagination mémoire. Ce sont 2 choses différentes apparues presque en même temps et qui permettent, réunies, d'éviter l'exécution de n'importe quoi et d'accéder à n'importe quoi)
Marsh Posté le 02-06-2003 à 16:11:51
phosphorus68 a écrit : |
L'interuption horloge est déclenchée par un circuit autonome lorsque son décompte atteint 0.
Je présume donc que lorsque l'OS donne la main a un process il remet ce compteur à la valeur d'un quantum.
Marsh Posté le 02-06-2003 à 19:44:59
euh,
donc a chaque interruption, le processus en cours est derouté et le scheduler est appelé!
et si par hasard, l interruption apparait au moment ou le scheduler s execute...ca fout le bazaar
Marsh Posté le 02-06-2003 à 20:36:32
le scheduler n'est pas appellé pour toutes les interruptions juste celle qui le concernent.
Quel interruption? Toute facon lors de la gestion d'une interruption, tu ne peux etre interrompu que par une interruption strictement plus prioritaire.
Marsh Posté le 02-06-2003 à 20:55:24
dsl, c etait ambigue.
je parle de l'exception qui vient pour qu un processus rendent la main. (j ai mis un S, car il y a plusieurs fois la meme au court du temps.)
Marsh Posté le 02-06-2003 à 20:56:02
Reply
Marsh Posté le 01-06-2003 à 17:15:17
bonjour,
j ai une question sur le fonctionnement d un system d exploitation :
l OS permet d proteger l execution d un programme :
zone memoire protege, temps d execution limite, qui font en sorte qu on ne plante pas un OS bien concu!
Cependant, a partir du moment ou un programme s execute, comment l OS fait il pour reccuperer la main
est ce que c est prevu au depart, que l OS recupere la main apres un certain temps ?
et puis comment prevoit il que le processus ne sorte pas de l espace memoire allouee ?