Old:Udev e Debian: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
m (spaziatura/box iniziale)
 
(27 versioni intermedie di 8 utenti non mostrate)
Riga 1: Riga 1:
== INSTALLAZIONE QEMU + KQEMU PER DEBIAN / UBUNTU ==
{{Old|Per le versioni attualmente supportate di Debian, si raccomanda [[Udev|quest'altra guida Wiki]].}}
<!-- TEMPLATE RIMOSSO
{{File_System
|precedente=File_System
|successivo=LVM:_Logical_Volume_Manager
}}
-->
= Disclaimer =
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.


1. Assicuratevi di aver installato i pacchetti necessari a compilare il tutto:
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.
* '''gcc-3.3''' oppure '''gcc-3.4''' (qemu non � ancora compilabile col gcc 4.0)
* '''libsdl1.2-dev'''
* '''zlib1g-dev'''
* '''make'''
* '''kernel-headers-'''''versione_del_kernel_in_uso'' (oppure '''linux-headers-'''''versione_del_kernel_in_uso'' se avete una Ubuntu od usate una Debian unstable con un kernel recente). La versione pu� essere individuata eseguendo il comando <code>uname -r</code>.


2. Scaricate da [http://fabrice.bellard.free.fr/qemu/download.html http://fabrice.bellard.free.fr/qemu/download.html] gli archivi dei codici sorgenti di QEMU e di KQEMU, e scompattateli in modo che la directory di kqemu venga estratta all'interno della directory di qemu. Quindi entrate nella directory dei sorgenti.
= Il sottosistema hotplug =


Esempio:
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.
<pre>
Nell'evoluzione del kernel Linux questo servizio ha subito diverse modifiche, nel tentativo di migliorare ogni volta in termini di prestazioni e flessibilità.
rob@klingon:/home/rob$ tar zxvf qemu-0.7.2.tar.gz
 
rob@klingon:/home/rob$ tar zxvf kqemu-0.7.2.tar.gz -C qemu-0.7.2
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.
rob@klingon:/home/rob$ cd qemu-0.7.2</pre>
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.
 
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.
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;
* sempre a causa della sua natura di script, occupa molto più spazio di un programma C, considerato anche che necessita dell'interprete <code>/bin/sh</code>. Anche questo fattore non tocca direttamente un utente comune, ma è invece fondamentale per chi sta riorganizzando il processo di boot per implementare un sistema di hotplug dentro ad un nuovo tipo di initrd: l'initramfs;
* deve funzionare anche sui kernel 2.4, quindi non si appoggia al sysfs, perdendo in performance e funzionalità;
* necessita di una directory <code>/dev</code> statica (nota che il devfs è ormai in disuso).
 
= Cos'è udev =
 
Udev è un programma in userspace in grado ricevere le notifiche del sottosistema hotplug dei kernel 2.6.<br/> 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.


3. Configurate l'ambiente di compilazione avviando lo script <code>./configure</code>.  
Udev è un programma molto potente e flessibile che, occupandosi direttamente della creazione dei file di dispositivo (device file), permette un controllo molto accurato nella gestione degli stessi, dando la possibilità all'amministratore di impostare in modo personalizzato tutti i loro attributi (nome, permessi, proprietario, ecc.).
Verificate che sia tutto ok e che il supporto kqemu sia attivato, in modo che venga compilato
Tramite delle regole (udev rules) si possono assegnare nomi fissi a determinati dispositivi (a prescindere, ad esempio, dalla porta usata per collegare la periferica). Inoltre è possibile richiamare un certo programma/script non appena un dispositivo viene riconosciuto dal sistema.
il modulo corretto per il vostro kernel. Poi compilate il tutto ed installate.


Esempio:
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.
<pre>
rob@klingon:/home/rob/qemu-0.7.2$ ./configure --cc=gcc-3.3
rob@klingon:/home/rob/qemu-0.7.2$ make</pre>


Se dopo aver avviato <code>make</code> ci sono errori di compilazione, ci si pu� limitare a compilare il solo modulo di emulazione x86, aggiungendo l'opzione <code>--target-list=i386-softmmu</code> al comando <code>./configure</code>.
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.
<pre>
rob@klingon:/home/rob/qemu-0.7.2$ make clean
rob@klingon:/home/rob/qemu-0.7.2$ ./configure --cc=gcc-3.3 --target-list=i386-softmmu
rob@klingon:/home/rob/qemu-0.7.2$ make</pre>


Se non ci sono errori, ora potete diventare root ed installare qemu.
In '''Etch''' (attuale testing) e '''Sid''' udev ha invece sostituito anche Hotplug.


<pre>
Questa guida è dedicata alla versione di udev attualmente in Etch.
rob@klingon:/home/rob/qemu-0.7.2# su
Password:
rob@klingon:/home/rob/qemu-0.7.2# make install</pre>


A questo punto qemu � installato in <code>/usr/local/bin/qemu</code>, ed il modulo kqemu si trova in <code>/lib/modules/''versione_del_kernel''/misc/kqemu.ko</code>.
= Il nuovo udev =


4. Prima di eseguire qemu va caricato il modulo del kernel <code>kqemu</code>, va eventualmente creato <code>/dev/kqemu</code> (usato per interagire col kernel) e gli vanno dati permessi adeguati.  
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.


Esempio di procedura manuale (per chi '''non ha''' installato il pacchetto udev):'''
Per usare questa versione di udev è necessario un kernel 2.6.12 o superiore con le opzioni hotplug (<code>CONFIG_HOTPLUG</code>) e tmpfs (<code>CONFIG_TMPFS</code>) attivate. Le opzioni <code>CONFIG_PNP</code>, <code>CONFIG_ISAPNP</code>, <code>CONFIG_PNPBIOS</code> e <code>CONFIG_PNPACPI</code> sono altamente raccomandate per consentire il caricamento automatico di importanti driver.
<pre>
# Queste due operazioni sono da fare come root una volta sola:
rob@klingon:/home/rob/qemu-0.7.2# mknod /dev/kqemu c 250 0
rob@klingon:/home/rob/qemu-0.7.2# chmod 666 /dev/kqemu


# Questa operazione va eseguita come root ad ogni avvio del sistema
A partire dal kernel 2.6.15-rc1 è stata introdotta la nuova implementazione del driver model, la quale presenta nuove caratteristiche ed 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.
rob@klingon:/home/rob/qemu-0.7.2# modprobe kqemu</pre>


Esempio di procedura manuale (per chi '''ha''' installato il pacchetto udev):
Il pacchetto hotplug deve essere rimosso manualmente, anche se non dovrebbe creare problemi se restasse installato.
<pre>
# Queste due operazioni vanno eseguite come root ad ogni avvio del sistema
rob@klingon:/home/rob/qemu-0.7.2# modprobe kqemu major=0
rob@klingon:/home/rob/qemu-0.7.2# chmod 666 /dev/kqemu</pre>


Per far eseguire '''automaticamente''' queste operazioni ad ogni avvio del sistema (consigliato):
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.
* diventate root (<code>su -</code>)
* modificate il file <code>/etc/modules</code> aggiungendo la riga <code>kqemu</code>, in modo che il modulo venga automaticamente caricato al boot.
* create il file <code>/etc/modprobe.d/kqemu</code> contenente le seguenti righe:
** per chi '''non ha''' installato il pacchetto udev:
<pre>
install kqemu /sbin/modprobe --ignore-install kqemu \
&& (test -c /dev/kqemu || mknod /dev/keqmu c 250 0) \
&& chmod 666 /dev/kqemu</pre>
:* per chi '''ha''' installato il pacchetto udev:
<pre>
options kqemu major=0
install kqemu /sbin/modprobe --ignore-install kqemu && chmod 666 /dev/kqemu</pre>


Una volta caricato il modulo e dati i permessi di lettura a /dev/kqemu siamo pronti per eseguire il nuovo qemu.
= Come funziona udev =
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.


Accertatevi che il qemu che andrete ad eseguire '''sia quello compilato in <code>/usr/local/bin/qemu</code>''': potete farlo eseguendo <code>type qemu</code>.
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>).


5. (facoltativo) Creazione di un file immagine per il disco (facoltativo)
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!


<pre>
* 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 ;-));
rob@klingon:/home/rob$ qemu-img create hd.img 3500M
</pre>


6. Eseguiamo qemu:
* 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;
(cambiare il boot per fare l'installazione da cd etc..)


Per semplicita` qui avviamo qemu da root (gli utenti comuni in Debian solitamente non possono leggere direttamente /dev/cdrom), tuttavia qemu puo` tranquillamente essere eseguito come utente comune (consigliato).
* 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>.


<pre>
In altre parole, su un tipico sistema si potrebbero dover caricare manualmente (usando <code>/etc/modules</code>) dei moduli come ppdev e tun.
rob@klingon# qemu -boot c -cdrom /dev/cdrom -hda /home/rob/hd.img \
              -user-net -pci -m 256 -k it -localtime
</pre>


Le principali opzioni di qemu sono:
= Da hotplug a udev =


* '''-m ''megabyte'' ''' --> memoria per l'emulatore = 256MB
Nel passaggio da hotplug a udev i seguenti file di configurazione sono diventati obsoleti:
* '''-k it''' --> tastiera italiana
* '''-localtime''' --> usa ora locale (default UTC)
* '''-pci''' --> emula scheda di rete rtl8029 PCI
* '''-boot c''' --> avvia dal dico rigido emulato (usare '''-boot d''' per il boot dal cdrom emulato)
* '''-user-net''' --> Il sistema GUEST deve essere configurato in DHCP. Qemu assegna un indirizzo dinamico "10.0.2.15" al SO guest, il quale sar� in grado di pingare solo il suo GW che � "10.0.2.2". Per testare la rete quindi avviare le applicazioni di rete, visto che il ping ''host'' non funziona.


=== Qemu Networking ===
; <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.


Con la soluzione indicata qui sopra, il sistema Guest riesce a navigare in Internet, ma non riesce ad accedere alle risorse del proprio host. La maniera pi� facile per configurare qemu in modo che possa fare entrambe le cose, � quella di installare vde e usare tun/tap con un bridge.
; <code>/etc/hotplug/usb/*.usermap</code>: devono essere sostituiti da regole udev.


Prima di iniziare, dovete verificare che il vostro kernel supporti i seguenti moduli:
; <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>).
  tun: "Network device support" -> "Universal TUN/TAP device driver support"
  IP masquerade: "Networking options" -> "IP: Netfilter Configuration"
  bridging: "Networking options" -> "802.1d Ethernet Bridging"


e dovete installare il pacchetto bridge-utils:
Inoltre dalla versione 0.072:
<pre>
apt-get install bridge-utils
</pre>


[http://vde.sourceforge.net Vde] sta per Virtual Distributed Ethernet ed � un programma open source che vi permette di creare un network virtuale. Noi lo utilizzeremo per far fare in modo che il sistema Guest veda se stesso come un'unit� distinta dal sistema host e possa colloquiare con questi.
* 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.


Per quel che ne so io, non esiste (ancora) un pacchetto deb gi� pronto per l'uso, ma per installare vde sono sufficenti poche righe:
= La directory <code>/etc/udev/rules.d/</code> =
<pre>
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 <code>NAME</code>, di cui viene considerato solo il primo.
wget http://puzzle.dl.sourceforge.net/sourceforge/vde/vde-1.5.9.tar.gz
tar -xvzf vde-1.5.9.tar.gz
cd vde-1.5.9
./configure
make
make install
</pre>


Una volta fatto questo, siete pronti per configurare tun e il bridge:
Poiché l'ordine è importante, alcuni di questi file hanno un nome particolare, per far sì che vengano letti prima o dopo di altri, e devono essere opportunamente considerati quando si aggiungono regole personalizzate.


<pre>
Fino ad ora sono stati definiti:
vde_switch -tap tun0 -daemon
chmod 777 /tmp/vde.ctl


ifconfig eth0 down
; <code>020_permissions.rules</code>: imposta proprietario e permessi di default.
brctl addbr br0
ifconfig eth0 0.0.0.0 promisc up
ifconfig tun0 0.0.0.0 promisc up
#l'IP qui sotto � quello del computer host; modificatelo per adeguarlo alle vs esigenze
ifconfig br0 192.168.0.200 netmask 255.255.255.0 broadcast 192.168.0.255 up


brctl stp br0 off
; <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>.
brctl setfd br0 1
brctl sethello br0 1
brctl addif br0 eth0
brctl addif br0 tun0
#questo invece � l'indirizzo IP del gateway
route add default gw 192.168.0.1
</pre>


NB: Una volta verificato che tutto funziona, queste istruzioni vanno inserite in uno script in modo da essere eseguite automaticamente all'accensione del computer
; <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>.
qui ne trovate uno piuttosto grezzo: [http://www.itaca.coopsoc.it/download/sources/vde_qemu vde_qemu], che va salvato in /etc/init.d. Dopodich�: <pre>chmod u+x /etc/init.d/vde_qemu
update-rc.d -n vde_qemu defaults 90</pre>


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


Ora tutto � pronto per lanciare qemu, con l'ultima avvertenza che dovete usare l'apposito wrapper vdeqemu:
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.
<pre>
vdeqemu -hda disk.img -localtime
</pre>


Potete utilizzare tutte le opzioni di qemu, fuorch� -user-net, che disattiverebbe tun.
= Il file <code>/etc/udev/links.conf</code> =


Ora il sistema guest dovrebbe accedere a tutte le porte del sistema host, in maniera totalmente trasparente: da risorse di rete dovreste vedere il vostro server samba con le sue partizioni; dal browser dovreste accedere alle pagine del vostro server web, etc. etc.
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à.


=== PATCH PER WINDOWS ===
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>.


Per quanto riguarda l'utilizzo della CPU, a quanto pare
La sintassi del file è la seguente:
Windows 9x non fa un uso corretto della istruzione CPU HLT e  
* Ogni riga vuota o che inizia con <code>#</code> viene trascurata.
quindi spara la cpu a 100% quando � in idle (non fa nulla) e
* Ogni riga che inizia con <code>L</code> dice ad udev di creare un link simbolico; dopo la <code>L</code> 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.
invece la usa regolarmente quando � sotto "sforzo", paradossalmente
* Ogni riga che inizia con <code>D</code> dice ad udev di creare una sottodirectory della directory <code>/dev</code>, il cui nome deve essere specificato dopo uno spazio o un tab.
infatti, se viene utilizzata la cpu di qemu l'utilizzo di
* Ogni riga che inizia con <code>M</code> 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>).
cpu si abbassa su linux in proporzione.


la patch puo' essere scaricata qui, va installata sul Win9x GUEST.
{{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.}}


[http://klingon.homelinux.net/files/amnhltm.zip http://klingon.homelinux.net/files/amnhltm.zip]
Per sottolineare il concetto riporto il commento del mantainer che appare in testa al file:
<pre>
# This file does not exist. Please do not ask the debian maintainer about it.
# You may use it to do strange and wonderful things, at your risk.
</pre>
che si legge:


''Questo file non esiste. Vi prego di non chiedere al mantainer Debian di questo file. Potete usarlo per fare cose strane e meravigliose, a vostro rischio.''


Link utili (in inglese):
= Approfondimenti =


*[http://ubuntuforums.org/showthread.php?t=39513 http://ubuntuforums.org/showthread.php?t=39513]
=== Sitografia ===
*[http://fabrice.bellard.free.fr/qemu/index.html http://fabrice.bellard.free.fr/qemu/index.html]
* [http://www.debianhelp.co.uk/udev.htm Rename Network Interface using udev in Debian]
*[http://fabrice.bellard.free.fr/qemu/qemu-doc.html http://fabrice.bellard.free.fr/qemu/qemu-doc.html]
* [http://www.debian-administration.org/articles/126 Card Readers and USB keys using udev]
*[http://www.debian-administration.org/?article=40 http://www.debian-administration.org/?article=40]
* [http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html udev Homepage]
*[http://oui.com.br/n/content.php?article.21 http://oui.com.br/n/content.php?article.21]
* [http://www.reactivated.net/udevrules.php Writing udev rules]
*[http://www.carlsonhome.net/computer_help_log.php http://www.carlsonhome.net/computer_help_log.php]


--
{{Autori
[[Utente:Themonkey|Themonkey]] 20:31, Ago 19, 2005 (EDT)
|Autore=[[Utente:TheNoise|TheNoise]]
The_monk_ey ( skype: the_monk_ey )
}}

Versione attuale delle 11:45, 25 giu 2016

Emblem-important.png Attenzione. Questa guida è obsoleta. Viene mantenuta sul Wiki solo per motivi di natura storica e didattica.
Per le versioni attualmente supportate di Debian, si raccomanda quest'altra guida Wiki.


Disclaimer

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 /usr/share/doc/udev/. Si prega di correggere o segnalare ogni possibile (e probabile) inesattezza.

Il sottosistema hotplug

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 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 /proc, e i file di dispositivo erano creati staticamente: nella directory /dev 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.

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 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 /dev).

Prima di udev il programma che svolgeva questo compito era stato chiamato, con poca fantasia, hotplug. 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;
  • sempre a causa della sua natura di script, occupa molto più spazio di un programma C, considerato anche che necessita dell'interprete /bin/sh. Anche questo fattore non tocca direttamente un utente comune, ma è invece fondamentale per chi sta riorganizzando il processo di boot per implementare un sistema di hotplug dentro ad un nuovo tipo di initrd: l'initramfs;
  • deve funzionare anche sui kernel 2.4, quindi non si appoggia al sysfs, perdendo in performance e funzionalità;
  • necessita di una directory /dev statica (nota che il devfs è ormai in disuso).

Cos'è udev

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 /dev) 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 è un programma molto potente e flessibile che, occupandosi direttamente della creazione dei file di dispositivo (device file), permette un controllo molto accurato nella gestione degli stessi, dando la possibilità all'amministratore di impostare in modo personalizzato tutti i loro attributi (nome, permessi, proprietario, ecc.). Tramite delle regole (udev rules) si possono assegnare nomi fissi a determinati dispositivi (a prescindere, ad esempio, dalla porta usata per collegare la periferica). Inoltre è possibile richiamare un certo programma/script non appena un dispositivo viene riconosciuto dal sistema.

Udev non si occupa tuttavia di caricare i moduli necessari al funzionamento del dispositivo, infatti questi devono 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.

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

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

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 usb-storage 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 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 caratteristiche ed 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.

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 UDEV_DISABLED=yes in Grub o lilo. Alternativamente si può configurare in /etc/udev/udev.conf una directory diversa da /dev per la creazione dei device file.

Come funziona udev

Quando un driver viene caricato, rende disponibili delle informazioni in /sys 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 /sbin/hotplug bensì da /sbin/udevsend (il gestore degli eventi hotplug è indicato in /proc/sys/kernel/hotplug).

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!
  • 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 ;-));
  • 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 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 /etc/udev/links.conf.

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

Da hotplug a udev

Nel passaggio da hotplug a udev i seguenti file di configurazione sono diventati obsoleti:

/etc/hotplug/*.rc e *.agent
i vecchi file di hotplug non vengono più usati. Le regole di udev in /etc/udev/rules.d/ possono essere usate per disabilitare selettivamente il coldplugging.
/etc/hotplug/usb/*.usermap
devono essere sostituiti da regole udev.
/etc/hotplug/blacklist*
dovrebbero essere sostituite da direttive di configurazione di modprobe (ma per adesso modprobe processerà /etc/hotplug/blacklist.d/).

Inoltre dalla versione 0.072:

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

La directory /etc/udev/rules.d/

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.

Poiché l'ordine è importante, alcuni di questi file hanno un nome particolare, per far sì che vengano letti prima o dopo di altri, e devono essere opportunamente considerati quando si aggiungono regole personalizzate.

Fino ad ora sono stati definiti:

020_permissions.rules
imposta proprietario e permessi di default.
z50_run.rules
viene eseguito $REMOVE_CMD, e successivamente l'elaborazione dei device tty viene fermato con last_rule.
z70_hotplugd.rules
le opzioni di last_rule finiscono di processare gli eventi hotplug riguardanti "drivers" e "module" e vengono eseguiti i vecchi script in hotplug.d/ e dev.d/.

È fortemente sconsigliato di modificare i file nella directory /etc/udev/rules.d/, perchè il sistema di gestione dei pacchetti (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 /etc/udev/rules.d/00_local.rules 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 al posto di quelle di default per lo stesso device.

Il file /etc/udev/links.conf

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 /etc/udev/links.conf.

La sintassi del file è la seguente:

  • 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 /dev, 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 /dev, il cui nome deve essere specificato dopo uno spazio o un tab.
  • Ogni riga che inizia con M dice ad udev di usare /dev/MAKEDEV per creare un device node, e di seguito devono essere indicati i parametri da passare a /dev/MAKEDEV, che sono, nell'ordine: il tipo di device, il major number e il minor number (per delucidazioni in merito vedere man mknod).
Warning.png ATTENZIONE
Coma già detto, il file /etc/udev/links.conf 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 non usare mai 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: 

# This file does not exist. Please do not ask the debian maintainer about it.
# You may use it to do strange and wonderful things, at your risk.

che si legge:

Questo file non esiste. Vi prego di non chiedere al mantainer Debian di questo file. Potete usarlo per fare cose strane e meravigliose, a vostro rischio.

Approfondimenti

Sitografia



Guida scritta da: TheNoise Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

Verificare ed estendere la guida | Cos'è una guida Debianized


Estratto da "https://guide.debianizzati.org/index.php?title=Old:Udev_e_Debian&oldid=41569"