Guía del Sistema de Archivos de Dispositivos
La implementación tradicional de Linux provee a los usuarios con un directorio abstracto, llamado /dev. Dentro de este se pueden encontrar los nodos de dispositivos, archivos especiales que representan los dispositivos dentro del sistema. Por ejemplo, /dev/hda representa el primer dispositivo IDE en el sistema. Al proveer archivos de dispositivos a los usuarios, estos pueden crear programas que interactúen con el hardware como si este fuese un archivo regular en vez de utilizar APIs especiales. Los archivos de dispositivos están divididos en dos grupos, los llamados dispositivos de caracteres y lo dispositivos de bloques.El primer grupo consiste en el hardware cuyos procesos de lectura/escritura no tienen buffer. El segundo grupo, naturalmente, consiste en el hardware cuyo proceso de lectura/escritura sí tiene buffer. Ambos tipos pueden ser leídos un carácter a la vez, o en bloques. Por lo que la nomenclatura puede sonar confusa y en realidad es incorrecta. Si le echas una mirada a algún archivo de dispositivo, es probable que encuentres algo parecido a esto:
En el ejemplo previo podemos ver que /dev/hda es un dispositivo de bloques. Sin embargo, más importante aún, tiene dos números especiales asignados a él: 3, 0. Este par es llamado el par mayor-menor. Es utilizado por el núcleo para convertir el archivo de dispositivo en un dispositivo real. El mayor corresponde a cierto dispositivo, el menor a un sub-dispositivo. ¿Parece confuso? No lo es. Dos ejemplos son /dev/hda4 y /dev/tty5. El primer archivo de dispositivo corresponde a la cuarta partición del primer dispositivo IDE. Su par mayor-menor es 3, 4. En otras palabras, el menor corresponde a la partición mientras que el mayor corresponde al dispositivo. El segundo ejemplo tiene 4, 5 como par mayor-menor. En este caso, el mayor corresponde al controlador del terminal, mientras que el menor corresponde al numero de terminal (en este caso, el quinto terminal). Si le das una mirada al directorio /dev, encontrarás que no solo todos tus dispositivos están listados, sino todos los dispositivos que te puedas imaginar. En otras palabras, tienes archivos de dispositivos por dispositivos que no tienes. Manejar tal grupo de dispositivos es pesado, por decir menos. Imagine tener que cambiar permisos a todos los archivos de dispositivos que tienen un dispositivo correspondiente en tu sistema, y dejar el resto intacto. Cuando añades un nuevo hardware a tu sistema, y este nuevo hardware no tiene un archivo de dispositivo previamente diseñado, tienes que crear uno. Los usuarios avanzados saben como hacer esto utilizado ./MAKEDEV dentro del árbol del /dev, pero ¿Sabes inmediatamente qué dispositivo crear? Cuando tienes programas interactuando con el hardware utilizando archivos de dispositivos, no puedes tener la partición raíz montada como solo lectura, dado que no puedes tener el directorio /dev en otra partición, ya que mount necesita de /dev para montar las particiones. Como puedes imaginar, los hackers del núcleo han encontrado varias soluciones para los problemas previamente mencionados. Sin embargo, muchos de ellos sufren de otras carencias como se describe en http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#faq-why . Nosotros no vamos a hablar acerca de estas soluciones, sino que nos concentraremos en una implementación que llegó a las fuentes oficiales del núcleo: devfs. ¿devfs como un ganador completo? devfs ataca todos los problemas listados. Solo provee al usuario con dispositivos existentes, añade nuevos nodos cuando un dispositivo es encontrado, y hace posible montar el sistema de archivos raíz como solo lectura. También soluciona otros problemas que no hemos discutido previamente porque no son de mucho interés a los usuarios... Por ejemplo, con devfs, no tienes que preocuparte por los pares mayores/menores. Aunque siguen siendo soportados (por compatibilidad con el antiguo sistema), ya no es necesario. Esto hace posible a Linux soportar incluso más dispositivos, dado que ya no hay límites (los números siempre tienen límites :). Pero devfs también tiene sus propios problemas; para los usuarios finales estos no son realmente visibles, pero para los mantenedores del núcleo los problemas son lo suficientemente grandes como para marcar a devfs como obsoleto en favor de udev, que Gentoo soporta y se usa por defecto en la mayoría de las arquitecturas desde el lanzamiento de la versión 2005.0 con núcleos 2.6. Para más información sobre por qué devfs ha sido marcado como obsoleto, por favor lea udev PUF (en Inglés) y udev versus devfs. 2. Navegando a través del árbol de dispositivos Una de las primeras cosas que debes haber notado, es que devfs utiliza directorios para agrupar los dispositivos. Esto mejora la comprensibilidad, ya que todos los dispositivos relacionados están dentro de un mismo directorio. Por ejemplo, todos los dispositivos IDE o relacionados, se encuentran dentro del directorio /dev/ide/, y todos los SCSI o relacionados están dentro de /dev/scsi/. Los discos SCSI e IDE son vistos de la misma manera, lo que significa que ambos tienen la misma estructura de subdirectorios. Los discos IDE y SCSI son controlados por un adaptador (incorporado o en una tarjeta separada), llamado anfitrión. Cada adaptador puede tener varios canales. El canal es llamado bus. En cada canal, puedes tener varios IDs. Un ID identifica un disco. Este Id es llamado el objetivo. Algunos dispositivos SCSI pueden tener varios luns (abreviatura en inglés de Números de Unidad Lógica), un ejemplo son los dispositivos que manejan múltiples medios al mismo tiempo (Controladores de cinta de alto desempeño). Mayormente solo tendrás un único lun, lun0/. Así, de tener el previo /dev/hda4, ahora tenemos /dev/ide/host0/bus0/target0/lun0/part4. Esto es mucho más simple ... no, tranquilo ... de verdad es más fácil ... naa, ¡no importa! :)
Para darte una idea de los directorios, esta es una lista de los directorios que yo tengo en mi laptop:
Compatibilidad con anteriores utilizando devfsd Usar este nuevo esquema suena divertido, pero varias herramientas y programas hacen uso del antiguo esquema. Para asegurarse de que no se rompa el sistema, se creó devfsd. Este demonio crea enlaces simbólicos con los nombres antiguos, apuntando hacia los nuevos archivos de dispositivos.
Con devfsd, también puedes configurar los permisos, crear nuevos archivos de dispositivos, definir acciones, etc. Todo esto está descrito en el siguiente capítulo. 3. Administrando el árbol de dispositivos Cuando modificas el archivo /etc/devfsd.conf, y quieres que los cambios sean aplicados a tu sistema, no necesitas reiniciar todo el sistema. Dependiendo de lo que quieras hacer, puedes utilizar cualquiera de las dos siguientes señales: SIGHUP hará que devfsd relea el archivo de configuración, recargue los objetos compartidos y genere los eventos REGISTER para cada nodo hoja del árbol de dispositivos. SIGUSR1 hará lo mismo, pero no generará los eventos REGISTER. Para enviar una señal, simplemente utiliza kill o killall:
Removiendo los enlaces simbólicos de compatibilidad
Si quieres remover los enlaces de compatibilidad que rellenan /dev de tu sistema Gentoo (Gentoo lo activa por defecto), edita /etc/devfsd.conf y remueve las siguientes dos lineas:
Necesitas reiniciar tu sistema para que los cambios se ejecuten. Removiendo la funcionalidad de auto cargado Cuando tu cargas un módulo, devfs automáticamente creará los archivos de dispositivos. Si no quieres que esto ocurra, remueve la siguiente linea del archivo /etc/devfsd.conf:
4. Puntos relacionados con los permisos Asignar/cambiar los permisos con devfsd
Si quieres configurar los permisos utilizando /etc/devfsd.conf, entonces utiliza la sintaxis del siguiente ejemplo:
El segundo campo es el grupo de dispositivos, empezando desde /dev. Es una expresión regular, lo que quiere decir que puede seleccionar varios archivos de dispositivos en una sola regla. El cuarto campo es el dueño del archivo de dispositivo y el quinto campo contiene los permisos del archivo de dispositivos. Configurar manualmente los permisos y hacer que devfsd los guarde Este es el comportamiento normal de Gentoo: si ejecutas chown y chmod sobre algún archivo de dispositivo, devfsd salvará la información incluso cuando se reinicie el sistema. Esto es porque el archivo /etc/devfsd.conf contiene las siguientes lineas:
En otras palabras, los cambios sobre los archivos de dispositivos son copiados a /lib/dev-state en el instante que suceden, y son copiados de regreso a /dev al iniciar el sistema. Otra posibilidad es montar /lib/dev-state en /dev en tiempo de arranque. Para hacer esto necesitas asegurarte que devfs no es montado automáticamente (para lo cual deberás recompilar tu núcleo) y que /dev/console existe. Luego, en algún momento en el inicio de los guiones de inicio de tu sistema coloca:
Para mayor información acerca de devfs, revisa los siguientes recursos. La página del manual devfsd.conf explica la sintaxis del archivo /etc/devfsd.conf. Para verla, escribe man devfsd.conf. El devfs PUF (en inglés) explica todo acerca de devfs. También contiene información acerca de la estructura interna de devfs y como los controladores pueden soportar devfs. En LinuxJournal hay un interesante artículo sobre devfs for Management and Administration. Daniel Robbins ha escrito un par de artículos para IBM's DeveloperWorks acerca de sistemas de archivos avanzados. Tres de ellos tratan sobre (todos en inglés): El contenido de este documento, a no ser que se especifique expresamente, está registrado bajo los términos de la licencia CC-BY-SA-2.5. Se aplican las Pautas de Utilización del logotipo y nombre de Gentoo. |
|