Les IPC ne rajoutent pas une complexité non négligeable. Au niveau de la programmation, en ce qui concerne les mécanismes d'IPC, lit la documentation de l4, il m'a semblé que ce n'était pas si complexe, en ce qui concerne les logiciels, le portage de debian sous Hurd montre bien qu'il n'y a pas besoin de les réécrire. C'est au niveau performance que le bas blesse, Mach est réputé pour être lent mais depuis les choses ont bien progresser et les micro noyaux de secondes génération sont plus rapides (encore une fois l4 est ton ami).
Evidemmennt les micro noyaux ne sont pas LA solution pour éradiquer tous les bugs, si ton programme est foireux, il est foireux, la séparation va seulement limiter l'impact des bugs. Je donnais l'exemple de fglrx qui parfois fait tout planter. Lors de démonstration de Hurd, le conférencier avait killer le prog en charge de sa partition home, le système n'a pas bronché et a redémarrer le prog, les services qui n'utilisaient pas la partition home n'ont pas été affecté. Sur un serveur, il serait dommage qu'un plantage du driver de la webcam qui sert a la vidéo surveillance fasse planter tout le système et par conséquent le serveur ssh qui aurait permis de réparer le problème.
Je pense que l'architecture micro noyaux n'est pas une fin en soit mais un moyen de dépasser les limites actuelles. Sous linux les modules sont en espace noyaux, il est donc nécessaire pour la sécurité que n'importe qui ne puisse pas en charger. Pourtant si veut monter un système de fichier sur une machine sous linux où on est pas root, on y était bien obligé. Depuis il y a FUSE, et si on regarde les projets de systèmes de fichiers implémenté avec FUSE, certains sont bien rodés (sshfs est une merveille) et serait peut être intégrés dans le noyaux sans trop de résistance, d'autres sont encore instables et jamais il n'aurait été mis dans le noyaux, et même s'ils était disponibles en module séparés, aucun admin sérieux ne les chargerait.
D'autre part, avoir des drivers en tant que simple programme en espace utilisateur permet de choisir son langage de programmation, je suis d'accord que c'est aussi faisable dans le noyaux, mais des programmes en O'Caml, C++, Java,... demanderaient qu'une run-time soient codé dans le noyau, personnellement je ne croient pas que ce soit ajouté un jour. La capacité de développer des drivers dans des langages de haut niveau elle aussi limite les bugs, prennons le cas de O'Caml, la gestion de la mémoire, le typage static fort, ... évite de nombreux bugs (mauvais ordre des paramètres, mauvais calcul de pointeur, etc ...) et tous ceux qui font l'amalgame entre langages de haut liveau et lenteur iront se référer aux performance du compilateur d'O'Caml.
Quoi qu'on en disent et même si on s'appelle Linus, l'approche micro noyau s'imposera, non pas pour faire plaisir a Tanenbaum ou pour éradiquer les bugs (sinon personne ne serait plus sous windows) mais pace que on veut de la flexibilité et de la simplicité (je considre qu'il est plus simple de programmer son fs en fuse, que de l'intégrer au noyau). C'est pas pour rien que Linux est passé a un système modulaire et lorgne de plus en plus sur le userspace (udev, fuse, ...).
[^] # Re: Lancer de troll /o/ ------------- *
Posté par GTof . En réponse au journal La vengeance de Tanenbaum. Évalué à 6.
Evidemmennt les micro noyaux ne sont pas LA solution pour éradiquer tous les bugs, si ton programme est foireux, il est foireux, la séparation va seulement limiter l'impact des bugs. Je donnais l'exemple de fglrx qui parfois fait tout planter. Lors de démonstration de Hurd, le conférencier avait killer le prog en charge de sa partition home, le système n'a pas bronché et a redémarrer le prog, les services qui n'utilisaient pas la partition home n'ont pas été affecté. Sur un serveur, il serait dommage qu'un plantage du driver de la webcam qui sert a la vidéo surveillance fasse planter tout le système et par conséquent le serveur ssh qui aurait permis de réparer le problème.
Je pense que l'architecture micro noyaux n'est pas une fin en soit mais un moyen de dépasser les limites actuelles. Sous linux les modules sont en espace noyaux, il est donc nécessaire pour la sécurité que n'importe qui ne puisse pas en charger. Pourtant si veut monter un système de fichier sur une machine sous linux où on est pas root, on y était bien obligé. Depuis il y a FUSE, et si on regarde les projets de systèmes de fichiers implémenté avec FUSE, certains sont bien rodés (sshfs est une merveille) et serait peut être intégrés dans le noyaux sans trop de résistance, d'autres sont encore instables et jamais il n'aurait été mis dans le noyaux, et même s'ils était disponibles en module séparés, aucun admin sérieux ne les chargerait.
D'autre part, avoir des drivers en tant que simple programme en espace utilisateur permet de choisir son langage de programmation, je suis d'accord que c'est aussi faisable dans le noyaux, mais des programmes en O'Caml, C++, Java,... demanderaient qu'une run-time soient codé dans le noyau, personnellement je ne croient pas que ce soit ajouté un jour. La capacité de développer des drivers dans des langages de haut niveau elle aussi limite les bugs, prennons le cas de O'Caml, la gestion de la mémoire, le typage static fort, ... évite de nombreux bugs (mauvais ordre des paramètres, mauvais calcul de pointeur, etc ...) et tous ceux qui font l'amalgame entre langages de haut liveau et lenteur iront se référer aux performance du compilateur d'O'Caml.
Quoi qu'on en disent et même si on s'appelle Linus, l'approche micro noyau s'imposera, non pas pour faire plaisir a Tanenbaum ou pour éradiquer les bugs (sinon personne ne serait plus sous windows) mais pace que on veut de la flexibilité et de la simplicité (je considre qu'il est plus simple de programmer son fs en fuse, que de l'intégrer au noyau). C'est pas pour rien que Linux est passé a un système modulaire et lorgne de plus en plus sur le userspace (udev, fuse, ...).