 |
|
Guida a udev su Gentoo 1.Cos'è udev? Quando 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 voi) utilizzano /dev/hda1 per indicare velocemente il proprio HD master sul primo controler IDE...giusto? Noi tutti sappiamo cosa sia un file di dispositivo. Qualcuno sa anche perchè questi file hanno diversi numeri quando quando si da un'occhiata più approfondita in /dev con un ls -l. Ma quello che noi tutti diamo per scontato è che quando ci riferiamo al primo HD sul primo controler IDE stiamo parlarlando di /dev/hda. Pensate 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 vostro lavoro fosse stampato invece che sulla vostra nuova stampante laser sulla vostra 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 assegnamento 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'assegnamento dei nomi ai dispositivi, fornito da LANANA, che è quello che viene 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. Successivamnte (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 si possono 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 percepisce che sono stati collegati o rimossi dei dispositivi, lancia il programma /sbin/hotplug. Hotplug a sua volta lancia i programmi che sono stati linkati nella directory /etc/hotplug.d/default, nella quale si trova anche un link simbolico all'eseguibile udev. Hotplug invia le informazioni fornite dal kernel al sistema udev che provvedere a aggiungere o rimuovere gli oppurtuni file di periferica dalla directory /dev. 2.Usare udev su Gentoo udev è stato pensato per funzionare in combinazione con i kernel 2.6 (come per esempio vanilla-sources o gentoo-sources con il profilo di default 2005.0). Oltre a avere installato un kernel 2.6 è necessario avere installato sul proprio sistema anche la versione piu' recente di sys-apps/baselayout.
udev installa come dipendenza anche il paccheto sys-apps/hotplug-base. Non é necessario installare hotplug a meno che non si voglia che i moduli del kernel vengano caricati quando si collega uan periferica ala sistema. hotplug si occupa anche di attivare le interfacce di rete.
Se si vuole che vengano caricati i moduli per le periferiche che sono state collegate al sistema prima del boot é necessario installare il pacchetto sys-apps/coldplug.
Assicuratevi di aver aggiunto coldplug al runlevel utilizzato:
e ricordatevi di attivare le segueti opzioni nel kernel:
Se si desidera si puo' mantenere attiva anche l'opzione /dev file system support (OBSOLETE), ma bisogna assicurarsi che l'opzione "Automatically mount at boot" sia disattivata.
Se si utilizza genkernel bisogna lanciarlo con l'opzione --udev per attivare tutte le opzioni del kernel necessarie al funzionamento di udev. Se volete utilizzare la versione gentoo di udev creata per semplificarvi la vita allora avete finito. Gentoo utilizzerà udev ma continuerà a mantenere un link statico in /dev in modo che non vi macherà 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 siete duri a morire e volete un sistema udev puro, senza il trucchetto precedente, cosa che peraltro è contemplata dai suoi sviluppatori (incluso il problema dei dispositivi mancanti visto che ancora udev non li supporta), continuate a leggere. La prima cosa da fare è quella di distattivare la regola che salva la struttura dei device in un tarball allo spegnimento del PC: editate la variabile RC_DEVICE_TARBALL in /etc/conf.d/rc e impostatela su 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. 3.Problemi Noti File di dispositivo mancanti all'avvio Se non si riesce a 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 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 incoveniente 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 dispositivo 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 viasualizzati durante il test precendente vanno creati manualmente. I comandi seguenti vanno eseguiti nella directory test/dev/ creata precentemente:
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:
Usando udev e LVM2 insieme, è possibile che che i volumi logici creati non appaiano nella directory /dev. In realta' questi device si chiamano /dev/dm-# dove # sta per un numero intero. Per coreggere questo errore bisogna modificare il file /etc/udev/rules.d/50-udev.rules decommentando la seguente linea:
Dopo, installate sys-fs/multipath-tools che contiene le applicazioni devmap_name.
Assegnamento dei nomi differente tra DevFS e udev Nonostante l'intento di mantere 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 piu'. Assicurarsi che nel proprio file di configurazione di X il percorso del dispositivo del mouse punti a un file esistente. Se il file corrispondente a un dispositivo 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 si provi a installare sys-apps/baselayout-1.8.12, o 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 precendente alla versione 2.6.4 è necessario includere esplicitamente il supporto per il filesystem /dev/pts.
4.Risorse & Riconoscimenti 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. |
|
