Contact me sending an e-mail (antispam defense activated)
Introduzione a /dev, devfs e udev
Sandro Tosi, 12 Marzo 2007
Cerchero' qui di raccogliere una serie di stralci di informazioni che ho raccolto riguardo a devfs, udev e alla directory /dev. Potrebbero non essere molto aggiornati, ma sono un buon punto di partenza per esplorare come il kernel gestisce i device.
1. Cos'e' la directory /dev e la vecchia gestione dei device in Linux
Il principale compito del kernel e' quello di gestire le componenti hardware del computer. Nella directory /dev troviamo i device file, riferimenti diretti ai device hardware. Non sono dei veri e propri file, ma corrispondono ad un particolare dispositivo. Quando un programma accede ed usa questi file speciali, l'operazione viene passata ad un device driver nel kernel.
In precendenza, i sistemi Linux erano obbligati a mantenere la directory /dev sul filesystem normale. Questo comporta che dentro /dev ci dovessere essere file per ogni possibile device driver, anche se non presente sulla macchina. Solitamente i file venivano creati una solta volta (per esempio all'installazione della macchina) e che fossero memorizzati su filesystem; cio' comportava che /dev fosse veramente grande.
Questa gestione statica delle informazioni rendeva difficile aggiungere o rimuovere dinamicamente device file quando i driver venivano caricato o rimossi dal kernel, e rendeve impossibile riorganizzare le entry in /dev. Inoltre, non era nemmeno chiaro quali device fossero davvero presenti sul sistema, e quali invece non sono utilizzati.
Un altro inconveniente di questo meccanismo per la gestione di /dev e' che la gerarchia dei driver deve essere strettamente legata all'idea di major e minor number, che sono il modo per associare un nome di device al driver incaricato a servire le operazioni hardware. La quantita' di major e minor number e' limitata, e questo riduce il numero di device e di device driver che possono essere usati sul sistema.
Per non parlare poi del fatto che, il device associato all'hardware, spesso dipendeva dall'ordine in cui veniva attaccato al sistema: due stampanti USB, potevano scambiarsi il device file a seconda di quale delle due venisse accesa prima.
Un aspetto interessante di questa vecchia gestione e' che, dal momento che mount utilizza /dev, non e' nemmeno possibile mettere /dev su una partizione separata da /.
1.2. Alcune info su /dev
In ogni caso, se ancora state utilizzando un vecchio sistema con la gestione di /dev statica, ecco qui alcune info interessanti:
- MAKEDEV e mknod, due programmi per creare device sotto /dev, utili per creare device non presenti
- file -s /dev/<entry>, per ottenere informazioni sul device (principalmente su device di dischi, /dev/hda per esempio, per sapere quale delle entry statiche sono associate ad un device sono in uso e quali no).
Una lista di device speciali, valida anche con i kernel piu' recenti:
- /dev/null: e' un dispositivo cestino: cio' che vi entra non ci esce mai piu'. Viene spesso utilizzato per eliminare l'ouput non necessario dall'esecuzione di alcuni programmi. Leggere da /dev/null ritorna caratteri end-of-file, EOF.
- /dev/zero: anche questo device puo' essere usato per evitare output non voluto, ma leggere da questo device, ritorna sempre il carattere \0, ed e' quindi spesso utilizzato percreare file vuoti (dd if=/dev/zero of=/tmp/empry_file bs=1k count=100)
- /dev/full: imita un dispositivo pieno, comodo per testare il comportamento di un'applicazione quando il device a qui accede e' pieno.
- /dev/random: genera dati casuali, basandosi su "rumori d'ambiente" che non sono determinabili (come i movimenti del mouse o il tempo intercorso tra la pressione dei tasti della tastiera). Dal momento che le fonti di questo rumore sono limitate, esse collaborano a riempire l'entropy pool, un'area di raccola di bit casuali; puo' pero' succedere che questo pool sia vuoto o venga alimentato con lentezza e cio' comporta che le letture da questo device siano spesso lente e che a volte si arrestino in attesa che nuovi dati vengano collezionati.
- /dev/urandom: genera dati casuali, basandosi anch'esso sulle stesse fonti di "rumori" di /dev/random, ma quando l'entropy pool e' vuoto, questo device genera dati pseudo-casuali; cio' lo rende piu' veloce ma meno sicuro, in quanto il livello di entropia e' molto minore (e cio' lo rende non adatto per ambiti come la crittografia).
2. Cos'e' devfs
devfs, device filesystem, e' stato introdotto a partire dalla serie stabile 2.4 e fornisce un nuovo filesystem da utilizzare per /dev; questo filesystem tiene traccia delle entry di /dev direttamente dal kernel; cio' significa che, ogni qual volta viene trovato nuovo hardware attaccato al sistema ed il relativo device driver viene caricato, una nuova entry puo' apparire dentro /dev.
In questo modo, /dev viene popolata solo con i device realmente presenti sulla macchina al momento del boot, ed aggioranta dinamicamente nel momento in cui dei device vengano aggiunti o rimossi, tutto questo agevolato dal fatto che ora /dev viene memorizzato in RAM e non su disco.
Questa nuova gestione elimina la necessita' di manterene la lista di tutti i possibili device: appena nuovo hardware viene riconosciuto, il kernel si limita ad inserire una nuova entry ad-hoc in /dev.
Anche devfs aveva qualche problema:
- device name poco flessibili: era difficile cambiare il nome ai device file
- dal momento che e' un driver del kernel, in casi di sistemi con migliaia di device, veniva utilizzata una gran quantita' di memoria del kernel
3. Cos'e' udev
A partire dalla serie di sviluppo 2.5, e dunque con quella stabile 2.6, nel kernel e' stato introdotto il supporto a udev. Dal momento che devfs aveva grossi problemi strutturali e non aveva piu' un maintainer da tempo, e' stato deciso di deprecarlo in favore di udev.
Il grande vantaggio di udev e' che esso vive completamente in userspace, quindi nel kernel non se ne trova traccia, ma e' necessario soltanto abilitare (e montare) il sysfs (/sys) da cui udev legge i parametri di tutte le periferiche e costruisce /dev.
udev si appoggia agli eventi hotplug e a sysfs: quando una nuova periferica viene rilevata, essa genera un evento hotplug e compare come voce sotto /sys; udev reagisce a questo evento creando sotto /dev il device corrispondente, in base alla configurazione effettuata.
Questa architettura implica un certo ritardo nella creazione del device, ma ha dalla sua parte una maggiore flessibilita' nella politca di gestione dei nome dei device, una struttura migliore e l'essere completamente in userspace consente di essere manutento attivamente.
4. Riferimenti
Documentation/filesystems/devfs/README
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs
-> rubini, linux magazine may 2000, using udev -> find link
http://www.kroah.com/linux/talks/ols_2003_udev_talk/
il filesystem devfs, opensp -> find link
Linux Magazine, Mastering udev