URL: https://linuxfr.org/news/le-point-sur-udev-et-systemd Title: Le point sur udev et systemd Authors: Anonyme Davy Defaud, B16F4RV4RD1N, patrick_g, Nÿco et Benoît Date: 2012年09月05日T09:30:17+02:00 License: CC By-SA Tags: systemd, fedora, opensuse, lennart_poettering et mageia Score: 48 L’annonce est passée inaperçue, mais _udev_ est intégré depuis avril 2012 dans les sources de _systemd_. Les deux projets sont amenés à fusionner. Désormais, c’est _systemd_ qui fournit le logiciel _udev_. Ce dernier est toujours utilisable indépendamment, mais son avenir est fixé. Les récentes déclarations de Lennart Poettering ont provoqué une salve de critique et même un _fork_ de _udev_. D’après Wikipédia, [_udev_](http://fr.wikipedia.org/wiki/Udev) est « un gestionnaire de périphériques remplaçant _devfs_ sur les noyaux Linux de la série 2.6. Sa fonction principale est de gérer les périphériques dans le répertoire `/dev`. _udev_ s’exécute en mode utilisateur et dialogue avec _hotplug_ qui, lui, s’exécute en mode noyau. » Toujours d’après Wikipédia, [_systemd_](http://fr.wikipedia.org/wiki/Systemd) est « un remplaçant du démon _init system V_ pour Linux. Il a pour but d’offrir une meilleure infrastructure pour la gestion des dépendances entre services, de permettre le chargement en parallèle des services au démarrage, et de réduire la surcharge du _shell_. _systemd_ est un projet initié par Lennart Poettering en 2010 et publié sous licence GNU LGPL en version 2.1. Le nom de ce programme vient de _« system daemon »_ : le [_daemon_](http://fr.wikipedia.org/wiki/Daemon_%28informatique%29) du système et fait aussi référence au _"système D"_. » ---- [Annonce sur de l’intégration de udev dans systemd linux-hotplug](http://article.gmane.org/gmane.linux.hotplug.devel/17392) [Journal de Sygne sur LFS et systemd](http://supervisord.org/) [Journal de neil sur le fork de udev](http://linuxfr.org/users/neil--2/journaux/udev-forke) [Dépôt du fork de udev](https://bitbucket.org/braindamaged/udev) [Évolutions techniques de systemd (dépêche de novembre 2011 sur LinuxFr)](http://linuxfr.org/news/%C3%A9volutions-techniques-de-systemd) ---- L’intégration de _udev_ surprend beaucoup, car il est un élément central et quasi universel des distributions GNU/Linux. Vue l’importance de l’affect dans les discussions sur _systemd_, cela vaut la peine de présenter _systemd_ tel qu’il se présente lui‐même. La partie suivante est tirée des [différents](http://0pointer.de/blog/projects/systemd.html) [articles](http://0pointer.de/blog/projects/systemd-update.html) [de](http://0pointer.de/blog/projects/systemd-update-2.html) [vulgarisation](http://0pointer.de/blog/projects/systemd-update-3.html) rédigés par Lennart Poettering. # Objectifs de systemd _systemd_ est le PID 1. C’est‐à‐dire le premier processus lancé par le noyau, dont l’objectif est de « démarrer l’espace utilisateur ». Historiquement, le PID 1 est [_init_](http://fr.wikipedia.org/wiki/_init_ "Définition Wikipédia") de _Système V_ qui se contente de lancer séquentiellement une liste déterminée de programmes. Contrairement à [_upstart_](http://fr.wikipedia.org/wiki/_upstart_ "Définition Wikipédia"), _systemd_ n’a pas été pensé comme un remplaçant d’_init_, mais plutôt comme une solution à une problématique renouvelée par l’état actuel de l’informatique. Dès les [débuts de _systemd_](http://0pointer.de/blog/projects/systemd.html), le cadre posé est : _comment démarrer l’espace utilisateur de manière rapide et efficace dans un système changeant ?_ # Les événements, tous les événements La question n’est plus tellement lancer des scripts au démarrage, mais : lancer, arrêter, relancer des logiciels pour répondre à des événements logiciels ou matériels, depuis le démarrage jusqu’à l’arrêt du système. Ces événements ce sont : le démarrage lui‐même, le montage d’un volume, la connexion à un port ou une [_socket_](http://fr.wikipedia.org/wiki/Berkeley_sockets), l’heure actuelle, l’interrogation d’une interface [D-Bus](http://fr.wikipedia.org/wiki/D-Bus "Définition Wikipédia"), la connexion/déconnexion d’un utilisateur, mais aussi l’ajout ou le retrait d’un périphérique à chaud ou à froid. Par exemple, au lieu d’attendre que tous les volumes de `/etc/fstab` soient montés (et contrôlés avec `fsck` si besoin), on monte le système de fichiers uniquement lorsqu’un service y accède. À l’instar d’[_autofs_](http://www.autofs.org/), _systemd_ intercepte les appels à `open` pour déclencher le montage d’un volume à la demande. Ou encore, _systemd_ écoute lui‐même sur le _socket_, pour ne lancer le service réel qu’à la première requête client. C’est ce que fait déjà _inetd_. En somme, _systemd_ factorise une mécanique de lancement d’un service suite à un événement. Cette mécanique était souvent déjà implémentée dans divers logiciels existants : _(x)inetd_, _upstart_, _autofs_, _cron_, _udev_, mais aussi [_supervisord_](http://supervisord.org/) et d’autres. _systemd_ unifie une problématique commune autour d’une seule solution. # La position des distributions Outre Fedora qui adopte la solution de son poulain depuis [Fedora 15](https://fedoraproject.org/wiki/Features/systemd), _systemd_ semble bien accueilli par les distributions. Mandriva, Mageia, OpenSUSE, [FrugalWare](https://wiki.frugalware.org/index.php/SystemD) et Arch Linux sont également passées à _systemd_. La question est plutôt : « Qui n’est pas passé à systemd ? » En premier lieu, Debian, qui se pose sérieusement la question, mais avec calme. Mais surtout LFS et Gentoo, qui affichent plutôt un refus de _systemd_. # Pourquoi intégrer udev ? _systemd_ est un _init_ _« hotplug »_. Pour cela, il réutilise le code de `udev` gérant l’interaction avec `hotplug`. La logique de gestion du cycle de vie d’un périphérique est intégrée dans _systemd_. Or, _udev_ est un service lancé par _systemd_. Cela créait des problèmes de dépendances circulaires à la compilation et des allers‐retours incessants entre les deux services à l’exécution. # Situation de udev et systemd _systemd_ poursuit la numérotation de version de _udev_, en passant de la version 45 à la version 184. _udev_ est toujours utilisable indépendamment de _systemd_, mais son développement est minimal. D’où la fameuse [phrase de Lennart](http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html) :> _Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven’t noticed it yet. I am looking forward to the day when we can drop that support entirely._ Ce qui signifie, dans la langue de Molière :> Oui, _udev_ sur les systèmes non _systemd_ est à nos yeux une impasse, au cas où vous ne l’auriez pas encore remarqué. J’attends le jour où nous pourrons complètement abandonner cette prise en charge. De quoi échauder plus d’un utilisateur attaché à _udev_. Comme certains l’étaient sans doute du vénérable [_devfs_](http://fr.wikipedia.org/wiki/_devfs_ "Définition Wikipédia"). # Le fork de udev [LFS](http://fr.wikipedia.org/wiki/Linux_From_Scratch) n’est pas satisfait de l’intégration de _udev_ dans _systemd_. En effet, pour compiler uniquement _udev_, on doit télécharger tout _systemd_ et ses dépendances. Un problème de système de compilation résolu par LFS avec un _patch_ ajoutant une option `UDEV_ONLY`. Finalement, un _fork_ complet de _udev_ a été réalisé à partir de la version 189 de _systemd_. L’objectif est uniquement de sortir _udev_ des sources de _systemd_. On peut le voir sur la page GitHub de `braindamaged`. # Conclusion Ce _fork_ a peu d’importance en soi. Il montre une certaine exaspération devant le manque d’intérêt des développeurs de _systemd_ à faciliter la vie des utilisateurs conservateurs.

AltStyle によって変換されたページ (->オリジナル) /