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

Bien que je comprenne la grandeur d'udev et apprécie l'effort des développeurs, je me demandais simplement s'il y avait une alternative.

Par exemple, je pourrais imaginer qu'il devrait y avoir un moyen de créer un script de démarrage qui crée la plupart des nœuds de périphérique qui sur mon système (pas de changement de matériel) sont de toute façon les mêmes.

L'avantage ou la raison pour laquelle je voudrais ignorer udevserait le même que pour sauter dbus, à savoir réduire la complexité et augmenter ainsi mes modifications pour configurer le système de manière plus sûre.

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

Notez qu'avec ce dernier, il n'est pas nécessaire de tout créer au démarrage car 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 consistait à créer tous les fichiers de périphérique dont vous pourriez raisonnablement avoir besoin /dev(c'est-à-dire beaucoup de fichiers de périphérique).

Bien sûr, la difficulté d'obtenir une de ces approches pour travailler dans une distribution moderne est probablement assez élevée. Le wiki Gentoo mentionne des difficultés mdevà travailler avec un environnement de bureau (sans parler de l'extérieur de Gentoo). La dernière devfsdversion date de 2002, je ne sais pas du tout si cela fonctionnera avec les noyaux modernes. La création manuelle des nœuds est probablement l'approche la plus viable, mais même la désactivation udevpourrait être un défi, en particulier dans les distos utilisant systemd( udevfait désormais partie de systemd, ce qui suggère une forte dépendance).

Mon conseil est fidèle udev;)

Les noyaux Linux modernes prennent en charge le devtmpfssystème de fichiers ^{(ne pas confondre avec les anciens devfs)} , qui crée tous les nœuds de périphérique dynamiquement dès que le noyau les découvre. (En fait, les dernières udevversions l' exigent ; vous constaterez que udev ne crée plus de nœuds de périphérique, seulement des liens symboliques.)

De même, le chargement du firmware a également été déplacé dans le noyau, de sorte que les seules tâches restantes à udeveffectuer sont le chargement du module (selon les modalias) et l'application des autorisations de périphérique 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. Un certain nombre de programmes de l'espace utilisateur comptent 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 se faire directement en utilisant les interfaces du noyau (sysfs et netlink), vous resterez toujours sans toutes les métadonnées que diverses règles udev ont attachées.

2. règles udev maintiennent également divers liens symboliques « persistants » dans /dev/disk/by-*, /dev/mapper, /dev/input/by-path, /dev/snd/by-pathet ainsi de suite. Par exemple, si vous avez deux disques connectés, rien ne garantit que le premier sera toujours sdaou sdb, mais udev s'assure que les liens symboliques vers /dev/disk/by-uuidcontinueront à pointer vers le bon.

3. Alors que les nœuds périphériques sont maintenant créés par le noyau et donc pas votre préoccupation plus, il est toujours important de noter que certains types d'appareils ont commencé à utiliser des numéros majeurs / mineures attribuées de manière dynamique, de sorte que même si vous avez /dev/fusecomme 10228 et /dev/hpetcomme 10229 aujourd'hui, ils seront avoir des numéros différents après chaque redémarrage, donc soit devtmpfsou (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 comme mdev, bien sûr. Mon point est qu'un /etc/MAKEDEVscript statique ne fonctionnera plus ...

Donc, fondamentalement, en ce qui concerne la complexité de démarrage, udev est probablement le moindre de vos soucis.

Il existe plusieurs alternatives:

• Avoir simplement un ensemble de appropriées chmod, chown, ln, et les commandes de suchlike dans un script qui est exécuté dans le cadre du bootstrap.
• Utilisez systemd-udev, le gestionnaire plug-and-play qui fait partie du projet systemd.
• Utilisez Gentooeudev , qui est une fourchette systemd-udevdont systemd a maintenant considérablement divergé.
• Utilisez Devuanvdev , 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 .
• Utilisez Sucklessmdev qui est un gestionnaire plug-and-play développé par Dimitris Papastamos.
• Utilisez celle de Laurent Bercotmdevd , qui est compatible avec la configuration de BusyBox mdevmais qui gère son propre socket 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, tels que les deux mdevs, et qui les adapteront et les sérialiseront en écoutant une socket netlink puis en générant ces programmes:

• Laurent Bercot, vieux s6-netlink-listenerets6-uevent-spawner
• netlink-datagram-socket-listen et à plug-and-play-event-handlerpartir de l'ensemble d'outils Nosh

udev? La meilleure alternative est de ne pas l'utiliser. Et en apprenant à ne pas l'utiliser, Linux et le monde * NIX commenceront à avoir un sens plus logique.

La meilleure alternative à long terme consiste à utiliser des appareils statiques (voir note). Si vous avez le pilote, le noyau Linux gère le branchement à chaud. Je préfère ne jamais faire fonctionner udevd.

dbus est une autre affaire. Cela ralentit votre système, mais le monde en constante évolution des scripteurs adore ça. Donc, beaucoup de choses auxquelles vous êtes habitué, comme les navigateurs Web ou les applications avec des backends de script, doivent être corrigées (lancées ou reconstruites sans ce genre de choses ou vidées pour une autre application).

Remarque: Si vous connectez simplement un lecteur flash ou un périphérique dvd, utilisez dmesg|tailpour voir le nom du périphérique à monter. Apprendre lorsqu'un périphérique est un périphérique de type caractère ou bloc est une connaissance fondamentale du système dans le monde du matériel informatique. Sous Linux, c'est open source, vérifiez-en beaucoup sur Linux, et pas seulement sur le système embarqué . C'est le meilleur pour une compréhension plus large de la logique directe (pas de la philosophie) de tous les NIX *, comme Linux (Solaris, HPUX, AIX, etc.).

Udev, dbus, gconf / dconf, systemd, gnome-shell, Gnome, Glib, mono et Fedora sont destinés aux personnes ayant beaucoup de temps à disposition qui ne peuvent pas RTFM, ou qui souhaitent une mise à jour automatique vraiment lisse (à la recherche) mais, plus lente que la mélasse, buggy, Linux à mi-chemin. (Un endroit vraiment horrible, parcourez le Web pour des tonnes d'expériences similaires).

Le système démarre puis exécute udevd. Mais, il est affirmé que udev est nécessaire car, les numéros mineurs de l'appareil will changeau redémarrage. La raison d'être d'Udev semble se contredire à chaque instant. Et où se trouvent les fichiers semble toujours faux, peu importe qui vous consultez. Ne faites pas confiance ou freedesktop.org.

Outre udev est absorbé par cette horreur connue sous le nom de systemd, je ne sais pas ce que l'on fait alors avec les fichiers indésirables / etc / udev. Et, il est ridicule de dire qu'écrire des règles udev est en quelque sorte mieux que tout. Les gens gentoo semblent vouloir s'y accrocher et ne pas avoir à avoir systemd, ils l'ont donc envoyé à eudev.

Si vous voulez un système ridiculement rapide et sans surprise, utilisez les bases de Linux.