Es gibt verschiedene Alternativen zu udev
dort draußen. Scheinbar kann Gentoo etwas namens mdev
verwenden . Eine andere Möglichkeit wäre, zu versuchen, udev
zu verwenden Vorgänger devfsd
von . Schließlich können Sie mit mknod
immer alle benötigten Gerätedateien erstellen .
Beachten Sie, dass bei letzterem nicht alles beim Booten erstellt werden muss, da die Knoten auf der Festplatte und nicht wie bei den anderen Optionen in einem temporären Dateisystem erstellt werden können. Natürlich verliert man die Flexibilität, dynamisch erstellte Gerätedateien zu haben, wenn man neue Hardware einsteckt (z. B. einen USB-Stick). Ich glaube, dass der Standardansatz in dieser Ära darin bestand, jede Gerätedatei, die Sie vernünftigerweise benötigen könnten, bereits unter /dev
erstellt zu haben (dh viele Gerätedateien).
Natürlich ist die Schwierigkeit, einen dieser Ansätze in einer modernen Distribution zum Laufen zu bringen, wahrscheinlich ziemlich hoch. Das Gentoo-Wiki erwähnt Schwierigkeiten, mdev
zu bekommen um mit einer Desktop-Umgebung zu arbeiten (geschweige denn außerhalb von Gentoo). Die letzten devfsd
Release war 2002, ich habe keine Ahnung, ob es überhaupt mit modernen Kerneln funktionieren wird. Das manuelle Erstellen der Knoten ist wahrscheinlich der praktikabelste Ansatz, aber sogar das Deaktivieren von udev
könnte eine Herausforderung sein, besonders in Distos, die systemd
verwenden (udev
ist jetzt Teil von systemd
, was auf eine starke Abhängigkeit hindeutet).
Mein Rat ist, bei udev
zu bleiben;)
Moderne Linux-Kernel unterstützen den devtmpfs
Dateisystem , das alle Geräteknoten dynamisch erstellt, sobald der Kernel sie entdeckt. (Tatsächlich ist der neueste udev
Freigaben erfordern Dies; Sie werden feststellen, dass udev keine Geräteknoten mehr erstellt, sondern nur Symlinks.)
In ähnlicher Weise wurde auch das Laden der Firmware in den Kernel verschoben, sodass die einzigen verbleibenden Aufgaben udev
sind führt das Laden von Modulen (gemäß Modaliasen) und das Anwenden von Geräteberechtigungen und anderen udev-Regeln durch.
Theoretisch sollte also ein vollständig monolithischer Kernel booten ganz gut ohne udev.
Das eigentliche Problem dabei ist jedoch, was später passiert.
-
Nicht wenige Userspace-Programme verlassen sich darauf, dass udev seine Gerätedatenbank verwaltet, auf die über
libudev
zugegriffen werden kann . Während das Aufzählen von Geräten und das Abhören von hinzugefügten/entfernten Ereignissen direkt über die Kernel-Schnittstellen (sysfs und netlink) erfolgen könnte, werden Sie immer noch ohne alle Metadaten zurückgelassen, die verschiedene udev-Regeln angehängt haben. -
udev-Regeln behalten auch verschiedene "beständige" symbolische Links in
/dev/disk/by-*
bei ,/dev/mapper
,/dev/input/by-path
,/dev/snd/by-path
, usw. Wenn Sie beispielsweise zwei Festplatten angeschlossen haben, gibt es keine Garantie dafür, dass die erste immersda
ist odersdb
, aber udev stellt sicher, dass die symbolischen Links in/dev/disk/by-uuid
wird weiterhin auf den richtigen zeigen. -
Während Geräteknoten jetzt vom Kernel erstellt werden und daher nicht mehr Ihre Angelegenheit sind, ist es dennoch wichtig zu beachten, dass einige Gerätetypen begonnen haben, dynamisch zugewiesene Major/Minor-Nummern zu verwenden, also obwohl Sie
/dev/fuse
haben als 10.228 und/dev/hpet
wie heute 10.229, werden sie werden haben nach jedem Neustart unterschiedliche Nummern, also entwederdevtmpfs
oder (auf älteren Systemen) ein Programm, das auf uevents lauscht, ist erforderlich .
Viele dieser Dinge könnten leicht von anderen Programmen wie mdev
erledigt werden , Natürlich. Mein Punkt ist, dass ein statischer /etc/MAKEDEV
Skript wird nicht mehr funktionieren...
Wenn es also um die Boot-Komplexität geht, ist udev ziemlich wahrscheinlich die geringste Ihrer Bedenken.
Es gibt mehrere Alternativen:
- Besorgen Sie sich einfach einen Satz passender
chmod
,chown
,ln
, und ähnliche Befehle in einem Skript, das als Teil des Bootstrap ausgeführt wird. - Verwenden Sie
systemd-udev
, der Plug-and-Play-Manager, der Teil des systemd-Projekts ist. - Verwenden Sie
eudev
von Gentoo , was ein Fork vonsystemd-udev
ist von dem sich systemd jetzt deutlich entfernt hat. - Verwenden Sie
vdev
von Devuan , ein von Jude Nelson entwickelter Plug-and-Play-Manager, der Teil von Devuan ist. - Verwenden Sie
mdev
, was im Gegensatz zu einer anderen Antwort keine Gentoo-Sache ist. Es ist der Plug-and-Play-Manager, der in BusyBox integriert ist. - Verwenden Sie Suckless
mdev
Dies ist ein Plug-and-Play-Manager, der von Dimitris Papastamos entwickelt wurde. - Verwenden Sie
mdevd
von Laurent Bercot , die konfigurationskompatibel mitmdev
von BusyBox ist aber behandelt seine eigenen Sockets und versteht das LISTEN-Protokoll nicht.
All dies, mit Ausnahme des ersten, erfordert eine Reihe von Regeln, die beschreiben, wie auf Kernel-Benachrichtigungsereignisse über Geräte reagiert werden soll. Offensichtlich.
Es gibt auch Tools, die Programme aufnehmen, die für /proc/sys/kernel/hotplug
entwickelt wurden , wie die beiden mdev
s, und das wird sie anpassen und serialisieren, indem es auf einen Netlink-Socket hört und dann diese Programme erzeugt:
- Laurent Bercots alter
s6-netlink-listener
unds6-uevent-spawner
netlink-datagram-socket-listen
undplug-and-play-event-handler
aus dem Nosh-Toolset