Attachment 103889 Details for Bug 157953 – udev-guide.xml

udev-guide.xml

udev-guide.xml (text/plain), 17.07 KB, created by Davide Cendron (RETIRED) on 2006-12-12 12:21:07 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Davide Cendron (RETIRED)

Created: 2006-12-12 12:21:07 UTC

Size: 17.07 KB

patch

obsolete

><?xml version='1.0' encoding="UTF-8"?>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
>
>
>
><guide link="/doc/it/udev-guide.xml" lang="it">
><title>Guida a udev su Gentoo</title>
>
><author title="Autore">
> <mail link="swift@gentoo.org">Sven Vermeulen</mail>
></author>
><author title="Contributi">
> <mail link="greg_g@gentoo.org">Gregorio Guidi</mail>
></author>
><author title="Traduzione">
> <mail link="grandezot@cheapnet.it">Raffaele Camarda</mail>
></author>
><author title="Revisione">
> <mail link="posta@massimo.it">Massimo Canali</mail>
></author>
><author title="Revisione">
>	Davide Cendron
></author>
>
><abstract>
>Questo documento spiega cos'Ã¨ e come si puÃ² usare udev su Gentoo.
></abstract>
>
><license/>
>
><version>0.25</version>
><date>2006-11-26</date>
>
><chapter>
><title>Cos'Ã¨ udev?</title>
><section>
><title>La directory /dev</title>
><body>
>
>
>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 <path>/dev/hda1</path> 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 si da un'occhiata piÃ¹ approfondita in
><path>/dev</path> con un <c>ls -l</c>. Ma quello che noi tutti diamo per
>scontato Ã¨ che quando ci riferiamo al primo HD sul primo controler IDE stiamo
>parlarlando di <path>/dev/hda</path>.
>
>
>
>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:
>
>
><ul>
> <li>Gira in spazio utente</li>
> <li>Crea e rimuove dinamicamente i file di dispositivo</li>
> <li>Assegna i nomi alle periferiche</li>
> <li>Mette a disposizione un API utilizzabile nello spazio utente</li>
></ul>
>
>
>Per fornire queste caratteristiche, udev Ã¨ sviluppato in tre diversi progetti:
><e>namedev</e>, <e>libsysfs</e> e, ovviamente, <e>udev</e>.
>
>
></body>
></section>
><section>
><title>namedev</title>
><body>
>
>
>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:
>
>
><ul>
> <li>etichetta o numero seriale</li>
> <li>numero della periferica sul bus</li>
> <li>topologia del bus</li>
> <li>nome assegnato staticamente</li>
> <li>nome fornito dal kernel</li>
></ul>
>
>
>Il primo passaggio (<e>etichetta o numero seriale</e>) 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 (<e>numero della periferica sul bus</e>) 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 (<e>topologia del bus</e>), 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 (<e>nome
>assegnato staticamente</e>), 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
>(<e>nome fornito dal kernel</e>). Nella maggior parte dei casi questo Ã¨
>sufficiente visto che il nome corrisponde a quello assegnato.
>
>
></body>
></section>
><section>
><title>libsysfs</title>
><body>
>
>
>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.
>
>
></body>
></section>
><section>
><title>udev</title>
><body>
>
>
>Ogni volta che il kernel percepisce che sono stati collegati o rimossi dei
>dispositivi, lancia il programma <path>/sbin/hotplug</path>. Hotplug a sua
>volta lancia i programmi che sono stati linkati nella directory
><path>/etc/hotplug.d/default</path>, 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 <path>/dev</path>.
>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Usare udev su Gentoo</title>
><section>
><title>Requisiti</title>
><body>
>
>
>udev Ã¨ stato pensato per funzionare in combinazione con i kernel 2.6 (come per
>esempio <c>vanilla-sources</c> o <c>gentoo-sources</c> 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
><c>sys-apps/baselayout</c>.
>
>
><pre caption="Installare udev">
># emerge udev
></pre>
>
>
>udev installa come dipendenza anche il pacchetto <c>sys-apps/hotplug-base</c>.
>Non Ã© necessario installare <c>hotplug</c> a meno che non si voglia che i
>moduli del kernel vengano caricati quando si collega una periferica al sistema.
><c>hotplug</c> si occupa anche di attivare le interfacce di rete.
>
>
><pre caption="Installare gli script opzionali di hotplug">
># emerge hotplug
></pre>
>
>
>Se si vuole che vengano caricati i moduli per le periferiche che sono state
>collegate al sistema prima del boot Ã© necessario installare il pacchetto
><c>sys-apps/coldplug</c>.
>
>
><pre caption="Installare il pacchetto coldplug">
># emerge coldplug
></pre>
>
>
>
>Assicuratevi di aver aggiunto <c>coldplug</c> al runlevel utilizzato:
>
>
><pre caption="Aggiungere coldplug al runlevel boot">
># rc-update add coldplug boot
></pre>
>
><note>
>Se si sta utilizzando la versione 103 o successive di udev non Ã¨ piÃ¹ necessario
>installare <c>coldplug</c>, in quanto sarÃ  udev stesso a caricare i moduli. Se
>si sta aggiornando alla versione 103, bisogna rimuovere coldplug (<c>emerge -aC
>coldplug</c>) prima di aggiornare udev. Assicurarsi di rimuovere lo script di
>inizializzazione di coldplug da tutti i runlevel (<c>rc-update del
>coldplug</c>), ed in seguito rimuoverlo da <path>/etc/init.d</path>
></note>
>
>
>e ricordatevi di attivare le seguenti opzioni nel kernel:
>
>
><pre caption="Required kernel options">
>General setup ---&gt;
> [*] Support for hot-pluggable devices
>
>
>File systems ---&gt;
> Pseudo filesystems ---&gt;
> [*] /proc file system support
> [*] Virtual memory file system support (former shm fs)
></pre>
>
>
>Se si desidera si puo' mantenere attiva anche l'opzione <c>/dev file system
>support (OBSOLETE)</c>, ma bisogna assicurarsi che l'opzione "Automatically
>mount at boot" sia disattivata.
>
>
><pre caption="Disattivare l'opzione montare devfs al boot">
> File systems ---&gt;
> Pseudo Filesystems ---&gt;
> [*] /dev file system support (OBSOLETE)
> [ ] Automatically mount at boot
></pre>
>
>
>Se si utilizza <c>genkernel</c> bisogna lanciarlo con l'opzione <c>--udev</c>
>per attivare tutte le opzioni del kernel necessarie al funzionamento di udev.
>
>
></body>
></section>
>
><section>
><title>Configurazione</title>
><body>
>
>
>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 <path>/dev</path> in modo che non vi 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 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 <c>RC_DEVICE_TARBALL</c> in <path>/etc/conf.d/rc</path> e
>impostatela su <c>no</c>:
>
>
><pre caption="/etc/conf.d/rc">
>RC_DEVICE_TARBALL="no"
></pre>
>
>
>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
><c>gentoo=nodevfs</c>. Se invece si volesse riattivare il supporto a devfs
>disabilitando udev, si dovrÃ  passare al kernel il parametro
><c>gentoo=noudev</c>.
>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Problemi Noti</title>
><section>
><title>File di dispositivo mancanti all'avvio</title>
><body>
>
>
>Se non si riesce a avviare il sistema con successo perchÃ© si ottiene un errore
>che dice che il file <path>/dev/null</path> non Ã¨ stato trovato, o perchÃ© la
>console iniziale non esiste, il problema Ã¨ dovuto alla mancanza di alcuni file
>che devono essere presenti nel sistema <e>prima</e> che
><path>/dev</path> venga montato e udev inizi a gestirlo. Questo Ã¨ un errore
>piuttosto comune sui sistemi Gentoo installati usando supporti vecchi.
>
>
>
>Avendo installato <c>sys-apps/baselayout-1.8.12</c>, 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 dispositivo mancanti, come descritto in seguito.
>
>
>
>Per visualizzare i dispositivi che sono disponibili prima che il filesystem
><path>/dev</path> venga montato bisogna eseguire i seguenti comandi:
>
>
><pre caption="Elenco dei dispositivi disponibili all'avvio">
># mkdir test
># mount --bind / test
># cd test/dev
># ls
></pre>
>
>
>I dispositivi necessari per avviare correttamente il sistema sono
><path>/dev/null</path> e <path>/dev/console</path>. Se non vengono
>visualizzati durante il test precedente vanno creati manualmente. I comandi
>seguenti vanno eseguiti nella directory <path>test/dev/</path> creata
>precentemente:
>
>
><pre caption="Creare i file di dispositivo mancanti">
># mknod -m 660 console c 5 1
># mknod -m 660 null c 1 3
></pre>
>
>
>Quando si sono impartiti questi comandi Ã¨ necessario ricordarsi di smontare la
>directory <path>test/</path>:
>
>
><pre caption="Smontare la directory test/">
># cd ../../
># umount test
># rmdir test
></pre>
>
></body>
></section>
><section>
><title>udev e nvidia</title>
><body>
>
>
>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:
>
>
><ul>
> <li>
> il modulo <c>nvidia</c> sia elencato nel file
><path>/etc/modules.autoload.d/kernel-2.6</path>
> </li>
> <li>
> sia installata una versione di <c>nvidia-kernel</c> uguale o maggiore di
><c>media-video/nvidia-kernel-1.0.5336-r2</c>
> </li>
> <li>
> sia installata una versione di <c>sys-apps/baselayout</c> uguale o maggiore
>di <c>sys-apps/baselayout-1.8.12</c>
> </li>
></ul>
>
>
>Se <c>xorg-x11</c> si rifiuta di partire, puÃ² dipendere dalla mancanza del file
>device <path>/dev/nvidia</path>. Eventualmente eseguire
><path>/sbin/NVmakedevices.sh</path> per (ri)crearlo.
>
>
>
></body>
></section>
>
><section>
><title>I volumi LVM2 scompaiono</title>
><body>
>
>
>Usando <c>udev</c> e LVM2 insieme, Ã¨ possibile che che i volumi logici creati
>non appaiano nella directory <path>/dev</path>. In realta' questi device si
>chiamano <path>/dev/dm-#</path> dove # sta per un numero intero.
>
>
>
>Per correggere questo errore bisogna modificare il file
><path>/etc/udev/rules.d/50-udev.rules</path> decommentando la seguente linea:
>
>
><pre caption="Deconmmentare questa linea nel file /etc/udev/rules.d/50-udev.rules">
>KERNEL="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k",
>SYMLINK="%c"
></pre>
>
>
>Dopo, installate <c>sys-fs/multipath-tools</c> che contiene le applicazioni
><c>devmap_name</c>.
>
>
><pre caption="Installazione di multipath-tools">
><comment>(Al momento in cui scrivo multipath-tools e' disponibile solo in testing:)</comment>
># echo "=sys-fs/multipath-tools-0.4.2 ~x86" &gt;&gt; /etc/portage/package.keywords
># emerge multipath-tools
></pre>
>
></body>
></section>
>
><section>
><title>Assegnamento dei nomi differente tra DevFS e udev</title>
><body>
>
>
>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 <c>cciss</c>). Con udev, il dispositivo viene
>chiamato
><path>/dev/cciss/cXdYpZ</path> dove X, Y e Z sono numeri. Con devfs, il
>dispositivo
>si chiama <path>/dev/hostX/targetY/partZ</path> o Ã© un link simbolico a
><path>/dev/cciss/cXdY</path>.
>
>
>
>In questo caso Ã© necessario ricordarsi di modificare il file
><path>/etc/fstab</path> e i file di configurazione del bootloader.
>
>
>
>La stessa cosa succede con molti dei link simbolici che venivano creati in
><path>/dev</path>, come per esempio <path>/dev/mouse</path>, che ora
><c>udev</c> non crea piu'. Assicurarsi che nel proprio file di configurazione
>di X il percorso del dispositivo del mouse punti a un file esistente.
>
>
>
>Un'altro problema Ã¨ nella differenza di denominazione dei terminali tra devfs e
>udev. Mentre in devfs i terminali vengono chiamati <c>tty</c>, udev li chiama
><c>vc</c> e <c>tty</c>. CiÃ² puÃ² dare dei problemi nel caso siano state applicate
>delle restrizioni, attraverso l'uso di <path>/etc/securetty</path>, riguardo le
>login da utente root. Assicurarsi che entrambe le voci <c>tty1</c> e <c>vc/1</c>
>siano elencate nel file di configurazione <path>/etc/securetty</path>, per
>permettere a root di loggarsi tramite la console.
>
>
></body>
></section>
>
><section>
><title>Altri problemi</title>
><body>
>
>
>Se il file corrispondente a un dispositivo non viene creato quando si carica
>il modulo relativo tramite il file
><path>/etc/modules.autoload.d/kernel-2.6</path>, ma compare caricando
>manualmente il modulo tramite modprobe si provi a installare
><c>sys-apps/baselayout-1.8.12</c>, o piÃ¹ recente.
>
>
>
>Il supporto per i dispositivi framebuffer (<path>/dev/fb/*</path>) Ã¨ 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 <path>/dev/pts</path>.
>
>
><pre caption="Abilitare il filesystem /dev/pts">
>File systems ---&gt;
> Pseudo filesystems ---&gt;
> [*] /dev/pts file system for Unix98 PTYs
></pre>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Risorse &amp; Riconoscimenti</title>
><section>
><body>
>
>
>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.
>
>
>
><uri
>link="http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html">
>Decibel's
>UDEV Primer</uri> Ã¨ un documento molto approfondito riguardo all'uso di udev
>su Gentoo.
>
>
>
><uri link="http://www.reactivated.net/udevrules.php">Writing udev
>rules</uri>, scritto dallo sviluppatore di Gentoo Daniel Drake, Ã¨ un
>documento eccellente per imparare come personalizzare la proprio
>installazione di udev.
>
>
></body>
></section>
></chapter>
>
></guide>

Actions: View

Attachments on bug 157953: 103889 | 105550