Nous souhaitons déposer des cookies à des fins de mesure d'audience avec Google Analytics. Vous êtes libre d'accepter ou de refuser. En poursuivant votre navigation sur ce site sans exprimer votre choix, vous autorisez la mesure d'audience.
Bonjour j’ai lu la première partie du cours "Les systèmes d’exploitation", je n’ai pas compris l’explication sur le noyau monolithique, elle dit qu’un maximum de programme systèmes sont placés dans l’espace noyau et que donc peu d’appels systèmes sont fait mais ce n’est pas plutot le contraire ? Je ne comprends pas pourquoi le fait qu’il y aurait beaucoup de prg systèmes dans l’espace noyau ça engendre moins d’appels systèmes.
Les appels systèmes servent aux programmes de l’espace utilisateur. Si le programme est dans l’espace noyau, il n’as pas besoin des appels système.
Les appels systèmes sont une sortes d’interface entre espace noyau et utilisateur, qui permettent depuis l’espace utilisateur d’utiliser des fonctions (au sens utilité) du noyau.
Dans l’idée, un programme en espace noyau peut de lui même interagir avec le matériel si j’ai bien compris.
Hum en fait je pensais que les appels systèmes servaient surtout pour les programmes applicatifs puissent communiquer avec le matériel, du coup je pensais que même si le prg système se trouve en espace noyau il doit tout de même faire un appel système
En fait, un CPU possède plusieurs niveaux de privilèges, lorsqu’il exécute un logiciel donné. Ce niveau de privilège permet de déterminer ce que le « logiciel a le droit de faire ».
Il est donc possible de configurer le CPU de manière à ce que le logiciel executé ne puisse plus interagir directement avec des périphériques matériels ; c’est ce qu’on appelle l’userland.
Pour interagir avec du matériel, il est donc nécessaire de « sortir » du userland ; en d’autres termes, de changer le niveau de privilège du CPU. La façon dont cette sortie se fait dépend du CPU, mais globalement, l’idée c’est que le logiciel exécuté hors du userland n’est pas sous le contrôle de l’application. Cela permet effectivement d’assurer l’isolation, quand c’est bien fait.
Donc, en résumé et pour revenir au sujet qui intéresse ici : lorsqu’un programme est exécuté en userland, il ne peut pas interagir avec certains périphériques matériels ; lorsqu’un programme est exécuté directement « dans » le kernel, il le peut. D’où la nécessité de sortir du userland dans un cas, nécessité qui n’existe pas dans le second cas car on dispose déjà des droits nécessaires.
Merida is so cool · “Now that I have built my very own hammer, nothing looks like a nail anymore. ”
Bonjour j’ai lu la première partie du cours "Les systèmes d’exploitation", je n’ai pas compris l’explication sur le noyau monolithique, elle dit qu’un maximum de programme systèmes sont placés dans l’espace noyau et que donc peu d’appels systèmes sont fait mais ce n’est pas plutot le contraire ? Je ne comprends pas pourquoi le fait qu’il y aurait beaucoup de prg systèmes dans l’espace noyau ça engendre moins d’appels systèmes.
En fait, la conception d’un noyau monolithique fait qu’un maximum de services sont intégrés de base au noyau pour justement éviter d’utiliser des appels systèmes et avoir des gains de performance comme l’ont souligné ache et entwanne.
Avec une architecture de type micro-noyau, on rentre dans des problématique de sécurité comme l’explique lthms. Il y a une nécessité pour les programmes utilisateurs de ne pas avoir à accéder à n’importe quelle ressource système directement. Il faut que cela soit fait de manière contrôlée : un noyau monolithique offre ainsi une interface - les appels systèmes - aux programmes en userland (que ça soit ton navigateur internet, ton éditeur de texte, …) pour profiter de ces services de manière contrôlée.
Avec un micro-noyau, contrairement aux noyaux monolithiques, tu vas aussi intégrer des passerelles, des interfaces entre les différents services au sein du noyau. L’avantage est que les échanges de données seront contrôlés (Cf. à nouveau la réponse de lthms) mais tu auras des impacts de performance. Or, un noyau se doit d’être performant dans l’exécution de ses diverses tâches fastidieuses.
Donc dans un noyau monolithique, puisque tu as tous les services un peu en "bric-à-brac" puisqu’il s’agit de l’extérieur d’un noyau où tout est intégré dedans, "peu d’appels systèmes sont faits" puisque tous les services communiquent entre eux de la manière la plus fine et sans les fameux contrôles exécutés via les appels systèmes.
Je me permet juste de revenir sur ceci. Un noyau ne « se doit » pas forcément d’être performant, cela dépend des objectifs recherchés. Si l’objectif premier est la sécurité par exemple, les performances passeront au second plan.
Vous devez être connecté pour pouvoir poster un message.
Connexion
Pas encore inscrit ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
