Existe-t-il des alternatives à l'utilisation de `udev` ?

Il existe différentes alternatives à udev là-bas. Apparemment Gentoo peut utiliser quelque chose appelé mdev . Une autre option serait d'essayer d'utiliser udev devfsd, prédécesseur de . Enfin, vous pouvez toujours créer tous les fichiers de périphérique dont vous avez besoin avec mknod .

Notez qu'avec cette dernière, il n'est pas nécessaire de tout créer au démarrage puisque les nœuds peuvent être créés sur disque et non dans un système de fichiers temporaire comme avec les autres options. Bien sûr, vous perdez la flexibilité d'avoir des fichiers de périphérique créés dynamiquement lorsqu'un nouveau matériel est branché (par exemple une clé USB). Je crois que l'approche standard à cette époque était d'avoir chaque fichier de périphérique dont vous pourriez raisonnablement avoir besoin déjà créé sous /dev (c'est-à-dire beaucoup de fichiers de périphérique).

Bien sûr, la difficulté à faire fonctionner l'une de ces approches dans une distribution moderne est probablement assez élevée. Le wiki Gentoo mentionne des difficultés à obtenir mdev pour travailler avec un environnement de bureau (et encore moins en dehors de Gentoo). Le dernier devfsd la version était de 2002, je n'ai aucune idée si cela fonctionnera même avec les noyaux modernes. Créer les nœuds manuellement est probablement l'approche la plus viable, mais même désactiver udev peut être un défi, en particulier dans les distos utilisant systemd (udev fait maintenant partie de systemd , ce qui suggère une forte dépendance).

Mon conseil est de rester avec udev;)

Les noyaux Linux modernes prennent en charge le devtmpfs système de fichiers , qui crée dynamiquement tous les nœuds de périphérique dès que le noyau les découvre. (En fait, le dernier udev les versions nécessitent cette; vous constaterez qu'udev ne crée plus de nœuds de périphérique, uniquement des liens symboliques.)

De même, le chargement du micrologiciel a également été déplacé dans le noyau, de sorte que les seules tâches restantes udev les performances sont le chargement du module (selon les modaliases) et l'application des autorisations de l'appareil et d'autres règles udev.

Donc, en théorie, un noyau entièrement monolithique devrait démarrer très bien sans udev.

Cependant, le vrai problème ici est ce qui se passe plus tard.

1. De nombreux programmes de l'espace utilisateur s'appuient sur udev pour maintenir sa base de données d'appareils, accessible via libudev . Bien que l'énumération des périphériques et l'écoute des événements ajoutés/supprimés puissent être effectuées directement à l'aide des interfaces du noyau (sysfs et netlink), vous vous retrouverez toujours sans toutes les métadonnées associées aux différentes règles udev.

2. Les règles udev maintiennent également divers liens symboliques "persistants" dans /dev/disk/by-* , /dev/mapper , /dev/input/by-path , /dev/snd/by-path , etc. Par exemple, si vous avez deux disques connectés, rien ne garantit que le premier sera toujours sda ou sdb , mais udev s'assure que les liens symboliques dans /dev/disk/by-uuid continuera à pointer vers la bonne.

3. Alors que les nœuds de périphérique sont maintenant créés par le noyau et ne vous concernent donc plus, il est toujours important de noter que certains types de périphériques ont commencé à utiliser des numéros majeurs/mineurs attribués dynamiquement, donc même si vous avez /dev/fuse comme 10 228 et /dev/hpet comme 10 229 aujourd'hui, ils vont ont des numéros différents après chaque redémarrage, donc soit devtmpfs ou (sur les anciens systèmes) un programme qui écoute les uevents est requis .

Beaucoup de ces choses pourraient facilement être faites par d'autres programmes tels que mdev , bien sûr. Mon point est qu'un /etc/MAKEDEV statique le script ne fonctionnera plus...

Donc, fondamentalement, en ce qui concerne la complexité du démarrage, udev est probablement le le moins de vos préoccupations.

Il existe plusieurs alternatives :

• Ayez simplement un ensemble de chmod approprié , chown , ln , et des commandes similaires dans un script exécuté dans le cadre du bootstrap.
• Utilisez systemd-udev , le gestionnaire plug-and-play qui fait partie du projet systemd.
• Utiliser le eudev de Gentoo , qui est un fork de systemd-udev dont systemd a maintenant considérablement divergé.
• Utiliser le vdev de Devuan , qui est un gestionnaire plug-and-play développé par Jude Nelson, qui fait partie de Devuan.
• Utilisez mdev , qui contrairement à une autre réponse n'est pas une chose Gentoo. C'est le gestionnaire plug-and-play intégré à BusyBox.
• Utiliser Suckless mdev qui est un gestionnaire plug-and-play développé par Dimitris Papastamos.
• Utiliser le mdevd de Laurent Bercot , dont la configuration est compatible avec le mdev de BusyBox mais fait sa propre gestion des sockets et ne comprend pas le protocole LISTEN.

Tous ces éléments, à l'exception du premier, nécessitent des ensembles de règles décrivant comment réagir aux événements de notification du noyau concernant les périphériques. Évidemment.

Il existe également des outils qui prendront des programmes conçus pour /proc/sys/kernel/hotplug , comme les deux mdev s, et qui les adaptera et les sérialisera en écoutant un socket netlink puis en engendrant ces programmes :

• L'ancien s6-netlink-listener de Laurent Bercot et s6-uevent-spawner
• netlink-datagram-socket-listen et plug-and-play-event-handler de l'ensemble d'outils nosh