Pour ceux que ca interresse , voici les avantages d'un micro-noyeau sur un noyeau monolithique (fut-il modulaire).
1- Un micro noyeau peut faire tout ce que fait un noyeau monolithique. Outre le fait que ca soit super chiant a coder (mais alors beaucoup) un micro noyeau n'a pas d'inconvennient.
2- Un micro noyeau agit pour les fonctions de base comme un noyeau (timing, semaphores, ressources etc..) par contre pour tout ce qui est drivers il est out. Ce qui veut dire non seulement que si un driver plante, vu que mon noyeau n'est pas plante je peux continuer a bosser, mais surtout que je peux choisir mes drivers a la volee en fonction de mes besoins, avec une granularite qui peut descendre jusqu'au thread.
En d'autre terme on peut tres bien imaginer une appli qui utilise un driver graphique pour 80% de ses fonctions mais qui fasse appel a un autre driver pour les operation OpenGL par exemple.
Bien sur on peut aussi imaginer un utilisateur root qui n'a pas les memes drivers de carte reseau que les autres (implementation de ETH0 par exemple).
De plus pour un systeme micro-noyeau un certains nombre de choses qui sont implementees par le kernel passe en drivers (Gestion memoire, filesystems etc..) toutes ces choses sont donc configurable et adaptable a un groupe, un utilisateur ou meme un processus.
Il est meme theoriquement de declarer un deuxieme micro noyeau comme driver et de se lancer a tire larigo dans du kernel hacking sans risquer une seule fois de planter sa machine. Ou de donner a chaque utilisateur un noyeau different.
[^] # Re: Linux,
Posté par Jerome Herman . En réponse à la dépêche Linux, "successeur logique de AIX", selon IBM. Évalué à 10.
1- Un micro noyeau peut faire tout ce que fait un noyeau monolithique. Outre le fait que ca soit super chiant a coder (mais alors beaucoup) un micro noyeau n'a pas d'inconvennient.
2- Un micro noyeau agit pour les fonctions de base comme un noyeau (timing, semaphores, ressources etc..) par contre pour tout ce qui est drivers il est out. Ce qui veut dire non seulement que si un driver plante, vu que mon noyeau n'est pas plante je peux continuer a bosser, mais surtout que je peux choisir mes drivers a la volee en fonction de mes besoins, avec une granularite qui peut descendre jusqu'au thread.
En d'autre terme on peut tres bien imaginer une appli qui utilise un driver graphique pour 80% de ses fonctions mais qui fasse appel a un autre driver pour les operation OpenGL par exemple.
Bien sur on peut aussi imaginer un utilisateur root qui n'a pas les memes drivers de carte reseau que les autres (implementation de ETH0 par exemple).
De plus pour un systeme micro-noyeau un certains nombre de choses qui sont implementees par le kernel passe en drivers (Gestion memoire, filesystems etc..) toutes ces choses sont donc configurable et adaptable a un groupe, un utilisateur ou meme un processus.
Il est meme theoriquement de declarer un deuxieme micro noyeau comme driver et de se lancer a tire larigo dans du kernel hacking sans risquer une seule fois de planter sa machine. Ou de donner a chaque utilisateur un noyeau different.
Kha