j'ai bien peur que tout ça soit à peu près aussi coûteux que les changements de contexte user/kernel quand on utilise un process normal en mode user.
En fait ce que je propose ça serait des sortes de processus privilégiés, qui auraient la possibilité d'accéder au hardware mais n'utiliseraient pas la mémoire virtuelle et toutes ces choses, pour des raisons de performances.
Pour ce que je connais du système, et en supposant que les mécanismes hardware de protection mémoire soient suffisement flexibles, ça consisterait à mettre en place un espace "kernel", un "espace utilisateur", un espace "kernel bis" et un espace "utilisateur bis".
L'espace "kernel bis" serait l'espace kernel normal sauf que les mécanisme de protection mémoire seraient activé. L'espace "utilisateur bis" serait la partie de l'espace mémoire auquel les membres de "kernel bis" auraient accès.
En cas d'IRQ, au moment de choisir le handler, on activerais la protection mémoire suivant que l'appel est destiné à "kernel bis" ou non.
On perdrais quelque chose comme un cycle ou deux par appel système libres (tester un flag) et cinq cycles par appel système pas libre (tester le flag et activer la protection).
Je précise que les ordres de grandeur son le fruit de mon imagination, qu'il est 3:50 et que je ne connais pas bien la manière dont la protection mémoire est implantée sur les x86. Ceci dit, à la réflection je crois qu'elle consiste à mettre en place 3 anneaux dans lesquels les membres des anneaux supérieurs ont accès à tous les anneaux inférieurs. Ça permettrait pas de protéger l'espace utilisateurs des modules propriétaires, donc aucun intérêt -_-. Mais je suis pas sûr, et je sais pas ce qu'il en est sur les autres architectures.
[^] # Re: Micro noyau
Posté par un_brice (site web personnel) . En réponse au journal Micro noyau. Évalué à 1.
En fait ce que je propose ça serait des sortes de processus privilégiés, qui auraient la possibilité d'accéder au hardware mais n'utiliseraient pas la mémoire virtuelle et toutes ces choses, pour des raisons de performances.
Pour ce que je connais du système, et en supposant que les mécanismes hardware de protection mémoire soient suffisement flexibles, ça consisterait à mettre en place un espace "kernel", un "espace utilisateur", un espace "kernel bis" et un espace "utilisateur bis".
L'espace "kernel bis" serait l'espace kernel normal sauf que les mécanisme de protection mémoire seraient activé. L'espace "utilisateur bis" serait la partie de l'espace mémoire auquel les membres de "kernel bis" auraient accès.
En cas d'IRQ, au moment de choisir le handler, on activerais la protection mémoire suivant que l'appel est destiné à "kernel bis" ou non.
On perdrais quelque chose comme un cycle ou deux par appel système libres (tester un flag) et cinq cycles par appel système pas libre (tester le flag et activer la protection).
Je précise que les ordres de grandeur son le fruit de mon imagination, qu'il est 3:50 et que je ne connais pas bien la manière dont la protection mémoire est implantée sur les x86. Ceci dit, à la réflection je crois qu'elle consiste à mettre en place 3 anneaux dans lesquels les membres des anneaux supérieurs ont accès à tous les anneaux inférieurs. Ça permettrait pas de protéger l'espace utilisateurs des modules propriétaires, donc aucun intérêt -_-. Mais je suis pas sûr, et je sais pas ce qu'il en est sur les autres architectures.