Ci sono alternative all'uso di `udev`?

Ci sono varie alternative a udev là fuori. Apparentemente Gentoo può usare qualcosa chiamato mdev . Un'altra opzione sarebbe tentare di utilizzare udev il predecessore di devfsd . Infine, puoi sempre creare tutti i file del dispositivo di cui hai bisogno con mknod .

Si noti che con quest'ultimo non è necessario creare tutto all'avvio poiché i nodi possono essere creati su disco e non in un file system temporaneo come con le altre opzioni. Naturalmente, si perde la flessibilità di avere file di dispositivo creati dinamicamente quando viene collegato un nuovo hardware (ad esempio una chiavetta USB). Credo che l'approccio standard in quest'epoca fosse quello di avere tutti i file di dispositivo di cui potevi ragionevolmente aver bisogno già creati sotto /dev (vale a dire molti file di dispositivo).

Ovviamente la difficoltà nel far funzionare uno qualsiasi di questi approcci in una distribuzione moderna è probabilmente piuttosto alta. Il wiki di Gentoo menziona le difficoltà nell'ottenere mdev lavorare con un ambiente desktop (figuriamoci al di fuori di Gentoo). L'ultimo devfsd il rilascio era il 2002, non ho idea se funzionerà anche con i kernel moderni. La creazione manuale dei nodi è probabilmente l'approccio più praticabile, ma anche la disabilitazione di udev potrebbe essere una sfida, in particolare nei disto usando systemd (udev fa ora parte di systemd , che suggerisce una forte dipendenza).

Il mio consiglio è di attenersi a udev;)

I moderni kernel Linux supportano il devtmpfs file system , che crea dinamicamente tutti i nodi del dispositivo non appena il kernel li scopre. (In effetti, l'ultimo udev le versioni richiedono questo; scoprirai che udev non crea più alcun nodo di dispositivo, solo collegamenti simbolici.)

Allo stesso modo, anche il caricamento del firmware è stato spostato nel kernel, quindi le uniche attività rimanenti udev esegue sono il caricamento del modulo (secondo modaliases) e l'applicazione delle autorizzazioni del dispositivo e altre regole udev.

Quindi, in teoria, un kernel completamente monolitico dovrebbe avviarsi bene senza udev.

Tuttavia, il vero problema qui è cosa succede dopo.

1. Molti programmi in spazio utente si affidano a udev per mantenere il proprio database dei dispositivi, accessibile tramite libudev . Sebbene l'enumerazione dei dispositivi e l'ascolto degli eventi aggiunti/rimossi possano essere eseguiti direttamente utilizzando le interfacce del kernel (sysfs e netlink), rimarrai comunque senza tutti i metadati che le varie regole udev hanno allegato.

2. Le regole di udev mantengono anche vari collegamenti simbolici "persistenti" in /dev/disk/by-* , /dev/mapper , /dev/input/by-path , /dev/snd/by-path , e così via. Ad esempio, se hai due dischi collegati, non c'è alcuna garanzia che il primo sarà sempre sda o sdb , ma udev garantisce che i collegamenti simbolici in /dev/disk/by-uuid continuerà a puntare a quello giusto.

3. Mentre i nodi del dispositivo sono ora creati dal kernel e quindi non ti riguardano più, è comunque importante notare che alcuni tipi di dispositivi hanno iniziato a utilizzare numeri maggiori/secondari assegnati dinamicamente, quindi anche se hai /dev/fuse come 10.228 e /dev/hpet come 10.229 oggi, lo faranno hanno numeri diversi dopo ogni riavvio, quindi devtmpfs oppure (sui sistemi meno recenti) è necessario un programma che ascolti uevents .

Molte di queste cose potrebbero essere facilmente eseguite da altri programmi come mdev , Certo. Il mio punto è che un /etc/MAKEDEV statico lo script non funzionerà più...

Quindi, fondamentalmente, quando si tratta di complessità di avvio, udev è molto probabilmente il minore delle tue preoccupazioni.

Ci sono diverse alternative:

• Basta avere una serie di chmod appropriati , chown , ln e comandi simili in uno script che viene eseguito come parte del bootstrap.
• Usa systemd-udev , il gestore plug-and-play che fa parte del progetto systemd.
• Usa eudev di Gentoo , che è un fork di systemd-udev da cui ora systemd si è notevolmente discostato.
• Usa il vdev di Devuan , che è un gestore plug-and-play sviluppato da Jude Nelson, che fa parte di Devuan.
• Usa mdev , che contrariamente a un'altra risposta non è una cosa di Gentoo. È il gestore plug-and-play integrato in BusyBox.
• Usa Suckless mdev che è un gestore plug-and-play sviluppato da Dimitris Papastamos.
• Usa mdevd di Laurent Bercot , che è una configurazione compatibile con mdev di BusyBox ma gestisce i propri socket e non comprende il protocollo LISTEN.

Tutti questi, a parte il primo, richiedono serie di regole che descrivono come reagire agli eventi di notifica del kernel sui dispositivi. Ovviamente.

Ci sono anche strumenti che accettano programmi progettati per /proc/sys/kernel/hotplug , come i due mdev s, e che li adatterà e li serializzerà ascoltando un socket netlink e quindi generando quei programmi:

• Il vecchio s6-netlink-listener di Laurent Bercot e s6-uevent-spawner
• netlink-datagram-socket-listen e plug-and-play-event-handler dal set di strumenti nosh