2485 connectés

FORUM HardWare.fr

Linux et OS Alternatifs

Divers

[os]question sur le principe d un system d exploitation

Recherche :

Dernière réponse

Sujet : [os]question sur le principe d un system d exploitation

slvn

Le Sot Zi a écrit :

cf ma signure...

et pis ça : www.mega-tokyo.com/forum

marrant comme signature :)

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

slvn

Le Sot Zi a écrit :

cf ma signure...

et pis ça : www.mega-tokyo.com/forum

marrant comme signature :)

slvn	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.)

cf ma signure...

et pis ça : www.mega-tokyo.com/forum

cassidy

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.

slvn	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:??:

cassidy

phosphorus68 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"?

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.

phosphorus68

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)

phosphorus68

Cassidy a écrit :

- 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.

udok

Slvn a écrit :

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 ;)

ah mais oui exact :jap:
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 :)

cassidy

Slvn a écrit :

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...

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. :)

slvn	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 ;)

udok

Slvn a écrit :

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...

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 ?

slvn

udok	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

ganjo

Slvn a écrit :

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 :d

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

slvn	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 :d

ganjo

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).

udok

Slvn a écrit :

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...

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 :D

slvn

udok

Slvn a écrit :

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.

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 [:joce]

slvn

udok

Slvn a écrit :

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??

ç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 :D )

Slvn a écrit :

dans ce cas, comment ca peut tester si des pointeurs touches un autre espace memoire??

gni ? :??:

slvn

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??

ganjo

je crois qu'au niveau materiel il y a une intetuption qui permet de rendre la main a l'ordonaceur

Mr YouP

udok 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é

tout à fait. Je me positionnais sur le plan purement théorique. Maintenant le proc il fait une chose à la fois , d'où l'ordonanceur...

udok

Slvn a écrit :

est ce que c est prevu au depart, que l OS recupere la main apres un certain temps ?

Mr YouP

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....

slvn

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 ?