Ci sono alternative all'utilizzo di `udev`?

Mentre capisco la grandezza di udev e apprezzo lo sforzo degli sviluppatori, mi chiedevo semplicemente se ci fosse un'alternativa.

Ad esempio, potrei immaginare che dovrebbe esserci un modo per creare uno script di avvio che crei la maggior parte dei nodi del dispositivo che sul mio sistema (senza cambiare hardware) sono comunque gli stessi.

Il vantaggio o il motivo che vorrei saltare udevsarebbe lo stesso del salto dbus, vale a dire ridurre la complessità e aumentando così le mie modifiche per configurare il sistema in modo più sicuro.

Ci sono varie alternative udevlà fuori. Apparentemente Gentoo può usare qualcosa chiamato mdev. Un'altra opzione sarebbe quella di tentare di utilizzare udevil predecessore devfsd. Infine, puoi sempre creare tutti i file del dispositivo di cui hai bisognomknod .

Si noti che con quest'ultimo non è necessario creare tutto al momento dell'avvio poiché i nodi possono essere creati su disco e non in un file system temporaneo come con le altre opzioni. Naturalmente, perdi la flessibilità di aver creato in modo dinamico i file del dispositivo quando viene inserito un nuovo hardware (ad es. Una chiavetta USB). Credo che l'approccio standard in questa era sia quello di avere tutti i file di dispositivo di cui potresti ragionevolmente aver già bisogno /dev(cioè molti file di dispositivi).

Ovviamente il difficile riuscire a far funzionare uno di questi approcci in una distribuzione moderna è probabilmente piuttosto alto. Il wiki di Gentoo menziona le difficoltà nel mdevlavorare con un ambiente desktop (per non parlare di Gentoo). L'ultima devfsdversione è stata il 2002, non ho idea se funzionerà con i kernel moderni. La creazione manuale dei nodi è probabilmente l'approccio più praticabile, ma anche la disabilitazione udevpotrebbe essere una sfida, in particolare nelle distos utilizzando systemd( udevora fa parte disystemd , il che suggerisce una forte dipendenza).

Il mio consiglio è di attenersi udev;)

I kernel Linux moderni supportano il devtmpfsfile system ^{(non confondere con gli antichi devfs)} , che crea dinamicamente tutti i nodi del dispositivo non appena il kernel li rileva. (In effetti, le ultime udevversioni lo richiedono ; scoprirai che udev non crea più nodi di dispositivo, ma solo collegamenti simbolici.)

Allo stesso modo, anche il caricamento del firmware è stato spostato nel kernel, quindi le uniche attività rimanenti da udeveseguire sono il caricamento del modulo (in base alle modalità) e l'applicazione delle autorizzazioni del dispositivo e di altre regole udev.

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

Tuttavia, il vero problema qui è quello che succede dopo.

1. Molti programmi per lo spazio utente fanno affidamento sul fatto che udev mantenga il proprio database dei dispositivi, accessibile attraverso libudev. Mentre l'enumerazione dei dispositivi e l'ascolto di eventi aggiunti / rimossi potrebbero essere eseguiti direttamente utilizzando le interfacce del kernel (sysfs e netlink), rimarrai comunque senza tutti i metadati a cui sono state associate varie regole udev.

2. udev regole mantengono anche vari link 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'è garanzia che il primo sarà sempre sdao sdb, ma udev assicura che i collegamenti simbolici /dev/disk/by-uuidcontinuino a puntare a quello giusto.

3. Mentre i nodi del dispositivo vengono ora creati dal kernel e quindi non la vostra preoccupazione più, è comunque importante notare che alcuni tipi di dispositivi hanno iniziato a utilizzare i numeri / minori importanti assegnati in modo dinamico, quindi, anche se si dispone /dev/fusedi 10.228 e /dev/hpetdi 10.229 di oggi, che saranno hanno numeri diversi dopo ogni riavvio, quindi o devtmpfso (su sistemi più vecchi) è richiesto un programma che ascolta gli eventi .

Molte di queste cose potrebbero essere facilmente eseguite da altri programmi come mdev, ovviamente. Il mio punto è che uno /etc/MAKEDEVscript statico non funzionerà più ...

Quindi, in sostanza, quando si tratta di complessità di avvio, udev è probabilmente il minimo dei tuoi dubbi.

Esistono diverse alternative:

• È sufficiente avere un insieme di appropriate chmod, chown, lne comandi consimili in uno script che viene eseguito come parte del bootstrap.
• Utilizzare systemd-udevil gestore plug-and-play che fa parte del progetto systemd.
• Usa Gentoo'seudev , che è un fork di systemd-udevcui systemd è ora notevolmente divergente.
• Usa Devuan'svdev , 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 Sucklessmdev che è un gestore plug-and-play sviluppato da Dimitris Papastamos.
• Utilizzare Laurent Bercotmdevd , che è compatibile con la configurazione di BusyBox mdevma gestisce la propria presa 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.

Esistono anche strumenti per i quali saranno progettati programmi /proc/sys/kernel/hotplug, come i due mdev, e che li adatteranno e li serializzeranno ascoltando un socket netlink e generando poi quei programmi:

• Laurent Bercot è vecchio s6-netlink-listeneres6-uevent-spawner
• netlink-datagram-socket-listen e plug-and-play-event-handlerdal set di strumenti nosh

udev? La migliore alternativa è non usarlo. E imparando a non usarlo, Linux e il mondo * NIX inizieranno ad avere un senso logico.

La migliore alternativa a lungo termine è l'uso di dispositivi statici (vedi nota). Se hai il driver, il kernel di Linux gestisce l'hot plug. Preferisco non avere mai udevd in esecuzione.

dbus è un'altra questione. Rallenta il tuo sistema ma, il mondo in continua evoluzione degli sceneggiatori lo adora. Quindi, molte cose a cui sei abituato, come i browser web o le applicazioni con backend di script, devono essere riparate (avviate o ricostruite senza quella roba o scaricate per un'altra applicazione).

Nota: se si sta semplicemente collegando un'unità flash o un dispositivo dvd, utilizzare dmesg|tailper vedere il nome del dispositivo da montare. Imparare quando un dispositivo è un personaggio o un dispositivo a blocchi è una conoscenza di sistema fondamentale nel mondo dell'hardware del computer. In Linux è open source, controlla molto su Linux, non solo integrato . È il migliore per una comprensione più ampia della logica diretta (non della filosofia) di tutti * NIX, come Linux (Solaris, HPUX, AIX, ecc.).

Udev, dbus, gconf / dconf, systemd, gnome-shell, Gnome, Glib, mono e Fedora sono per le persone con un sacco di tempo a disposizione che non possono RTFM, o che desiderano un aggiornamento davvero automatico (aspetto) ma, più lento di melassa, buggy, a metà strada Linux. (Un posto davvero orribile, guarda in giro per tonnellate di esperienze simili).

Il sistema si avvia quindi esegue udevd. Ma si afferma che udev è necessario perché, will changeal riavvio , i numeri minori del dispositivo sono necessari . La ragion d'essere di Udev sembra contraddirsi ad ogni turno. E dove sono i file sembra sempre sbagliato, indipendentemente da chi consulti. Non fidarti o freedesktop.org.

Inoltre udev viene assorbito da quell'orrore noto come systemd, quindi non so cosa si faccia con i junk / etc / udev. Ed è fatuo dire che scrivere regole udev è in qualche modo migliore di qualsiasi cosa. La gente di Gentoo sembra voler aggrapparsi a questo e non dover avere systemd, quindi l'hanno biforcuta su eudev.

Se vuoi un sistema ridicolmente veloce, senza brutte sorprese, usa le basi di Linux.