Udev: Userspace devfs
Si sois un poco curiosos seguro que alguna vez habéis echado un ojo
a /dev y os habrá llamado la atención la cantidad ingente de dispositivos
que pueblan este directorio; seguro que alguno se ha preguntado para
que valen...pues, sobre un 80%, para nada. Están ahí puestos por
si acaso algún día apareciese ese dispositivo... Es decir, es una
base de datos de POSIBLES dispositivos, pero que no reflejan
para nada lo que hay conectado en nuestro sistema.
Esto viene de muy atrás y arranca en cómo el kernel contempla los
dispositivos. Pero esto va a cambiar, y se pretende que la identificación
de dispositivos sea mucho más flexible en el futuro (eliminar la dependecia
de 'block number' y etc. en un futuro)
A raíz de esto nació devfs; se trata de un pseudo sistema de ficheros
que se encarga de mantener una lista de dispositivos conectados al
sistema y crear las entradas en /dev oportunas. Si bien esta característica
hizo su entrada en la serie 2.5 y fue llevado a los 2.4, en el nuevo
2.6 se ha dado la característica por 'deprecated' (descontinuada)
porque ha surgido udev y porque el manetenedor de devfs ha desaparecido.
udev es un asalto al mismo problema desde otra perspectiva; funciona
por completo en espacio de usuario (en oposición a devfs que funcionaba
en espacio de kernel) y su principal punto fuerte (mi preferido) es
que permite personalizar el nombre de dispositivo.
Cualquiera que tenga hardware usb se habrá dado cuenta de que el dispositivo
asignado a un dispositivo depende de lo que ya esté conectado al sistema
o el orden en que se haya hecho. Esto es tremendamente incómodo de
cara a automatizar los montados y desmontados de, por poner un ejemplo,
un disco usb, o una cámara digital. Ya que, si por ejemplo, un día
enchufamos primero el disco usb y después la cámara, recibirán /dev/sda
y /dev/sdb; pero si otro día lo hacemos al revés, ¡los dispositivos
se invierten!
Todo un lío de cara a crear scripts o, mismamente, crear accesos directos
a nuestros dispositivos en el escritorio. Por suerte, tiene solución
:-)
Bueno, el funcionamiento es más o menos simple:
- Enchufamos nuestro dispositivo
- El kernel se da cuenta de que algo está en marcha, detecta nuestro
dispositivo y le pasa el control a hotplug1
- Hotplug examina el tipo de dispositivo y carga módulos si son necesarios
para dejar el dispositivo listo para usar
- Hotplug notifica a udev que tiene un nuevo dispositivo conectado
- udev se da por enterado, y se va a la partición sysfs a buscar la
identificación del dispositvo; estos datos son contrastados con una
serie de reglas de nomenclatura (más sobre esto más tarde) y le asigna
una entrada de dispositivo.
Bien, antes de seguir, debo advertir que udev sólo está disponible
para la serie 2.6 del kernel. Es decir, todo lo que se explica aquí
es de aplicación exclusiva a esta serie.
- Un kernel 2.6 http://www.kernel.org
- Haber configurado CONFIG_HOTPLUG a 'yes' cuando lo compilamos (o
lo compilaron)
- Tener montado la partición sysfs2
- Tener instalados los scripts de hotplug linux-hotplug.sf.net
- udev, el programa de espacio de usuario, se puede encontrar en http://www.kernel.org/pub/linux/utils/kernel/hotplug/
Es tan simple como descomprimir el archivo que nos habremos bajado
(en el momento de escribir esto, la versión más moderna de la que
tengo noticia es la 015) entrar al directorio, hacer 'make' y después,
como root 'make install'
Esto ya no es tan simple y aquí debemos trabajar un poquito más.
La configuración general del sistema se hace a través de /etc/udev/udev.conf
(esto podría cambiar en el futuro o haber sido personalizado). En
este fichero será de nuestro interés principalmente
- udev_root
- Aquí se especifica en dónde debe crear los nodos udev.
Es buena idea, de momento, conservar nuestro /dev y usar udev en otro
directorio, como, por ejemplo, el /udev que viene por defecto.
- default_mode
- Aquí definimos los permisos por defecto para aquellos
nodos que no tengan una regla fijada en udev.permissions
- default_owner
- A nombre de quién se crean los nodos
- default_group
- Bajo que grupo se crean los nodos.
Aquí llega uno de los problemas de los que adolece udev ahora mismo;
no recuerda los permisos que pusimos a un nodo con lo que (de momento,
está en la lista de 'TODO') tenemos que crear un archivo contándole
a udev con qué permisos queremos que cree cada nodo, el fichero tiene
una sintaxis bastante facilona:
Se crea una nueva línea para dispositivo(s) con la forma: NOMBRE:USUARIO:GRUPO:PERMISOS
por ejemplo, si queremos que la tarjeta de sonido (con un nombre genérico
como dsp1) sea creado bajo la propiedad del usuario 'sonido', en el
grupo 'multimedia' con permisos de lectura y escritura para el usuario,
escritura al grupo, y lectura al resto, sería:
dsp1:sonido:multimedia:0642
Se permiten los comodines y se aplican principalmente a los números
de dispositivo (por ejemplo, para fijar permisos a todas las tarjetas
de sonido, usaríamos dsp*)
Cabe mencionar que el programa trae archivos de configuración ya preparados
en lo que a permisos se refiere tanto para debian como para gentoo
que se pueden encontrar en ./udev/etc/udev
udev, como ya he mencionado permite personalizar el nombre que se
asigna a los dispositivos, pero para ello, debemos definir una serie
de reglas que identifiquen al dispositivo de forma inconfundible,
para esto se define el archivo /etc/udev/udev.rules Hay que decir
que tenemos unas posibilidades enormes, y que esto hace que la lista
de opciones sea también enorme, podemos definir reglas en función
de a qué bus se conecta un dispositivo, a qué puerto pci o usb, que
lo llame en función de un programa que llamemos nosotros al conectar
el disposito, que coincida con un determinado valor en las propiedades
de sysfs, y etc.
Udev examinará la regla (cada línea es una regla) y si todas las condicions
que hemos definido son ciertas, el dispositivo será llamado como se
escifica con ``NAME'', si no, se asume la nomenclatura estándard
del kernel. Un ejemplo de regla para udev.rules:
-
- BUS="scsi", SYSFS{vendor}="TEAC ", NAME="disquetera%n"
Se puede ver como se define que es un dispositivo conectado al bus
scsi (¡¡¡OJO!!! aquellos dispositivos que hacen uso de la emulación
scsi; por ejemplo, usb-storage; se consideran conectados al bus SCSI),
se define también que el fabricante es TEAC pero, por favor,
fijaos
en los espacios, ¡la cadena debe coincidir literalmente!, y vemos
como a este dispositivo se le llama ``disquetera%n''. El %n
se refiere al número de dispositivo que da el kernel, por ejemplo,
si conectamos la disquetera con un disquete con tres particiones,
se creará disquetera, disquetra1, disquetera2 y disquetera3 (en donde
el %n es sustituído por el número apropiado)
Mención especial requiere la opción de SYSFS{vendor}: En el árbol
de sysfs se mantiene información sobre los dispositivos conectados,
creando archivos que definen propiedades en su carpeta, es devir,
lo que decimos con SYSFS{vendor}= ``TEAC `` es que 'el archivo
``vendor'' bajo sysfs que corresponde a este dispositivo debe
conetener la cadena TEAC', así, es posible usar cualquiera de los
archivos para identificar al dispositivo. Una pequeña lista de posibles
opciones para la identificación:
- BUS el tipo de bus al que se conecta
- KERNEL nombre del kernel
- SYSFS_fichero Coincidir el contenido del fichero de sysfs que definimos
(sólo se pueden comprobar 5 archivos por norma) Atencion:en la release 018 se ha cambiado por SYSFS{fichero}
- PROGRAM Llama a un programa externo y considera que la condición
se cumple si el programa devuelve 'éxito'
- RESULT se usa para afinar más con los programas externos, pidiendo
esta regla que la salida del programa anterior coincida con lo que
hemos definido
- NAME El nombre que le vamos a dar al dispositivo
- SYMLINK En caso de que queramos crear un enlace simbólico al dispositivo;
se pueden crear más de uno
Tanto NAME, como SYMLINK aceptan ``comodines'' de la que se enuncia
ahora los dos principales ( la lista completa con 'man udev'):
- %n El número que el kernel asigna (por ejemplo, hda3 tendría un
%n de 3)
- %k El nombre del kernel
Eliminad lo
Aunque udev promete mucho a los que usamos gran cantidad de dispositivos
extraíbles es todavía un tanto experimental y sujeto a cambios, así
que tal vez sea, durante un tiempo, buena idea mantener nuestro /dev
de la distribución y mantener en paralelo un /udev para comprobar
que tal funciona. Por no mencionar que si nos cargamos el /dev convencional
y no lo reemplazamos por un dinámico bien configurado es muy posible
que nos carguemos el sistema
No dudemos tampoco en probarlo por el hecho de que sea experimental,
ya que el ``feedback'' que podemos aportar ayudará al desarrollo
de estas características.
Y finalmente unas palabras de ánimo hacia aquellos usuarios de escritorio
que todavía usan los 2.4, os estáis perdiendo la gozada del 2.6; avisados
estáis.
|
