Plan 9 est un système d’exploitation développé à Bell Labs depuis le milieu des années 80, qui est construit en développant encore plus les principes d’unix.

P.S.: Image de couverture de l’article obtenue ici: https://en.wikipedia.org/wiki/File:Spaceglenda.svg

Dans cet article, je compte vous donner une rapide introduction aux principes de Plan 9, et un peu du potentiel qu’ils représentent. Gardez tout de même à l’esprit que je n’ai jamais utilisé Plan 9 (j’ai seulement lu la documentation), et que, l’ensemble des pages man faisant plus de 1000 pages en pdf, je ne pourrai évidemment pas être exhaustive.

Les devices et namespaces:

Comme vous le savez peut-être, sous unix, on dit que tout est un fichier. Mais, pour être plus précise, on devrait plutôt dire que tout est un flux de charactères avec un descripteur de fichier. De fait, un fichier est souvent décrit par un élément de plus: son/ses nom·s.

Sous Plan 9, la majorité des services du système sont fournis via une interface exposée dans les système de fichier de la machine. Chacun de ces services, qui peuvent être implémentés comme des programmes utilisateurs, s’appelle une device. Par exemple, il y en a qui implémentent différents systèmes de fichiers, comme fat ou ext2. Mais, il y en a beaucoup d’autres, comme celui qui gère l’interface graphique, celui qui gère le son, un qui permet d’accèder au contenu d’une archive de manière transparente, et même celui qui permet d’accèder à des pages web.

De plus, chaque groupe de processus a une vue (que l’on appelle son namespace) un peu différente du système de fichier, souvent assez similaire, mais pas toujours. En effet, quand une device est montée à un endroit du système, cette modification ne s’applique que pour le groupe de processus qui la monte. Celà permet, par exemple, de ne pas avoir de concept de PATH: tous les exécutables sont dans /bin, mais le contenu de /bin peut varier selon l’utilisateur·ice: il suffit de monter les dossiers que l’on veut par dessus pour rajouter des exécutables personels (on peut monter plusieurs dossiers au même endroit, ils seront fouillés dans l’ordre pour trouver le fichier que l’on cherche).

Avant toute chose, notons que Plan 9 permet de facilement monter un système de fichier à distance. Celà permet d’accèder à des fichiers distants comme s’ils étaient localement sur notre machine, mais également, pour toutes les devices qui contrôlent la machine (comme audio, cons, draw (et 8¹/₂), webfs), celà permet de les exécuter à distance, mais qu’ils affectent quand même la machine locale.

Explorons quelques exemples de devices:

  • audio, généralement monté sur /dev, fournit deux fichiers:
    • ./audio, dans lequel on écrit des samples qui seront joués par les hauts-parleurs, et duquel on peut lire les samples enregistrés par le microphone.
    • ./volume, qui contrôle bien sûr le volume du haut-parleur et du microphone.
  • cons, généralement monté sur /dev, fournit beaucoup de fichiers, qui servent à utiliser et contrôler l’interface textuelle du système. Par exemple,
    • ./cons, qui correspond à l’entrée et la sortie textuelle de la console.
    • ./consctl contrôle la console, par exemple en activant ou désactivant le mode brut d’entrée de caractères.
  • draw, de manière similaire, implémente l’interface graphique du système. Elle fournit beaucoup de fichiers, que je ne détaillerai pas ici. Cependant, notons qu’elle n’est pas un système de fenêtrage, mais une représentation simple d’un écran.
  • 8¹/₂ est un système de fenêtrage de Plan 9. Il a la particularité d’avoir exactement la même interface de fichiers que draw. En effet, l’unique rôle de 8¹/₂ est de fournir l’accès à draw à plusieurs programmes simultanément, et de transmettre leurs commandes à l’affichage global. Cette architecture à des avantages notables:
    • Comme 8¹/₂ fournit la même interface que draw, n’importe quel programme qui opère sur tout l’écran peut être utilisé dans une fenêtre, et inversement, sans modification de son code.
    • Et, surtout, ceci s’applique aussi à 8¹/₂: il est possible d’utiliser 8¹/₂ dans une fenêtre, ce qui permet de facilement le développer, en exécutant la nouvelle version dans une fenêtre de la version actuelle.
    • Elle est assez simple à implémenter, et respecte la philosophie unix puisqu’elle ne fait qu’une seule chose: multiplexer les commandes graphiques.
    • Comme précisé précédemment, cette interface permet aussi de facilement interagir avec des processus sur d’autres machines, puisqu’il suffit de monter les fichiers de l’interface sur la machine externe avant de lancer un programme graphique, et il s’exécutera comme un programme qui serait présent sur la notre.
  • ext2srv, beaucoup plus classique, fournit simplement une implémentation du système de fichier ext2. Mais, son avantage est bien sûr qu’elle est écrite comme un programme classique, pas un driver, ce qui la rend bien plus simple à modifier et débugger.
  • webfs, bien sûr, fournit un système qui implémente les protocoles du web pour permettre d’accèder à des pages web dans le système de fichier. Les navigateurs n’ont ainsi qu’à utiliser webfs, et n’ont pas à implémenter l’interprétation d’URLs, ou les différents protocoles, ce qui permet de les rendre “plus faciles” à implémenter.

C’est le sujet principal que je voulais aborder, car c’est celui qui m’inspire le plus dès que je réfléchis au design de systèmes d’exploitation, ce qui est un sujet qui m’intéresse beaucoup. Mais, c’est loin d’être le seul aspect intéressant de Plan 9. Donc, pour la suite et fin de cet article…

Un petit florilège désorganisé d’aspects intéressants de Plan 9:

Plan 9 est un des premiers systèmes avec une résolution lexicale des noms de fichiers, c’est à dire que faire cd a/b puis cd ../.. nous ramène dans le dossier dans lequel on était, même si on a suivi des liens symboliques (ou plutôt des bind mounts dans le cas de Plan 9, puisque les liens symboliques n’y existent pas, mais que les bind mounts permettent quand même de faire des liens d’un bout à l’autre du système de fichier).

Plan 9 étend aussi la plupart des valeurs numériques dans unix, notamment les valeurs de sortie des programmes, et les signaux. Dans les deux cas, ils sont remplacés par des chaines de caractères. Par exemple, pour tuer un processus, au lieu de lui envoyer le signal 9, on lui envoit le signal “kill”, ce qui est beaucoup plus clair, et permet d’avoir des signaux spécifiques aux programmes, autres que juste SIGUSR1 et SIGUSR2 dans unix. Pour le résultat des programmes, une chaine vide est considérée comme une réussite, et toute autre chaîne est un message d’erreur. Celà permet de faire des erreurs de programmes bien plus descriptives qu’un simple nombre.

Enfin, c’est un autre système de fichiers que je n’ai pas eu le temps d’évoquer en détail, mais plumber est un système de messages interprétés de manière configurable et transmits à différents logiciels. Par exemple, les éditeurs de texte attendent le message “edit”. On peut configurer plumber pour que, quand il reçoit le texte <fichier>:<ligne>[:<colonne>], il transmette ce message en tant qu’edit. Ainsi, dès qu’on a besoin d’ouvrir un fichier, comme par exemple en lisant les erreurs du compilateur, il suffit de sélectionner la localisation et d’envoyer le message, et l’éditeur s’ouvrira automatiquement. Ça marche aussi pour les URLs, les images, ou tout autre système puisque c’est configurable par l’utilisateur·ice.

Enfin voilà, j’espère vous avoir donné un petit goût de Plan 9, et que vous aurez trouvé ce dernier article (et surtout Plan 9) intéressant.

Bises, et à bientôt, Amélia Coutard-Sander.