☰

Gibt es Alternativen zur Verwendung von „udev“?

tag-icon • tag-icon linux devices udev
Gibt es Alternativen zur Verwendung von „udev“?

Obwohl ich die Großartigkeit von udev verstehe und die Bemühungen der Entwickler schätze, habe ich mich einfach gefragt, ob es eine Alternative dazu gibt.

Ich könnte mir zum Beispiel vorstellen, dass es eine Möglichkeit geben müsste, ein Startskript zu erstellen, das die meisten Geräteknoten erstellt, die auf meinem System (ohne Änderung der Hardware) ohnehin weitgehend gleich sind.

Der Vorteil oder Grund, warum ich es überspringen möchte, udevwäre derselbe wie beim Überspringen dbus, nämlich die Verringerung der Komplexität und dadurch die Erhöhung meiner Möglichkeiten, das System sicherer einzurichten.

Antwort1

Moderne Linux-Kernel unterstützen das devtmpfsDateisystem (nicht zu verwechseln mit dem alten devfs) , das alle Geräteknoten dynamisch erstellt, sobald der Kernel sie erkennt. (Tatsächlich verwenden die neuesten udevVersionenerforderndies; Sie werden feststellen, dass udev keine Geräteknoten mehr erstellt, sondern nur symbolische Links.)

Ebenso wurde das Laden der Firmware in den Kernel verschoben, sodass die einzigen verbleibenden Aufgaben udevdas Laden von Modulen (gemäß Modaliasen) und das Anwenden von Geräteberechtigungen und anderen Udev-Regeln sind.

Theoretisch sollte ein vollständig monolithischer KernelStiefelgeht ganz gut ohne udev.

Das wirkliche Problem besteht hier jedoch darin, was später passiert.

  1. Viele Userspace-Programme verlassen sich darauf, dass udev seine Gerätedatenbank verwaltet, die über zugänglich ist libudev. Obwohl das Aufzählen von Geräten und das Abhören von Hinzufügungs-/Entfernungsereignissen direkt über die Kernelschnittstellen (Sysfs und Netlink) erfolgen könnte, fehlen Ihnen dennoch alle Metadaten, die an verschiedene udev-Regeln angehängt sind.

  2. udev-Regeln verwalten auch verschiedene „persistente“ symbolische Links in /dev/disk/by-*, /dev/mapper, /dev/input/by-path, /dev/snd/by-path, usw. Wenn Sie beispielsweise zwei Festplatten angeschlossen haben, gibt es keine Garantie, dass die erste immer sdaoder ist sdb, aber udev stellt sicher, dass die symbolischen Links in /dev/disk/by-uuidweiterhin auf die richtige zeigen.

  3. Obwohl Geräteknoten jetzt vom Kernel erstellt werden und Sie sich daher nicht mehr darum kümmern müssen, ist es dennoch wichtig zu beachten, dass einige Gerätetypen begonnen haben, dynamisch zugewiesene Haupt-/Nebennummern zu verwenden. Obwohl Sie heute /dev/fusealso 10.228 und /dev/hpet10.229 haben,Willehaben nach jedem Neustart unterschiedliche Zahlen, so dass entweder devtmpfsoder (auf älteren Systemen) ein Programm, das auf uevents hört,erforderlich.

Viele dieser Dinge könnten mdevnatürlich auch problemlos von anderen Programmen wie erledigt werden. Mein Punkt ist, dass ein statisches /etc/MAKEDEVSkript nicht mehr funktionieren wird ...

Wenn es also um die Komplexität des Bootens geht, ist udev wahrscheinlich dieam wenigstenIhrer Anliegen.

Antwort2

Es gibt verschiedene Alternativen udev. Gentoo kann anscheinend etwas verwenden, dasmdevEine andere Möglichkeit wäre, udevden Vorgänger von zu verwenden devfsd. Schließlich können Sie alle benötigten Gerätedateien jederzeit mit erstellen mknod.

Beachten Sie, dass bei letzterem nicht alles beim Booten erstellt werden muss, da die Knoten auf der Festplatte und nicht in einem temporären Dateisystem wie bei den anderen Optionen erstellt werden können. Natürlich verlieren Sie die Flexibilität dynamisch erstellter Gerätedateien, wenn neue Hardware angeschlossen wird (z. B. ein USB-Stick). Ich glaube, der Standardansatz in dieser Ära bestand darin, jede Gerätedatei, die Sie vernünftigerweise benötigen könnten, bereits erstellt zu haben /dev(d. h. viele Gerätedateien).

Natürlich ist es wahrscheinlich ziemlich schwierig, einen dieser Ansätze in einer modernen Distribution zum Laufen zu bringen. Das Gentoo-Wiki erwähnt Schwierigkeiten, es in mdeveiner Desktop-Umgebung zum Laufen zu bringen (ganz zu schweigen von außerhalb von Gentoo). Die letzte devfsdVersion war 2002, ich habe keine Ahnung, ob es überhaupt mit modernen Kerneln funktioniert. Das manuelle Erstellen der Knoten ist wahrscheinlich der praktikabelste Ansatz, aber selbst das Deaktivieren könnte eine Herausforderung sein, insbesondere in Distributionen, die ( ist jetzt Teil von , was auf eine starke Abhängigkeit hindeutet) udevverwenden .systemdudevsystemd

Mein Rat: Bleib dabei udev;)

Antwort3

Es gibt mehrere Alternativen:

  • Besitzen Sie einfach eine Reihe geeigneter chmod, chown, ln, und ähnlicher Befehle in einem Skript, das als Teil des Bootstraps ausgeführt wird.
  • Verwenden Sie systemd-udev, den Plug-and-Play-Manager, der Teil des systemd-Projekts ist.
  • VerwendenGentooseudev, ein Fork von , systemd-udevvon dem sich systemd mittlerweile deutlich abgewichen ist.
  • VerwendenDevuansvdev, ein von Jude Nelson entwickelter Plug-and-Play-Manager, der Teil von Devuan ist.
  • Verwenden Sie mdev, was im Gegensatz zu einer anderen Antwort kein Gentoo-Ding ist. Es ist der Plug-and-Play-Manager, der inBusyBox.
  • VerwendenSauglosmdevDabei handelt es sich um einen Plug-and-Play-Manager, der von Dimitris Papastamos entwickelt wurde.
  • VerwendenLaurent Bercotsmdevd, dessen Konfiguration mit der von BusyBox kompatibel ist, mdevaber seine eigene Socket-Verarbeitung durchführt und das LISTEN-Protokoll nicht versteht.

Alle diese Punkte, mit Ausnahme des ersten, erfordern Regelsätze, die beschreiben, wie auf Kernel-Benachrichtigungsereignisse zu Geräten reagiert werden soll. Offensichtlich.

/proc/sys/kernel/hotplugEs gibt auch Tools, die für entwickelte Programme (wie die beiden s) übernehmen mdevund diese anpassen und serialisieren, indem sie auf einen Netlink-Socket hören und dann die folgenden Programme erzeugen:

Antwort4

Das ist zwar alt, aber ich möchte meine Lösung hier für alle zusammenfassen, die vergeblich danach suchen.
Es ist nicht einfach, udev zu vermeiden. DEVTMPFS aus der Konfiguration herauszulassen, hindert den Kernel nicht daran, eine RAM-Disk auf /dev zu mounten und zu füllen. Leider erstellt es nicht die notwendigen Mount-Punkte /dev/shm und /dev/pts. Was notwendig ist, ist, devtmpfs.mount=0 zu den Boot-Argumenten hinzuzufügen.

verwandte Informationen