Le GNU/Linux est considéré comme un noyau monolithique. Mais alors peut on encore parler de système de noyau en bloc, à partir du moyen où l'utilisation des modules kernels reduisent le role du kernel à un simple "gestionnaire" de modules externes ?
Oui, définitivement, oui. Tu dois remarquer toi-même, dans ta phrase, une contradiction flagrante : tu parles de module noyau. Tu es bien conscient que ces modules n'ont aucune autonomie, et qu'il s'agit juste de bouts de code qui seront ajoutés ou enlevés dynamiquement - c'est le principe des LKM. Ces bouts de code, une fois intégrés, font partie du noyau au même titre que ceux qui n'auront pas été chargés dynamiquement. Alors, le noyau n'est plus un gestionnaire de modules externes, puisqu'il comporte les parties qui étaient dans les modules. La modularité qu'implique l'utilisation de LKMs - très intéressante, cependant - n'est qu'une astuce pratique pour facilité la vie des utilisateurs : elle ne constitue en aucun cas une modularité de design, en aucun cas une modularité « logique » : si tu dois faire un schéma des différentes fonctions de l'OS, et par qui elles sont assurées, tu devras toujours faire un schéma avec un énorme (puisqu'il contiendra plein de cases avec ce qu'il fait, donc pas au sens de l'espace disque) noyal au milieu : un noyal monolithique.
Il faut bien aussi voir que s'il est difficile de discriminer parfaitement un micro-noyau d'un noyau monolithique, c'est parce qu'il s'agit également d'une question d'esprit, d'évolution, de volonté dans la conception du noyau, et pas seulement qu'une question des fonctionnalités que l'on peut avoir en espace utilisateur et superviseur (et en aucun cas, une question de taille). Mach, par exemple, bien que fournissant la majeure partie de son VMM en kernel space (toute la partie concernant la décision de quelles pages est swapped ou swapped in se trouve dans le noyau), fournit un certain mouvement vers l'espace utilisateur en fournissant le principe de memory objects et de backing store, délégant la responsabilité du choix du traitement de ces pages swapped out à un pager (page fault handler), qui sera chargé de les restituer quand y'en aura besoin (en cas de page fault). C'est, en fait, sur ce principe que sont implémentés les systèmes de fichier en espace utilisateur - et on imagine l'avantage qu'une telle approche fournit par rapport à des systèmes distribués, avec une mémoire distribuée, par exemple. Ces innovations, cette optique, plus le fait qu'une grande partie soit déjà délocalisée, en fait vraiment un micro-noyau. Ce qu'on ne peut pas dire de Linux. Linux, lui, a pour optique, de l'avis même de Linus Torvalds, une optique qui n'est pas celle du design, mais celle d'un pragmatisme technique. Ainsi, le cas de la VMM est intéressant : si l'on prend par exemple la VM rmap, on ne peut dire qu'elle n'est pas designée : elle est réfléchie, pensée, structurée, articulé autour d'un principe de reverse-mapping qui se justifie totalement, et le fait est que techniquement, c'est, à mon avis, une excellente VM.
En revanche, a-t-elle un vrai design de structure ? De la même façon que Linux, je ne le pense pas : il s'agit simplement d'une entité monolithique, ou tout est ensemble, les fonctions pas ou peu séparées logiquement, juste un programme, comme ça. Le cas de Mach évoqué ci-dessus montre un réel effort de design, puisqu'il y'a une séparation logique entre le "Who?" et le "Where?", permettant déjà une modularité et une adaptabilité qui change la vie. Voilà, ce que veut dire la modularité, et le design du Hurd. C'est encore plus vrai dans le cas de la VMM qui a été concue pour le Hurd sur L4[0].
Peut on encore parler de noyau monolithique à partir du moment où le plantage d'un module n'entraine pas l'arret complet du système ?
Euuuuh, ce ne serait plus des modules, mais des entités séparées. Ce qui n'est pas le cas actuellement. Je le dis et le répète : ce qui change dans un module, c'est la façon d'arriver dans le kernel, et le fait qu'on puisse le virer puis le remettre dynamiquement. C'est uniquement une facilité technique. Ils ont donc exactement les mêmes droits que ceux qui sont déjà dans le noyau. Ils peuvent provoquer l'arrêt complet du système, le plantage complet du noyau. Pensons par exemple aux drivers (libres) du winmodem du portable de Kilobug qui plantent quand on joue un ogg en se connectant :-)
La multiplication des systèmes d'exploitation "libres" (xBSD, Linux, Hurd), et je ne parle pas des multiples distributions linux ou version xBSD, ne risque t-il pas d'amener un peu plus de confusion chez les utilsateurs des dits systèmes, alors qu'une certaine cohésion commence (enfin) à se faire jour autour de GNU/Linux ?
C'est réellement une fausse question. Le problème est, il faut que les utilisateurs aient une vue d'ensemble assez globale du paysage disponible. Celà ne veut pas dire, des préjugés à deux balles qu'ils répandent sur les newsgroups du genre « Nunux c'est pour les débutants, ensuite c'est BSD pour les vrais proZ, etc. ». Ça veut dire avoir quelques éléments de base théorique, qui vont permettre de dire « Bon, voilà, les deux sont des trucs qui sont de la même famille, compatibles, y'a les mêmes logiciels dessus, c'est donc ce qui est très bas niveau qui change, genre tout ce qui va concerner le matos, etc. ». Ça va pas très loin, ça nécessite pas grand chose, mais ce serait heureux qu'un utilisateur basique sache un minimum d'informatique. Comment ça, utopiste ? (:
Si l'on ne parle pas d'opposition, alors j'ai un peu de mal à comprendre la complémentarité entre les deux systèmes. Existe t-il un système "libre" plus performant que l'autre (vitesse, éxécution des programmes, gestion de la MC, gestion des périphériques), de telle manière que le système le plus rapide pourrait servir pour "des expérimentations" et l'autre pour une production en entreprise ?
Si l'on ne parle pas d'opposition, c'est plus pour éviter le sous-entendu de rejet mutuel et de non communication entre les deux mondes. Linux, de par son excellence technique, a beaucoup à nous apprendre. Le Hurd pourrait apprendre pas mal de choses aux développeurs Linux. Pour l'instant, il n'y a pas « compétition » : les développeurs de GNU/Hurd utilisent GNU/Linux pour travailler, et l'un sert à l'autre. Il sert aussi à l'autre dans la mesure où il permet la promotion du libre, et le développement de logiciels libres, qui marcheront ensuite sous GNU/Hurd. Cependant, il ne faut pas se leurrer : GNU/Linux et GNU/Hurd se veulent des systèmes adaptables à à peu près toutes les possibilités - GNU/Hurd surtout, bien entendu ;-) Ils s'adressent donc au même public : tous ! Ensuite, le minoritaire pourra être utilisé pour des tâches où les avantages de l'autre ne comptent pas vraiment - changer le coeur d'un OS change beaucoup de choses, mais il ne peut pas tout.
Cette dernière question est la suite logique de la troisième, à savoir : Ces deux systèmes (diamétralement) opposées dans leur conception de base, peuvent ils etre compatibles au niveau des binaires, comme cela existe avec les Unix commerciaux et le GNU/linux avec le module IBCS ?
Oui, ils peuvent l'être, moyennant un effort. GNU/Hurd fournit une couche de compatibilité POSIX dans la GNU C Library, dans une certaine mesure il fournit aussi une compatibilité plus spécifiquement Linux et avec le port Linux de la GNU C Library, bien qu'à l'origine, il ait plus tendance à se rapprocher de BSD au niveau de ses interfaces - origines de Mach obligent, on retrouve les slices, la gestion des interruptions (niveaux de priorités, soft interrupts en « couches », ...). Il suffirait de presque rien, peut-être quelques symboles de plus, pour que te je dise : il y'a compatibilité binaire. (comment ça, c'est mauvais ?! :-). Cependant, je ne pense pas que ce soit une priorité, pour moi comme pour tous les développeurs de GNU/Hurd. Il me semble que la compatibilité sources devrait être assez, et qu'une compatibilité binaire ne peut engendre qu'une série de problèmes qui n'ont que peu d'intérêts. Ah, à moins que vous vouliez parler de logiciels propriétaires .. auquel cas vous oubliez qu'on parle ici du système GNU, l'officiel, le seul système d'ailleurs (« There is no system but GNU »), et que la possibilité du propriétaire ne rentrera aucunement dans nos priorités.
[^] # Re: GNU/Hurd vs GNU/Linux ?
Posté par Manuel Menal . En réponse à la dépêche Le Hurd bientôt au niveau de l'Everest !. Évalué à 10.
Oui, définitivement, oui. Tu dois remarquer toi-même, dans ta phrase, une contradiction flagrante : tu parles de module noyau. Tu es bien conscient que ces modules n'ont aucune autonomie, et qu'il s'agit juste de bouts de code qui seront ajoutés ou enlevés dynamiquement - c'est le principe des LKM. Ces bouts de code, une fois intégrés, font partie du noyau au même titre que ceux qui n'auront pas été chargés dynamiquement. Alors, le noyau n'est plus un gestionnaire de modules externes, puisqu'il comporte les parties qui étaient dans les modules. La modularité qu'implique l'utilisation de LKMs - très intéressante, cependant - n'est qu'une astuce pratique pour facilité la vie des utilisateurs : elle ne constitue en aucun cas une modularité de design, en aucun cas une modularité « logique » : si tu dois faire un schéma des différentes fonctions de l'OS, et par qui elles sont assurées, tu devras toujours faire un schéma avec un énorme (puisqu'il contiendra plein de cases avec ce qu'il fait, donc pas au sens de l'espace disque) noyal au milieu : un noyal monolithique.
Il faut bien aussi voir que s'il est difficile de discriminer parfaitement un micro-noyau d'un noyau monolithique, c'est parce qu'il s'agit également d'une question d'esprit, d'évolution, de volonté dans la conception du noyau, et pas seulement qu'une question des fonctionnalités que l'on peut avoir en espace utilisateur et superviseur (et en aucun cas, une question de taille). Mach, par exemple, bien que fournissant la majeure partie de son VMM en kernel space (toute la partie concernant la décision de quelles pages est swapped ou swapped in se trouve dans le noyau), fournit un certain mouvement vers l'espace utilisateur en fournissant le principe de memory objects et de backing store, délégant la responsabilité du choix du traitement de ces pages swapped out à un pager (page fault handler), qui sera chargé de les restituer quand y'en aura besoin (en cas de page fault). C'est, en fait, sur ce principe que sont implémentés les systèmes de fichier en espace utilisateur - et on imagine l'avantage qu'une telle approche fournit par rapport à des systèmes distribués, avec une mémoire distribuée, par exemple. Ces innovations, cette optique, plus le fait qu'une grande partie soit déjà délocalisée, en fait vraiment un micro-noyau. Ce qu'on ne peut pas dire de Linux. Linux, lui, a pour optique, de l'avis même de Linus Torvalds, une optique qui n'est pas celle du design, mais celle d'un pragmatisme technique. Ainsi, le cas de la VMM est intéressant : si l'on prend par exemple la VM rmap, on ne peut dire qu'elle n'est pas designée : elle est réfléchie, pensée, structurée, articulé autour d'un principe de reverse-mapping qui se justifie totalement, et le fait est que techniquement, c'est, à mon avis, une excellente VM.
En revanche, a-t-elle un vrai design de structure ? De la même façon que Linux, je ne le pense pas : il s'agit simplement d'une entité monolithique, ou tout est ensemble, les fonctions pas ou peu séparées logiquement, juste un programme, comme ça. Le cas de Mach évoqué ci-dessus montre un réel effort de design, puisqu'il y'a une séparation logique entre le "Who?" et le "Where?", permettant déjà une modularité et une adaptabilité qui change la vie. Voilà, ce que veut dire la modularité, et le design du Hurd. C'est encore plus vrai dans le cas de la VMM qui a été concue pour le Hurd sur L4[0].
Peut on encore parler de noyau monolithique à partir du moment où le plantage d'un module n'entraine pas l'arret complet du système ?
Euuuuh, ce ne serait plus des modules, mais des entités séparées. Ce qui n'est pas le cas actuellement. Je le dis et le répète : ce qui change dans un module, c'est la façon d'arriver dans le kernel, et le fait qu'on puisse le virer puis le remettre dynamiquement. C'est uniquement une facilité technique. Ils ont donc exactement les mêmes droits que ceux qui sont déjà dans le noyau. Ils peuvent provoquer l'arrêt complet du système, le plantage complet du noyau. Pensons par exemple aux drivers (libres) du winmodem du portable de Kilobug qui plantent quand on joue un ogg en se connectant :-)
La multiplication des systèmes d'exploitation "libres" (xBSD, Linux, Hurd), et je ne parle pas des multiples distributions linux ou version xBSD, ne risque t-il pas d'amener un peu plus de confusion chez les utilsateurs des dits systèmes, alors qu'une certaine cohésion commence (enfin) à se faire jour autour de GNU/Linux ?
C'est réellement une fausse question. Le problème est, il faut que les utilisateurs aient une vue d'ensemble assez globale du paysage disponible. Celà ne veut pas dire, des préjugés à deux balles qu'ils répandent sur les newsgroups du genre « Nunux c'est pour les débutants, ensuite c'est BSD pour les vrais proZ, etc. ». Ça veut dire avoir quelques éléments de base théorique, qui vont permettre de dire « Bon, voilà, les deux sont des trucs qui sont de la même famille, compatibles, y'a les mêmes logiciels dessus, c'est donc ce qui est très bas niveau qui change, genre tout ce qui va concerner le matos, etc. ». Ça va pas très loin, ça nécessite pas grand chose, mais ce serait heureux qu'un utilisateur basique sache un minimum d'informatique. Comment ça, utopiste ? (:
Si l'on ne parle pas d'opposition, alors j'ai un peu de mal à comprendre la complémentarité entre les deux systèmes. Existe t-il un système "libre" plus performant que l'autre (vitesse, éxécution des programmes, gestion de la MC, gestion des périphériques), de telle manière que le système le plus rapide pourrait servir pour "des expérimentations" et l'autre pour une production en entreprise ?
Si l'on ne parle pas d'opposition, c'est plus pour éviter le sous-entendu de rejet mutuel et de non communication entre les deux mondes. Linux, de par son excellence technique, a beaucoup à nous apprendre. Le Hurd pourrait apprendre pas mal de choses aux développeurs Linux. Pour l'instant, il n'y a pas « compétition » : les développeurs de GNU/Hurd utilisent GNU/Linux pour travailler, et l'un sert à l'autre. Il sert aussi à l'autre dans la mesure où il permet la promotion du libre, et le développement de logiciels libres, qui marcheront ensuite sous GNU/Hurd. Cependant, il ne faut pas se leurrer : GNU/Linux et GNU/Hurd se veulent des systèmes adaptables à à peu près toutes les possibilités - GNU/Hurd surtout, bien entendu ;-) Ils s'adressent donc au même public : tous ! Ensuite, le minoritaire pourra être utilisé pour des tâches où les avantages de l'autre ne comptent pas vraiment - changer le coeur d'un OS change beaucoup de choses, mais il ne peut pas tout.
Cette dernière question est la suite logique de la troisième, à savoir : Ces deux systèmes (diamétralement) opposées dans leur conception de base, peuvent ils etre compatibles au niveau des binaires, comme cela existe avec les Unix commerciaux et le GNU/linux avec le module IBCS ?
Oui, ils peuvent l'être, moyennant un effort. GNU/Hurd fournit une couche de compatibilité POSIX dans la GNU C Library, dans une certaine mesure il fournit aussi une compatibilité plus spécifiquement Linux et avec le port Linux de la GNU C Library, bien qu'à l'origine, il ait plus tendance à se rapprocher de BSD au niveau de ses interfaces - origines de Mach obligent, on retrouve les slices, la gestion des interruptions (niveaux de priorités, soft interrupts en « couches », ...). Il suffirait de presque rien, peut-être quelques symboles de plus, pour que te je dise : il y'a compatibilité binaire. (comment ça, c'est mauvais ?! :-). Cependant, je ne pense pas que ce soit une priorité, pour moi comme pour tous les développeurs de GNU/Hurd. Il me semble que la compatibilité sources devrait être assez, et qu'une compatibilité binaire ne peut engendre qu'une série de problèmes qui n'ont que peu d'intérêts. Ah, à moins que vous vouliez parler de logiciels propriétaires .. auquel cas vous oubliez qu'on parle ici du système GNU, l'officiel, le seul système d'ailleurs (« There is no system but GNU »), et que la possibilité du propriétaire ne rentrera aucunement dans nos priorités.
[0]: http://web.walfield.org/papers/better-best-effort-20021026/(...)
[1]: