Je pensais avoir été assez explicite, mais peut-être y a-t-il des précisions supplémentaires à apporter.
L'idée du passage à L4 n'était pas juste de remplacer Mach par L4. D'abord, parce que L4 et Mach ne sont pas comparables : tout ce qui est implémenté dans Mach (la gestion de la mémoire, par exemple) ne l'est pas dans L4, qui fournit des fonctionnalités extrêmement minimales. Il s'agissait donc de réécrire, avec une nouvelle conception, des fonctions essentielles du noyau.
En travaillant sur le port du Hurd sur L4, Neal Walfield et Marcus Brinkmann, notamment, ont mis en évidence des problèmes et des limites du Hurd et de Mach. C'est ce qu'ils présentent dans la critique (voir plus haut). Ils ont proposé des idées pour une nouvelle architecture qui tente de résoudre ces problèmes, dépassant le Hurd actuel (cf. le second papier plus haut).
C'est ce sur quoi Neal Walfield a commencé à travailler dans Viengoos. Tout ça est du travail expérimental : on est dans le domaine de la recherche, pas juste de l'implémentation. Il y a des idées très intéressantes, mais ça n'est pas exactement fonctionnel, et ça n'a pas vocation à l'être dans le proche futur.
L'intérêt d'un port du Hurd, dans sa conception actuelle, sur L4, n'est pas évident — et pas simple, d'ailleurs, les interfaces fournies par L4 étant assez différentes de celles de Mach. Le choix de la plupart des développeurs a été de continuer à travailler sur le Hurd sur Mach — quitte à reprendre des éléments qui viennent du monde L4, comme DDE (pilotes en espace utilisateur).
Il est possible qu'à terme, un autre micro-noyau que GNU Mach soit utilisé — ou que GNU Mach soit simplement modifié. C'est un choix opérationnel (qu'est-ce qui est le plus efficace par rapport à nos objectifs ?).
[^] # Re: Enfin des news
Posté par Manuel Menal . En réponse à la dépêche L'année 2010 du Hurd. Évalué à 6.
L'idée du passage à L4 n'était pas juste de remplacer Mach par L4. D'abord, parce que L4 et Mach ne sont pas comparables : tout ce qui est implémenté dans Mach (la gestion de la mémoire, par exemple) ne l'est pas dans L4, qui fournit des fonctionnalités extrêmement minimales. Il s'agissait donc de réécrire, avec une nouvelle conception, des fonctions essentielles du noyau.
En travaillant sur le port du Hurd sur L4, Neal Walfield et Marcus Brinkmann, notamment, ont mis en évidence des problèmes et des limites du Hurd et de Mach. C'est ce qu'ils présentent dans la critique (voir plus haut). Ils ont proposé des idées pour une nouvelle architecture qui tente de résoudre ces problèmes, dépassant le Hurd actuel (cf. le second papier plus haut).
C'est ce sur quoi Neal Walfield a commencé à travailler dans Viengoos. Tout ça est du travail expérimental : on est dans le domaine de la recherche, pas juste de l'implémentation. Il y a des idées très intéressantes, mais ça n'est pas exactement fonctionnel, et ça n'a pas vocation à l'être dans le proche futur.
L'intérêt d'un port du Hurd, dans sa conception actuelle, sur L4, n'est pas évident — et pas simple, d'ailleurs, les interfaces fournies par L4 étant assez différentes de celles de Mach. Le choix de la plupart des développeurs a été de continuer à travailler sur le Hurd sur Mach — quitte à reprendre des éléments qui viennent du monde L4, comme DDE (pilotes en espace utilisateur).
Il est possible qu'à terme, un autre micro-noyau que GNU Mach soit utilisé — ou que GNU Mach soit simplement modifié. C'est un choix opérationnel (qu'est-ce qui est le plus efficace par rapport à nos objectifs ?).
La FAQ traite d'ailleurs de ce point : http://www.gnu.org/software/hurd/hurd/faq/which_microkernel.(...)