Old:Udev e Debian: differenze tra le versioni

nessun oggetto della modifica
m (→‎Link: aggiunto link)
Nessun oggetto della modifica
Riga 4: Riga 4:
Questa guida si prefigge di raccogliere informazioni riguardo udev, la sua configurazione e il suo utilizzo dal punto di vista dell'utente su sistemi Debian GNU/Linux.
Questa guida si prefigge di raccogliere informazioni riguardo udev, la sua configurazione e il suo utilizzo dal punto di vista dell'utente su sistemi Debian GNU/Linux.


Molte delle informazioni sono tratte (e tradotte) da <tt>/usr/share/doc/udev/</tt>. Si prega di correggere o segnalare ogni possibile (e probabile) inesattezza.
Molte delle informazioni sono tratte (e tradotte) da <code>/usr/share/doc/udev/</code>. Si prega di correggere o segnalare ogni possibile (e probabile) inesattezza.


== Il sottosistema hotplug ==
== Il sottosistema hotplug ==


Il sottosistema hotplug (dall'inglese: connessione a caldo, cioè a PC acceso) è un servizio del kernel che provvede a notificare in user space l'avvenuta connessione di un nuovo dispositivo.
Il sottosistema hotplug (dall'inglese: connessione a caldo, cioè a PC acceso) è un servizio del kernel che provvede a notificare in userspace l'avvenuta connessione di un nuovo dispositivo.
Nell'evoluzione del kernel Linux questo servizio ha subito diverse modificazioni, nel tentativo di migliorare ogni volta in termini di prestazioni e flessibilità.
Nell'evoluzione del kernel Linux questo servizio ha subito diverse modifiche, nel tentativo di migliorare ogni volta in termini di prestazioni e flessibilità.


Nei kernel 2.4 l'interfaccia tra i driver e i programmi era fornita assieme a tutte le configurazioni del kernel stesso tramite il filesystem virtuale <tt>/proc</tt>, e i file di dispositivo erano creati staticamente: nella directory <tt>/dev</tt> erano presenti tutti i possibili device file.
Nei kernel 2.4 l'interfaccia tra i driver e i programmi era fornita assieme a tutte le configurazioni del kernel stesso tramite il filesystem virtuale <code>/proc</code>, e i file di dispositivo erano creati staticamente: nella directory <code>/dev</code> erano presenti tutti i possibili device file.
Nel tentativo di migliorare il sistema venne implementato devfs, un altro filesystem virtuale, che si occupava solo dell'interazione programmi-driver, separando così la gestione di questi da quella del kernel.
Nel tentativo di migliorare il sistema venne implementato devfs, un altro filesystem virtuale, che si occupava solo dell'interazione programmi-driver, separando così la gestione di questi da quella del kernel.


A partire dal kernel 2.6 devfs è stato progressivamente abbandonato e sostituito dal sysfs, ancora un filesystem virtuale, che adotta una nuova e unificata interfaccia verso i driver e che risulta migliore di tutte le implementazioni passate.
A partire dal kernel 2.6 devfs è stato progressivamente abbandonato e sostituito dal sysfs, ancora un filesystem virtuale, che adotta una nuova e unificata interfaccia verso i driver e che risulta migliore di tutte le implementazioni passate.


Qualsiasi sia l'interfaccia che il kernel mette a disposizione, è necessario in user space un programma che si occupi di ricevere le notifiche di hotplug e compiere le azioni necessarie per l'utilizzo delle periferiche notificate (caricare moduli, eseguire script ed, eventualmente, creare file di dispositivo in <tt>/dev</tt>).
Qualsiasi sia l'interfaccia che il kernel mette a disposizione, è necessario in userspace un programma che si occupi di ricevere le notifiche di hotplug e compiere le azioni necessarie per l'utilizzo delle periferiche notificate (caricare moduli, eseguire script ed, eventualmente, creare file di dispositivo in <code>/dev</code>).


Prima di udev il programma che svolgeva questo compito era stato chiamato, con poca fantasia, hotplug.
Prima di udev il programma che svolgeva questo compito era stato chiamato, con poca fantasia, hotplug.
Hotplug è tutt'ora in grado di svolgere il suo compito, ma ha alcune limitazioni che si sta tentando di superare:
Hotplug è tuttora in grado di svolgere il suo compito, ma ha alcune limitazioni che si sta tentando di superare:


*è uno script bash, quindi è lento. Notare che la cosa è ininfluente per gli utenti comuni, a meno che non si connettano decine di periferiche al minuto ;-)
*è uno script bash, quindi è lento. Notare che la cosa è ininfluente per gli utenti comuni, a meno che non si connettano decine di periferiche al minuto ;-)
Riga 28: Riga 28:
== Cos'è udev ==
== Cos'è udev ==


Udev è un programma in user space in grado ricevere le notifiche del sottosistema hotplug dei kernel 2.6. A partire dalla versione 0.070 è in grado di fare tutto quello che faceva hotplug per i kernel 2.4, ma è molto più veloce e leggero (è scritto in C). In più udev è in grado di creare dinamicamente i device file (quelli in <tt>/dev</tt>) per ogni periferica che viene rilevata nel sistema.
Udev è un programma in userspace in grado ricevere le notifiche del sottosistema hotplug dei kernel 2.6. A partire dalla versione 0.070 è in grado di fare tutto quello che faceva hotplug per i kernel 2.4, ma è molto più veloce e leggero (è scritto in C). In più udev è in grado di creare dinamicamente i device file (quelli in <code>/dev</code>) per ogni periferica che viene rilevata nel sistema.


Udev si appoggia unicamente al sysfs. Questo fatto ha il grande vantaggio di poter usufruire appieno della nuova e potente interfaccia di cui è stato dotato il kernel 2.6 (il sysfs, appunto) per la comunicazione tra i programmi in user space e i driver delle periferiche in kernel space, includendo nuove funzionalità e migliore controllo sui driver stessi. L'unico svantaggio consiste nel fatto che non tutti i driver, al momento in cui si scrive, sono stati aggiornati per utilizzare il sysfs.
Udev si appoggia unicamente al sysfs. Questo fatto ha il grande vantaggio di poter usufruire appieno della nuova e potente interfaccia di cui è stato dotato il kernel 2.6 (il sysfs, appunto) per la comunicazione tra i programmi in user space e i driver delle periferiche in kernel space, includendo nuove funzionalità e migliore controllo sui driver stessi. L'unico svantaggio consiste nel fatto che non tutti i driver, al momento in cui si scrive, sono stati aggiornati per utilizzare il sysfs.
Riga 37: Riga 37:
Udev non si occupa tuttavia di caricare i moduli necessari al funzionamento del dispositivo, infatti questi <b>devono</b> essere già caricati per permettere ad udev di riconoscere la periferica e creare il corrispondente device file.
Udev non si occupa tuttavia di caricare i moduli necessari al funzionamento del dispositivo, infatti questi <b>devono</b> essere già caricati per permettere ad udev di riconoscere la periferica e creare il corrispondente device file.


Sulla stable ('''sarge''') udev è presente nella versione 0.056 e viene usato in accoppiata con hotplug, che si occupa di caricare i driver delle periferiche.
Sulla stable ('''Sarge''') udev è presente nella versione 0.056 e viene usato in accoppiata con hotplug, che si occupa di caricare i driver delle periferiche.


In '''etch''' (attuale testing) e '''sid''' udev ha invece sostituito anche Hotplug.
In '''Etch''' (attuale testing) e '''Sid''' udev ha invece sostituito anche Hotplug.


Questa guida è dedicata alla versione di udev attualmente in etch.
Questa guida è dedicata alla versione di udev attualmente in Etch.


== Il nuovo udev ==
== Il nuovo udev ==


Dalla versione 0.070 in poi udev ha sostituito completamente hotplug. I driver delle periferiche rilevate vengono caricati tutti automaticamente durante il boot. Per fare un esempio, se al boot vengono trovate delle porte usb, verrà automaticamente caricato il modulo <tt>usb-storage</tt> che permetterà (tra le altre cose) di usare eventuali chiavette usb.
Dalla versione 0.070 in poi udev ha sostituito completamente hotplug. I driver delle periferiche rilevate vengono caricati tutti automaticamente durante il boot. Per fare un esempio, se al boot vengono trovate delle porte USB, verrà automaticamente caricato il modulo <code>usb-storage</code> che permetterà (tra le altre cose) di usare eventuali chiavette usb.


Per usare questa versione di udev è necessario un kernel 2.6.12 o superiore con le opzioni hotplug (CONFIG_HOTPLUG) e tmpfs (CONFIG_TMPFS) attivate. Le opzioni CONFIG_PNP, CONFIG_ISAPNP, CONFIG_PNPBIOS e CONFIG_PNPACPI sono altamente raccomandate per consentire il caricamente automatico di importanti driver.
Per usare questa versione di udev è necessario un kernel 2.6.12 o superiore con le opzioni hotplug (CONFIG_HOTPLUG) e tmpfs (CONFIG_TMPFS) attivate. Le opzioni CONFIG_PNP, CONFIG_ISAPNP, CONFIG_PNPBIOS e CONFIG_PNPACPI sono altamente raccomandate per consentire il caricamento automatico di importanti driver.


A partire dal kernel 2.6.15-rc1 è stata introdotta la nuova implementazione del driver model, la quale presenta nuove feature e una migliore organizzazione dei contenuti di sysfs. Per gestire correttamente i vari dispositivi è quindi obbligatorio dotarsi di una versione di udev pari o superiore alla 0.071.
A partire dal kernel 2.6.15-rc1 è stata introdotta la nuova implementazione del driver model, la quale presenta nuove feature e una migliore organizzazione dei contenuti di sysfs. Per gestire correttamente i vari dispositivi è quindi obbligatorio dotarsi di una versione di udev pari o superiore alla 0.071.
Riga 53: Riga 53:
Il pacchetto hotplug deve essere rimosso manualmente, anche se non dovrebbe creare problemi se restasse installato.
Il pacchetto hotplug deve essere rimosso manualmente, anche se non dovrebbe creare problemi se restasse installato.


Si può disabilitare udev aggiungendo al boot il parametro del kernel <tt>UDEV_DISABLED=yes</tt> in grub o lilo. Alternativamente si può configurare in <tt>/etc/udev/udev.conf</tt> una directory diversa da <tt>/dev</tt> per la creazione dei device file.
Si può disabilitare udev aggiungendo al boot il parametro del kernel <code>UDEV_DISABLED=yes</code> in grub o lilo. Alternativamente si può configurare in <code>/etc/udev/udev.conf</code> una directory diversa da <code>/dev</code> per la creazione dei device file.


== Come funziona udev ==
== Come funziona udev ==
Quando un driver viene caricato, rende disponibili delle informazioni in <tt>/sys</tt> e udev viene eseguito per leggerle e creare il device file appropriato.
Quando un driver viene caricato, rende disponibili delle informazioni in <code>/sys</code> e udev viene eseguito per leggerle e creare il device file appropriato.


Quando si collega una nuova periferica viene generato un evento di hotplug che viene intercettato non più da <tt>/sbin/hotplug</tt> bensì da <tt>/sbin/udevsend</tt> (il gestore degli eventi hotplug è indicato in <tt>/proc/sys/kernel/hotplug</tt>).
Quando si collega una nuova periferica viene generato un evento di hotplug che viene intercettato non più da <code>/sbin/hotplug</code> bensì da <code>/sbin/udevsend</code> (il gestore degli eventi hotplug è indicato in <code>/proc/sys/kernel/hotplug</code>).


Questo significa che:
Questo significa che:
* i moduli non possono essere caricati su richiesta quando un'applicazione cerca di aprire un suo dispositivo, perchè il dispositivo non c'è ancora!
* i moduli non possono essere caricati su richiesta quando un'applicazione cerca di aprire un suo dispositivo, perché il dispositivo non c'è ancora!


* poichè i moduli non vengono caricati su richiesta, se per qualche motivo i driver non possono essere caricati automaticamente durante il boot, bisognerà aggiungerli ad /etc/modules (oppure usare modconf ;-)).
* poiché i moduli non vengono caricati su richiesta, se per qualche motivo i driver non possono essere caricati automaticamente durante il boot, bisognerà aggiungerli ad <code>/etc/modules</code> (oppure usare modconf ;-)).


* alcuni moduli non sono dei driver di un dispositivo e non possono essere caricati automaticamente da udev, devono quindi essere elencati in /etc/modules anch'essi.
* alcuni moduli non sono dei driver di un dispositivo e non possono essere caricati automaticamente da udev, devono quindi essere elencati in <code>/etc/modules</code> anch'essi.


* alcuni driver non sono stati ancora portati su sysfs, e udev non sarà in grado di creare i loro device. Se si usa uno di questi driver è necessario creare il device dopo ogni boot. A questo scopo vedere la sezione sul file <tt>/etc/udev/links.conf</tt>
* alcuni driver non sono stati ancora portati su sysfs, e udev non sarà in grado di creare i loro device. Se si usa uno di questi driver è necessario creare il device dopo ogni boot. A questo scopo vedere la sezione sul file <code>/etc/udev/links.conf</code>


In altre parole, su un tipico sistema si potrebbero dover caricare manualmente (usando /etc/modules) dei moduli come ppdev e tun.
In altre parole, su un tipico sistema si potrebbero dover caricare manualmente (usando <code>/etc/modules</code>) dei moduli come ppdev e tun.


== Da hotplug a udev ==
== Da hotplug a udev ==
Riga 75: Riga 75:
Nel passaggio da hotplug a udev i seguenti file di configurazione sono diventati obsoleti:
Nel passaggio da hotplug a udev i seguenti file di configurazione sono diventati obsoleti:


; <tt>/etc/hotplug/*.rc</tt> e <tt>*.agent</tt>: i vecchi file di hotplug non vengono più usati. Le regole di udev in <tt>/etc/udev/rules.d/</tt> possono essere usate per disabilitare selettivamente il coldplugging.
; <code>/etc/hotplug/*.rc</code> e <code>*.agent</code>: i vecchi file di hotplug non vengono più usati. Le regole di udev in <code>/etc/udev/rules.d/</code> possono essere usate per disabilitare selettivamente il coldplugging.


; <tt>/etc/hotplug/usb/*.usermap</tt>: devono essere sostituiti da regole udev.
; <code>/etc/hotplug/usb/*.usermap</code>: devono essere sostituiti da regole udev.


; <tt>/etc/hotplug/blacklist*</tt>: dovrebbero essere sostituite da direttive di configurazione di modprobe (ma per adesso modprobe processerà <tt>/etc/hotplug/blacklist.d/</tt>).
; <code>/etc/hotplug/blacklist*</code>: dovrebbero essere sostituite da direttive di configurazione di modprobe (ma per adesso modprobe processerà <code>/etc/hotplug/blacklist.d/</code>).


Inoltre dalla versione 0.072:
Inoltre dalla versione 0.072:


* tutti i file in <tt>/etc/udev/scripts/</tt> e <tt>/lib/hotplug/</tt> e alcuni file in <tt>/sbin/</tt> sono stati spostati in <tt>/lib/udev/</tt>. Non dimenticate di aggiornare le regole personalizzate, se ne avete create.
* tutti i file in <code>/etc/udev/scripts/</code> e <code>/lib/hotplug/</code> e alcuni file in <code>/sbin/</code> sono stati spostati in <code>/lib/udev/</code>. Non dimenticate di aggiornare le regole personalizzate, se ne avete create.


== La directory <tt>/etc/udev/rules.d/</tt> ==
== La directory <code>/etc/udev/rules.d/</code> ==


I file vengono letti e processati in ordine alfabetico, e le direttive contenute nelle regole vengono applicate in ordine. Le uniche eccezioni sono gli attributi NAME, di cui viene considerato solo il primo.
I file vengono letti e processati in ordine alfabetico, e le direttive contenute nelle regole vengono applicate in ordine. Le uniche eccezioni sono gli attributi NAME, di cui viene considerato solo il primo.
Riga 93: Riga 93:
Fino ad ora sono stati definiti:
Fino ad ora sono stati definiti:


; <tt>020_permissions.rules</tt>: imposta proprietario e permessi di default.
; <code>020_permissions.rules</code>: imposta proprietario e permessi di default.


; <tt>z50_run.rules</tt>: viene eseguito <tt>$REMOVE_CMD</tt>, e successivamente l'elaborazione dei device tty viene fermato con <tt>last_rule</tt>.
; <code>z50_run.rules</code>: viene eseguito <code>$REMOVE_CMD</code>, e successivamente l'elaborazione dei device tty viene fermato con <code>last_rule</code>.


; <tt>z70_hotplugd.rules</tt>: le opzioni di <tt>last_rule</tt> finiscono di processare gli eventi hotplug riguardanti "drivers" e "module" e vengono eseguiti i vecchi script in <tt>hotplug.d/</tt> e <tt>dev.d/</tt>.
; <code>z70_hotplugd.rules</code>: le opzioni di <code>last_rule</code> finiscono di processare gli eventi hotplug riguardanti "drivers" e "module" e vengono eseguiti i vecchi script in <code>hotplug.d/</code> e <code>dev.d/</code>.


E' fortemente sconsigliato di modificare i file nella directory <tt>/etc/udev/rules.d/</tt>, perchè il sistema di gestione dei pacchetti ([[Introduzione_all%27_Apt_System | APT]]) per default non aggiorna i file che vengono modificati dopo l'installazione.
È fortemente sconsigliato di modificare i file nella directory <code>/etc/udev/rules.d/</code>, perchè il sistema di gestione dei pacchetti ([[Introduzione_all%27_Apt_System | APT]]) per default non aggiorna i file che vengono modificati dopo l'installazione.


Per aggiungere delle regole personalizzate per un device è sufficiente inserirle in un file <tt>/etc/udev/rules.d/00_local.rules</tt> creato da voi. Il nome del file assicura che esso venga letto per primo, e questo ci permette di inserire delle regole che varranno eseguite <b>al posto</b> di quelle di default per lo stesso device.
Per aggiungere delle regole personalizzate per un device è sufficiente inserirle in un file <code>/etc/udev/rules.d/00_local.rules</code> creato da voi. Il nome del file assicura che esso venga letto per primo, e questo ci permette di inserire delle regole che varranno eseguite <b>al posto</b> di quelle di default per lo stesso device.


== Il file <tt>/etc/udev/links.conf</tt> ==
== Il file <code>/etc/udev/links.conf</code> ==


Purtroppo non tutti i driver hanno un'interfaccia sysfs, e in questo caso udev non sarà in grado di creare alcun device node in modo automatico. Il problema è evidente nel caso di driver sviluppati al di fuori dal kernel, e/o proprietari, su cui si può solo sperare che gli autori/manutentori implementino la funzionalità.
Purtroppo non tutti i driver hanno un'interfaccia sysfs, e in questo caso udev non sarà in grado di creare alcun device node in modo automatico. Il problema è evidente nel caso di driver sviluppati al di fuori dal kernel, e/o proprietari, su cui si può solo sperare che gli autori/manutentori implementino la funzionalità.


Nel frattempo abbiamo bisogno di un workaround: certo, uno script di avvio con i giusti comandi (vedi mknod, chmod, chown) può risolvere il problema, ma il pacchetto udev in Debian fornisce un altro mezzo più semplice: il file <tt>/etc/udev/links.conf</tt>.
Nel frattempo abbiamo bisogno di un workaround: certo, uno script di avvio con i giusti comandi (vedi mknod, chmod, chown) può risolvere il problema, ma il pacchetto udev in Debian fornisce un altro mezzo più semplice: il file <code>/etc/udev/links.conf</code>.


La sintassi del file è la seguente:
La sintassi del file è la seguente:
* Ogni riga vuota o che inizia con "#" viene trascurata.
* Ogni riga vuota o che inizia con "#" viene trascurata.
* Ogni riga che inizia con "L" dice ad udev di creare un link simbolico; dopo la L iniziale devono essere specificati due parametri separati da uno spazio o da un tab: il primo è il nome del link da creare nella directory <tt>/dev</tt>, e il secondo è il file a cui punta il link.
* Ogni riga che inizia con "L" dice ad udev di creare un link simbolico; dopo la L iniziale devono essere specificati due parametri separati da uno spazio o da un tab: il primo è il nome del link da creare nella directory <code>/dev</code>, e il secondo è il file a cui punta il link.
* Ogni riga che inizia con "D" dice ad udev di creare una sottodirectory della directory <tt>/dev</tt>, il cui nome deve essere specificato dopo uno spazio o un tab.
* Ogni riga che inizia con "D" dice ad udev di creare una sottodirectory della directory <code>/dev</code>, il cui nome deve essere specificato dopo uno spazio o un tab.
* Ogni riga che inizia con "M" dice ad udev di usare <tt>/dev/MAKEDEV</tt> per creare un device node, e di seguito devono essere indicati i parametri da passare a <tt>/dev/MAKEDEV</tt>, che sono, nell'ordine: il tipo di device, il major number e il minor number (per delucidazioni in merito vedere <tt>man mknod</tt>).
* Ogni riga che inizia con "M" dice ad udev di usare <code>/dev/MAKEDEV</code> per creare un device node, e di seguito devono essere indicati i parametri da passare a <code>/dev/MAKEDEV</code>, che sono, nell'ordine: il tipo di device, il major number e il minor number (per delucidazioni in merito vedere <code>man mknod</code>).


{{Warningbox|Coma già detto, il file <tt>/etc/udev/links.conf</tt> rappresenta un workaround, e come tale deve essere usato il meno possibile. In particolare, al fine di evitare conflitti e possibili ''race condition'', si raccomanda di <b>non usare mai</b> questo file per delle impostazioni che udev è in grado di fare in altro modo.}}
{{Warningbox|Coma già detto, il file <code>/etc/udev/links.conf</code> rappresenta un workaround, e come tale deve essere usato il meno possibile. In particolare, al fine di evitare conflitti e possibili ''race condition'', si raccomanda di <b>non usare mai</b> questo file per delle impostazioni che udev è in grado di fare in altro modo.}}


Per sottolineare il concetto riporto il commento del mantainer che appare in testa al file:
Per sottolineare il concetto riporto il commento del mantainer che appare in testa al file:
6 999

contributi