Del resto, cosa c'era di sbagliato esattamente in un mucchio di file statici /dev? Apparentemente non è abbastanza soddisfacente per gli sviluppatori aver reinventato questa ruota con il mio conteggio 3 volte ora ( devfs-> udev + HAL-> udev), e ora a quanto pare sta entrando anche nel Programma di Unified Init, quindi quattro volte.

Ricordo quando ho iniziato a usare Linux anni fa, essendo sorpreso che, nonostante affermasse che "tutto è un file", non c'è /dev/eth0(che in seguito aveva senso, dal momento che non è un dispositivo char o block - sebbene un tipo di dispositivo "pacchetto" sarebbe interessante ...). Detto questo, perché il programma che gestisce l'albero dei file dei dispositivi char e block è anche responsabile dei dispositivi di rete? Ho visto vaghi riferimenti alla "flessibilità", ma cosa si aggiunge a ciò che, per esempio, ifconfig (8) fa semplicemente guardando /proc/net/dev? So, ad esempio, NetworkManager non sarà presto in Net o OpenBSD perché dipende da udevquale delle due squadre non vuole scrivere; cosa non dico/devche sono già esposti in più modi dal kernel (e nessuno di loro in /dev!).

È solo a causa del collegamento a caldo? Ci sono stati problemi con il kernel solo ascoltando i bus fisici e caricando i moduli appropriati su un messaggio "dispositivo aggiunto"? Oppure, Dio non voglia, l'amministratore vero lo fa? Ricordo che nei primi anni 2000 i miei server a volte inizializzavano le loro schede di rete in un ordine inaspettato, e suppongo che abbia senso decidere che la denominazione sia decisa in userland (anche se non era terribilmente difficile da correggere all'epoca), ma questo sembra un martello per uno scarafaggio. (O forse quel problema colpisce casi d'uso non sto pensando a molto più difficile di server o PC montati su rack, che è la mia esperienza.)

Quindi, per dire chiaramente la mia domanda: quali problemi risolve effettivamente udev e in che modo devfs, HAL e / o un semplice vecchio file non sono riusciti a risolverli? C'è un motivo particolare per cui molte cose diverse (hotplugging, gestione generale dei dispositivi, gestione dei dispositivi di rete, denominazione dei dispositivi, priorità dei driver, ecc.) Devono essere tutte un programma?

Altre due cose: il passaggio di Linux nell'azienda e altri server di grandi dimensioni stava esponendo l'elettricità statica /dev. La tecnologia avanzata, sia nel consumatore che nell'impresa, stava esponendo statico / sviluppo come uno scherzo. [Questa risposta riempie di più il retroscena, non in particolare perché devfs è stato sostituito con udev].

Esaurimento dello spazio numerico maggiore e minore

/devi file sono identificati all'interno del kernel dai loro numeri maggiori e minori. Il kernel non si è mai preoccupato del nome (e potresti, ad esempio, mv /dev/sda /dev/disk-1continuare a funzionare, anche se ovviamente i programmi non saprebbero dove trovarlo).

Con un statico /dev, è necessario allocare un numero maggiore / minore per ogni potenziale dispositivo che potrebbe esistere. Questi numeri devono essere univoci a livello globale, poiché vengono spediti come parte di distro, non creati su richiesta. Il problema è che sono tutti numeri a 8 bit: l'intervallo è compreso tra 0 e 255.

Inizialmente, ad esempio, Linux ha iniziato con 8,0 essendo sda, 8,1 essendo sda1, 8,16 essendo sdb, ecc. Ma le persone continuavano ad aggiungere sempre più dischi alle macchine, specialmente quando si considerano cose come il canale in fibra ottica. Quindi ad un certo punto, sono stati aggiunti i numeri maggiori 65–71 per più dischi. Più tardi, i numeri maggiori 128–135. Eppure la gente continuava a desiderare più dischi ...

E sono arrivati ​​formati di tabelle di partizioni come GPT, che supportano più partizioni per disco. E ovviamente altri dispositivi stavano mangiando attraverso lo spazio numerico: vari controller RAID, gestione del volume logico, ecc.

Il risultato finale può essere visualizzato nell'elenco dei dispositivi LANANA Linux . Se guardi la lista 2.6 (l'unica ancora lì), molti dei numeri maggiori del blocco attraverso 200 (max: 255) —sono usati. Chiaramente, i numeri si sarebbero esauriti.

Passare a numeri più grandi non è stato facile. Cambia l'ABI del kernel. A seconda del file system, cambia il layout su disco. Ma, naturalmente, la maggior parte di quei dispositivi non esisteva su nessun sistema, anche uno che (ad esempio) stava esaurendo i dischi SCSI probabilmente aveva un sacco di cose gratuite - probabilmente non aveva bisogno di un disco rigido IBM XT, per esempio.

Con una dinamica /dev, la distribuzione non deve spedire i numeri dei dispositivi. Non devono più essere unici a livello globale. Non devono nemmeno essere unici tra gli stivali.

I nomi dei dispositivi erano imprevedibili

In passato era molto semplice assegnare un numero a tutto. Una scheda aveva due canali IDE; ogni canale IDE supportava un master e uno slave. È possibile assegnare in ordine di canale e in ordine master-poi-slave. Quindi hdadiventa il primo canale, maestro; hdbprimo canale, schiavo; hdcsecondo canale, master; ecc. Quelli erano prevedibili e stabili. Potrebbero cambiare se aggiungi una nuova unità o ne rimuovi una, ma in assenza di modifiche hardware, erano statiche.

Potresti inserire il /dev/hda1tuo /etc/fstabed essere sicuro che rimarrebbe funzionante, almeno assente le modifiche hardware.

IDE ha funzionato così. Niente dopo.

SATA sembra essere semplice: una porta, un disco. Ma non è così; consente moltiplicatori di porte. E consente hot-swap. Tuttavia, in assenza di modifiche hardware, puoi effettivamente continuare a far funzionare la mappatura.

USB è molto peggio. Non solo consente hot swap, è tipico. Le persone collegano continuamente unità flash USB. Inoltre, i dispositivi possono impiegare un po 'di tempo a sondare e possono effettivamente cambiare ogni volta che ne hanno voglia (ad esempio, quando si accende o si spegne la modalità di archiviazione USB sul telefono). Firewire è simile. Con nessuno dei due puoi davvero trovare una mappatura stabile.

I dischi collegati in rete non hanno alcun ordine di porta intrinseco. L'unico ordine utilizzato dal kernel è l'ordine in cui sono comparsi. Lo stesso vale per i volumi logici.

La ricerca della velocità di avvio ha anche peggiorato le cose. Inizialmente, il kernel si sarebbe felicemente seduto in giro e avrebbe aspettato abbastanza tempo per l'inizializzazione, ad esempio, di tutti i dispositivi USB. Per sondare completamente tutti i bus SCSI, ecc. Tali sonde sono state trasformate in attività in background; l'avvio non li aspetterebbe più. I dispositivi vengono aggiunti al completamento delle sonde.

Quindi al kernel è rimasto, più o meno, "qualunque sia l'ordine in cui si presentano". Ciò significava che molti tipi di dispositivi possono e hanno cambiato l'ordine ad ogni avvio: ciò che era su un avvio /dev/sdbera su un altro avvio /dev/sdc. Questo rende l'idea di uno statico /devuno scherzo.

Sommario

Quando si considera che la combinazione di elettricità statica /devdiventa sempre più insignificante a causa di ordini imprevedibili di sondaggi del dispositivo e si continua a allocare numeri statici maggiori / minori che portano a un notevole lavoro che non si esaurisce, diventa chiaro il motivo per cui gli sviluppatori di Linux hanno scelto di passare a una dinamica /dev.

Buona domanda.

In un certo senso, questo argomento potrebbe essere ribaltato: dal momento che il kernel 2.6.13 ha introdotto una nuova versione di uevent, era destinato a succedere che devfsavrebbe dovuto essere riscritto per sfruttare le nuove funzionalità dell'interfaccia. Quindi, in un certo senso, la domanda dovrebbe essere il motivo per cui il cambiamento nel kernel.

Tuttavia, prendendo il valore nominale, la tua domanda trova risposta in questo articolo di Wikipedia :

A differenza dei sistemi Unix tradizionali, in cui i nodi del dispositivo nella directory / dev sono stati un insieme statico di file, il gestore dei dispositivi udev Linux fornisce dinamicamente solo i nodi per i dispositivi effettivamente presenti su un sistema. Sebbene devfs usasse fornire funzionalità simili, Greg Kroah-Hartman ha citato una serie di ragioni per preferire la sua implementazione rispetto a devfs:

1) udev supporta la denominazione persistente dei dispositivi, che non dipende, ad esempio, dall'ordine in cui i dispositivi sono collegati al sistema. L'impostazione predefinita di udev fornisce nomi persistenti per i dispositivi di archiviazione. Qualsiasi disco rigido è riconosciuto dal suo ID univoco di filesystem, dal nome del disco e dalla posizione fisica sull'hardware a cui è collegato.

2) udev viene eseguito interamente nello spazio utente, al contrario dello spazio del kernel di devfs. Una conseguenza è che udev ha spostato la politica di denominazione dal kernel e può eseguire programmi arbitrari per comporre un nome per il dispositivo dalle proprietà del dispositivo, prima che il nodo venga creato; lì, l'intero processo è anche interrompibile e viene eseguito con una priorità inferiore.

Dovrei probabilmente aggiungere che con udev race conditionsi evita la possibilità di a , che fondamentalmente ha minato la denominazione dei dispositivi in ​​devfs e hotplug. In altre parole: con devfs non c'era modo di assicurarsi che la porta ethernet più a sinistra fosse chiamata eth0e quella più a destra eth1, rendendo (come puro esempio) la configurazione di router (una porta su WAN, una porta su LAN) difficile da strumento.

L'adozione dello schema di denominazione dei dischi basato su GUID è un altro vantaggio e il trasferimento dell'intero processo nello spazio utente è ancora più grande: hai cercato in questo sito per vedere quante persone scrivono le proprie regole udev?

Come semplice esempio dei vantaggi insiti nell'avere udev nello spazio utente, controlla questa domanda o questa altra domanda , entrambe su questo stesso sito.