Tu peux aussi balancer les arguments opposés : un micro-noyau, en appliquant des
découpages plus scricts, impose une séparation plus clair des responsabilités,
chaque bloc devient plus facile à maintenir / faire évoluer indépendamment.
Malheureusement, on s'aperçoit vite que les découpages stricts, avec l'évolution du matériel, notamment les cartes graphiques, ne reflètent plus la réalité matérielle.
D'ailleurs, même sous Linux, le sous-système gérant les cartes 3D a récemment subi des modifications majeures (FB, X.org, GLX, DRM, GEM, KMS, Gallium3D, Wayland), parce que c'est dur de faire une bonne abstraction, et notamment avec le modèle DRM+X.org, on a un peu l'idée d'un micro-noyau (X.org composant user-space contenant le code du pilote), mais ça ne marchait pas, au sens où, chaque chipset graphique avait besoin d'une interface DRM différente, bien qu'assez légère comparée à la complexité du code en espace utilisateur. Au final, les choses sous Linux sont en train d'évoluer, avec tout qui passe en espace noyau bien monolithique comme sous Windows, ce qui ne veut pas dire qu'il n'y a pas d'abstraction matérielle, mais elle part du principe que la mémoire est partagée dans le noyau, ce qui permet d'avoir des interfaces beaucoup plus complexes et subtiles pour le même temps de développement.
MINIX et HURD ne prouvent rien. Tout le monde peut faire des interfaces propres, stables et bien définies pour des choses aussi simples que PATA ou Ethernet 10/100 Mbps.
Par contre, dans l'embarqué, où les choses sont beaucoup plus simples, un micro-noyau peut être très intéressant.
[^] # Re: Avis de Linus Torvalds sur les micro-noyaux
Posté par NanoTech . En réponse à la dépêche Entretien avec Andrew Tanenbaum à propos de MINIX. Évalué à 3.
Malheureusement, on s'aperçoit vite que les découpages stricts, avec l'évolution du matériel, notamment les cartes graphiques, ne reflètent plus la réalité matérielle.
D'ailleurs, même sous Linux, le sous-système gérant les cartes 3D a récemment subi des modifications majeures (FB, X.org, GLX, DRM, GEM, KMS, Gallium3D, Wayland), parce que c'est dur de faire une bonne abstraction, et notamment avec le modèle DRM+X.org, on a un peu l'idée d'un micro-noyau (X.org composant user-space contenant le code du pilote), mais ça ne marchait pas, au sens où, chaque chipset graphique avait besoin d'une interface DRM différente, bien qu'assez légère comparée à la complexité du code en espace utilisateur. Au final, les choses sous Linux sont en train d'évoluer, avec tout qui passe en espace noyau bien monolithique comme sous Windows, ce qui ne veut pas dire qu'il n'y a pas d'abstraction matérielle, mais elle part du principe que la mémoire est partagée dans le noyau, ce qui permet d'avoir des interfaces beaucoup plus complexes et subtiles pour le même temps de développement.
MINIX et HURD ne prouvent rien. Tout le monde peut faire des interfaces propres, stables et bien définies pour des choses aussi simples que PATA ou Ethernet 10/100 Mbps.
Par contre, dans l'embarqué, où les choses sont beaucoup plus simples, un micro-noyau peut être très intéressant.