Traditionnellement dans les livres informatiques, un OS est décrit comme constitué de deux couches : la couche logiciel et la couche système. La couche système a essentiellement deux fonctions : offrir à la couche logiciel une machine virtuelle masquant les particularités de la couche matériel et assurer le partage, si possible optimal, des ressources de la machine. Tout ceci est en général représenté dans un schéma de ce type :
L'une des hypothèses de base des défendeurs du GNU/Hurd, c'est que cette architecture a fait son temps. Les fonctionnalités attendues par un système moderne demande une architecture plus complexe.
Le principal problème de l'architecture traditionnelle, c'est que l'OS, bien souvent développé sous forme d'un noyau monolithique, devient une composante logiciel de plus en plus grosse. On parle parfois de bloatware.
La solution apportée par la FSF dans le projet GNU et d'une part l'utilisation de micronoyau et d'autre part l'utilisation de multiple serveur. Dans ce cas la couche traditionnellement nommée OS est plus ou moins éclatée en deux partis: une partie offrant des services de bas niveau (gestion de la mémoire, des messages inter-processus, des interruptions etc.) et une partie offrant des services de plus haut niveau : authentification, démarrage d'un processus etc.
De plus comme une condition indispensable pour l'utilisation d'un nouveau système est sa compatibilité avec l'existant, il a été décidé d'utiliser la glibc pour assurer une compatibilité avec le standard POSIX.
L'architecture obtenue est celle decrite dans le schéma suivant :
Ce schéma a essentiellement été réalisé à partir de ces deux documents :
Passons maintenant en revu l'utilité de chaque partie.
Il assure la "plomberie" de base : gestion de la mémoire, des threads, des interruptions.
Actuellement, il assure aussi la gestion du matériel (drivers), mais plus pour très longtemps, très prochainement, cette partie sera remplacée par Oskit.
Je profite de ce paragraphe pour évoquer le projet dénomé Hurd/L4. Il consiste à redevelopper GNU/Hurd en le basant sur les micronoyaux L4. En effet les micronoyaux Mach commencent à sérieusement dater. Le projet Mach est officielement arrété (depuis 1997 ? à vérifier). La FSF a du donc reprendre à sont compte seul le développement des micronoyaux Mach qu'elle a pour l'occasion renommé GNUmach. Mais la FSF a des moyens de développement limités, donc en faite ces micronoyaux n'ont eu comme évolution que le strict nécessaire.
Pourtant les systèmes micronoyaux eux n'ont pas cesser d'évoluer. Notamment le projet dit "L4" (qui se nomme maintenant L5). Quelques développeurs ont proposé de remplacer les micronoyaux GNUmach par L4. Leur principal arguement est que le développement de L4 est toujours actifs. L'implémentation est plus propres, plus récente, plus performante.
Ceci sur le point de vu théorique ne devrait pas poser beaucoup de problème, il suffirait juste de réecrire les serveur Hurd vu qu'ils sont sensés être l'interface entre les applications et le système.
La pratique semble être un peu plus compliqué. Il semble que les développeurs d'Hurd on prit pas mal de liberté et on pas lié GNU/Hurd et GNUmach (on ne peut pas trop leur en vouloir, ce sont les même qui travail sur les deux parties).
Donc voici quelques arguments pour et contre ce portage:
L'équipe du GNU/Hurd ne voulait pas redévelopper tous les drivers pour tous les matériels existants. On les comprend, c'est très fastidieu comme travail. Leur première idée a été de repomper les drivers de Linux, version 2.0.x. Seulement les développeurs Linux sont très volatiles sur les API des drivers, ce qui n'arrange pas les développeurs du GNU/Hurd. Ainsi ils ne peuvent pas mettre à jours les drivers de GNUmach en recopiant les drivers des versions actuelles : 2.4.x. Heureusement, le projet OSKit est apparu entre-temps et il permet d'avoir des drivers sans trop de travail. Cette partie est en cours de développement.
Cette appellation est un peu trompeuse, car c'est des fois tous le système, d'autre fois uniquement les serveurs. Dans ce paragraphe, on appel GNU/Hurd la collection de serveur offrant des services de haut niveau. Tout ce qui est utile dans un OS, mais qui n'est pas dans GNUmach se trouve à ce niveau. Cela peut-être comparé aux deamons UNIX, mais les serveurs Hurd sont plus puissant. Na !
Voici la liste des serveurs GNU/Hurd :
Le petit monde du logiciel libre adore respecter les standards. il y en a un qui plus la cote que les autres : c'est le standard POSIX. Actuellement pour qu'une application tourne sur un grand nombre de platformes, il faut que cette application soit conforme au standard POSIX. Donc il fallait que le GNU/Hurd offre une compatibilité POSIX. Ce rôle à été dédié à la glibc.
Il est clair que la majorité des applications interragiront avec le système via la glibc. Ceci ne les empecheront pas de profiter des capacités du GNU/Hurd. Par exemple un application pourra ouvrir un fichier sans savoir que ce fichier aura été rappatrier via ftp.
Il y aura bien sur une petite catégorie de programme qui utiliseront directement les fonctionnalités du GNU/Hurd et pourquoi pas de GNUmach (même si cela est déconseillé [ à développer, cf Hurd/L4] ). Mais ceci sera surtout destiné au programme système (ps, reboot etc.)
GNU/Hurd apporte de nouveaux concepts du point de vu architecture d'un OS. Je lui souhaite de réussir. Mais il est certain qu'on verra un grand nombre de conservateur qui chercheront à tout prix à demontrer que la seul bonne manière de faire un OS est celle décrite dans le rappel initial.
Vous pouvez aussi rejoindre le rang des pessimistes développé par Rob Pike.