Guida a udev su GentooQuando gli utenti linux parlano del proprio hardware in presenza di persone che pensano linux sia una sorta di strano virus od una nuova marca di caffè, l'utilizzo di termini come "slash dev slash foo" vengono accolti con strani sguardi. Ma alcuni fortunati utenti (che probabilmente includono anche chi sta leggendo) utilizzano /dev/hda1 per indicare velocemente il proprio HD master sul primo controller IDE...giusto? Tutti sanno cosa sia un file di periferica. Qualcuno sa anche perché questi file hanno diversi numeri quando si da un'occhiata più approfondita in /dev con un ls -l. Ma quello che si dà per scontato è che quando ci si riferisce al primo HD sul primo controller IDE si parla di /dev/hda. Si pensi alle periferiche PlugNPlay come le penne USB, IEEE1394, periferiche PCI hot-swappable...qual è la prima periferica? E per quanto tempo? Come si chiameranno le altre periferiche quando la prima verrà sconnessa? Questo come influenzerà i flussi di dati in corso? Non sarebbe divertente che il proprio lavoro venisse stampato, invece che sulla nuova stampante laser, sulla propria sgangherata stampate ad aghi, solamente perché qualcuno ha deciso di staccare la spina alla stampante laser che era vista dal sistema come primaria? Le finalità del progetto udev sono sia interessanti che necessarie:
Per fornire queste caratteristiche, udev è sviluppato in tre diversi progetti: namedev, libsysfs e, ovviamente, udev. namedev consente di definire i nomi delle periferiche indipendentemente dal programma udev. Questo permette di avere uno modello di assegnazione dei nomi molto flessibile ed uno schema dei nomi sviluppato da diverse entità. Questo sistema per assegnare i nomi ai dispositivi offre un'interfaccia standard con cui udev può interfacciarsi Attualmente namedev fornisce un solo modello per l'assegnazione dei nomi ai dispositivi, fornito da LANANA, modello attualmente usato dalla maggior parte dei sistemi Linux e quindi piuttosto indicato per la maggior parte degli utenti Linux. namedev usa un procedimento suddiviso in cinque passi per assegnare un nome a una data periferica. Se si trova un nome per la periferica durante uno di questi passi, viene usato questo nome e la procedura si interrompe. I cinque passi, nell'ordine, sono:
Il primo passaggio (etichetta o numero seriale) controlla se la periferica ha un identificatore univoco. Per esempio i dispositivi USB hanno un numero seriale unico; le periferiche SCSI hanno un UUID unico. Se nel file di configurazione in uso esiste una regola che assegna il nome al dispositivo in base a questo identificatore, namedev applica la regola e assegna il nome alla periferica. Successivamente (numero della periferica sul bus) viene controllato il numero con cui il dispositivo viene identificato sul bus . Per esempio i numeri assegnati ai dispositivi sul bus PCI cambiano di rado durante il ciclo di vita di un sistema, per cui questo si può considerare un buon metodo per assegnare un nome a una periferica PCI (non-hot-swappable). Si può assegnare un nome a un dispositivo anche sulla base di come questo è fisicamente collegato al bus (topologia del bus), anche questo è un metodo abbastanza valido per identificare univocamente una periferica, almeno fino a quando non viene variata la disposizione fisica dei dispositivi all'interno del sistema. È possibile definire una regola che sostituisca staticamente (nome assegnato staticamente), al nome fornito dal kernel, una stringa arbitraria. Se non esistono regole per assegnare un nome a un dispositivo, il comportamento predefinito di udev è di assegnare alla periferica il nome fornito dal kernel (nome fornito dal kernel). Nella maggior parte dei casi questo è sufficiente visto che il nome corrisponde a quello assegnato. udev interagisce con il kernel tramite il filesystem sysfs. Il progetto libsysfs mette a disposizione un API per accedere alle informazione fornite dal filesystem sysfs. Questo consente di poter interrogare qualunque tipo di dispositivo hardware senza doversi preoccupare di che tipo di hardware si tratti. Ogni volta che il kernel riceve un evento nella struttura dei dispositivi, chiede ad udev di controllare. udev segue le regole contenute nella directory /etc/udev/rules.d/, successivamente usa le informazioni date dal kernel per eseguire le azioni necessarie nella struttura di /dev (creando o eliminando file di periferica). udev è stato pensato per funzionare in combinazione con i kernel 2.6 (come per esempio gentoo-sources con il profilo di default 2007.0). Oltre ad avere installato un kernel 2.6 è necessario avere installato sul proprio sistema anche la versione più recente di sys-apps/baselayout.
Ricordarsi inoltre di attivare le seguenti opzioni nel kernel:
Se si utilizza genkernel non occorre fare nulla di speciale. Genkernel imposterà udev in modo predefinito. Se si è voluto utilizzare le impostazioni specifiche per Gentoo di udev creata per semplificare la vita all'utente allora la procedura è terminata. Gentoo utilizzerà udev ma continuerà a mantenere un link statico in /dev in modo che non mancherà mai il nodo ad un particolare dispositivo. Gli script init di Gentoo non avvieranno più il servizio devfsd e disattiveranno devfs al boot. Ma se si vuole un sistema udev puro, senza modifiche, cosa che peraltro è contemplata dai suoi sviluppatori (incluso il problema dei dispositivi mancanti visto che ancora udev non li supporta), proseguire nella lettura. La prima cosa da fare è quella di disattivare la regola che salva la struttura dei dispositivi in un archivio tarball allo spegnimento del PC: modificare la variabile RC_DEVICE_TARBALL in /etc/conf.d/rc e impostarla a no:
Se si è lasciato attivo il supporto a devfs nel kernel lo si può disattivare nel file di configurazione del bootloader aggiungendo il parametro del kernel gentoo=nodevfs. Se invece si volesse riattivare il supporto a devfs disabilitando udev, si dovrà passare al kernel il parametro gentoo=noudev. File di periferica mancanti all'avvio Se non si riesce ad avviare il sistema con successo perché si ottiene un errore che dice che il file /dev/null non è stato trovato, o perché la console iniziale non esiste, il problema è dovuto alla mancanza di alcuni file che devono essere presenti nel sistema prima che /dev venga montato e udev inizi a gestirlo. Questo è un errore piuttosto comune sui sistemi Gentoo installati usando supporti vecchi. Avendo installato sys-apps/baselayout-1.8.12, o più recente, questo inconveniente dovrebbe essere alleviato dal fatto che il sistema dovrebbe essere comunque in grado di avviarsi. Comunque, per evitare noiosi avvisi, è sufficiente creare i file di periferica mancanti, come descritto in seguito. Per visualizzare i dispositivi che sono disponibili prima che il filesystem /dev venga montato bisogna eseguire i seguenti comandi:
I dispositivi necessari per avviare correttamente il sistema sono /dev/null e /dev/console. Se non vengono visualizzati durante il test precedente vanno creati manualmente. I comandi seguenti vanno eseguiti nella directory test/dev/ creata in precedenza:
Quando si sono impartiti questi comandi è necessario ricordarsi di smontare la directory test/:
Nel caso si usassero i driver proprietari di nVidia e il server grafico X non partisse, in un sistema configurato per utilizzare solo udev, bisogna assicurarsi che:
Assegnazione differente dei nomi tra DevFS e udev Nonostante l'intento di mantenere inalterati i nomi assegnati ai dispositivi da entrambi i sistemi di gestione, in qualche caso può capitare che ci siano delle differenze tra il nome assegnato da DevFS e quello assegnato da udev. Un caso conosciuto riguarda il controller RAID HP Smart Array 5i (più precisamente il modulo del kernel cciss). Con udev, il dispositivo viene chiamato /dev/cciss/cXdYpZ dove X, Y e Z sono numeri. Con devfs, il dispositivo si chiama /dev/hostX/targetY/partZ o é un link simbolico a /dev/cciss/cXdY. In questo caso é necessario ricordarsi di modificare il file /etc/fstab e i file di configurazione del bootloader. La stessa cosa succede con molti dei link simbolici che venivano creati in /dev, come per esempio /dev/mouse, che ora udev non crea più. Assicurarsi che nel proprio file di configurazione di X il percorso del dispositivo del mouse punti ad un file esistente. Un'altro problema è nella differenza di denominazione dei terminali tra devfs e udev. Mentre in devfs i terminali vengono chiamati tty, udev li chiama vc e tty. Ciò può dare dei problemi nel caso siano state applicate delle restrizioni, attraverso l'uso di /etc/securetty, riguardo le login da utente root. Assicurarsi che entrambe le voci tty1 e vc/1 siano elencate nel file di configurazione /etc/securetty, per permettere a root di effettuare il login tramite la console. Rinominare i dispositivi a blocchi Le versioni recenti di udev (dalla 104 in poi) unitamente alle nuove versioni del kernel (2.6.19 e successive) potrebbero cambiare i nomi di dispositivo dei propri dischi, a causa di una modifica nell'implementazione del kernel riguardo a libata: per esempio una periferica CD-RW mappata in precedenza come /dev/hdc potrebbe cambiare in /dev/sr0. Mentre questo di norma non rappresenta un problema, potrebbe dare dei problemi a qualche applicazione che ha codificato internamente la ricerca dei dispositivi in altre locazioni. Per esempio, media-sound/rip si aspetta di trovare i dischi in /dev/cdrom, e ciò diventa un problema se si usa un nuovo kernel e udev rinomina il proprio dispositivo in /dev/cdrom1. Per aggirare questi problemi, bisogna modificare /etc/udev/rules.d/70-persistent-cd.rules e assegnare il nome corretto al dispositivo. Per ulteriori informazioni riguardanti la scrittura di regole per udev, assicurarsi di leggere la guida di Daniel Drake. Rinominare i dispositivi di rete Talvolta disconnettendo e riconnettendo un disposirivo di rete (come una scheda USB WiFi) essa può venire rinominata ogni volta, incrementandone il numero di un'unità. Quando ciò accade, la si vedrà diventare wlan0, wlan1, wlan2, ecc. Ciò avviene perchè udev sta aggiungendo delle regole aggiuntive al proprio file delle regole, invece di ricaricare le regole esistenti. Siccome udev controlla la propria directory delle regole tramite inotify, bisogna avere il supporto a inotify nella propria configurazione del kernel:
Ora udev ricorderà correttamente i nomi dei propri dispositivi di rete. udev carica i moduli in un ordine non previsto Qualche volta udev carica i moduli in un ordine non indesiderato, non previsto o abbastanza casuale. Tale comportamento è abbastanza comune in special modo per i sistemi che hanno dispositivi multipli dello stesso tipo, per esempio periferiche multimediali. Questo influenza i numeri assegnati ai dispositivi; per esempio, nelle schede sonore talvolta potrebbero invertirsi di numero. Ci sono alcune soluzioni per correggere la numerazione dei dispositivi e/o l'ordine di caricamento dei moduli. Idealmente, basterebbe usare i parametri del modulo per specificare il numero di dispositivo desiderato. Alcuni moduli, come ALSA, include il parametro "index" (indice, ndt). I moduli che usano il parametro index possono essere adeguati come mostrato. Questo esempio è per sistemi con due schede sonore. La scheda con un indice uguale a 0 viene designata come prima scheda. Una volta che i parametri vengono modificati, i file di configurazione del modulo devono essere aggiornati.
L'esempio precedente è la soluzione preferibile, purtroppo non tutti i moduli supportano dei parametri come index. Per tali moduli, bisogna forzare il loro corretto ordine di caricamento. Per prima cosa, bisogna impedire ad udev di caricare automaticamente i moduli inserendoli in una "lista nera" (blacklist). Assicurarsi di usare il nome esatto del modulo che viene caricato. Per i dispositivi PCI, bisogna usare i nomi dei moduli ottenuti dall'output di lspci -k, disponibile nel pacchetto pciutils. L'esempio seguente usa i moduli DVB.
Successivamente, caricare i moduli nell'ordine corretto. Aggiungerli al file /etc/modules.autoload.d/kernel-2.6 nell'ordine esatto con cui si desidera vengano caricati.
Se il file corrispondente ad una periferica non viene creato quando si carica il modulo relativo tramite il file /etc/modules.autoload.d/kernel-2.6, ma compare caricando manualmente il modulo tramite modprobe, provare ad installare sys-apps/baselayout-1.8.12, o una versione più recente. Il supporto per i dispositivi framebuffer (/dev/fb/*) è stato introdotto a partire dalla versione 2.6.6-rc2 del kernel. Nel caso si usasse un kernel precedente alla versione 2.6.4 è necessario includere esplicitamente il supporto per il filesystem /dev/pts.
La conferenza sul sistema udev tenuta da Greg Kroah-Hartman (IBM Corporation) al Linux Symposium (Ottawa, Canada - 2003) è un ottimo punto di partenza per una buona comprensione di udev. Decibel's UDEV Primer è un documento molto approfondito riguardo all'uso di udev su Gentoo. Writing udev rules, scritto dallo sviluppatore di Gentoo Daniel Drake, è un documento eccellente per imparare come personalizzare la proprio installazione di udev. I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike. |
|