Tema 10. Periféricos

Tema 10.
Periféricos
Administración de Sistemas Operativos y Periféricos
Ma Pilar González Férez
Tema 10. Periféricos – p. 1/34
Índice
1. Ficheros
2. Módulos del núcleo
3. Conectando un dispositivo
4. Udev
5. Otras herramientas
6. HAL
7. The magic SysRq key
Tema 10. Periféricos – p. 2/34
Ficheros
Ficheros especiales de dispositivo
Todos los dispositivos tienen un fichero en /dev que lo
representa (/dev/sda1, /dev/lp0, /dev/sdb, /dev/audio, . . . )
Son ficheros especiales de bloque o de carácter (dependiendo del
tipo de dispositivo)
Cada uno de estos ficheros tiene asociados 2 números que el
núcleo utiliza para mapear las referencias a los mismos:
Número mayor (major number) ⇒ Identifica con qué driver está
asociado ese fichero, e.d., el tipo de dispositivo
Número menor (minor number) ⇒ Identifica la instancia
concreta del dispositivo asociado a ese fichero. También se le
conoce como unit number
brw-rw----
1 root disk 8, 0 abr 11 12:29 sda
Algunos de estos ficheros son creados por defecto, otros se
crearán al conectar el dispositivo mediante la herramienta udev
Tema 10. Periféricos – p. 3/34
Ficheros (ii)
/sysfs ⇒ Monta el sistema de ficheros basado en memoria Sysfs
Exporta al espacio de usuarios ciertos atributos e información
(estructuras de datos internas del núcleo) sobre los dispositivos
conectados en el sistema
La información es almacenada en ficheros que normalmente
contienen un único atributo
Estos ficheros se organizan en una jerarquía de directorios
Sysfs es manejado por el núcleo (aparece en el 2.6 y superiores)
Muestra los dispositivos hardware disponibles, sus atributos y
módulos o drivers
Determinadas herramientas, como udev, lo utilizan para obtener
información de los dispositivos, en concreto de sus directorios
block y class
Tema 10. Periféricos – p. 4/34
Ficheros (iii)
/proc ⇒ Monta el sistema de ficheros virtual basado en memoria
Proc
Contiene información sobre el hardware del sistema, cualquier
proceso que se esté ejecutando, la configuración del núcleo, etc.
Algunos ficheros en /proc:
cpuinfo ⇒ Información del procesador del sistema
devices ⇒ Los dispositivos de caracteres y de bloques actualmente
configurados (sólo incluye los dispositivos cuyos módulos están cargados)
interrupts ⇒ Interrupciones por IRQ
iomem ⇒ Mapa actual de la memoria del sistema para diversos dispositivos
ioports ⇒ Listado de puertos registrados para la comunicación de
entrada/salida con un dispositivo
modules ⇒ Listado de todos los módulos cargados por el sistema
partitions ⇒ Listado de las particiones de cada disco, junto con su tamaño
y los números “mayor” y “menor”
mounts ⇒ Listado de los sistemas de ficheros montados
Tema 10. Periféricos – p. 5/34
Ficheros (iv)
/proc (continúa. . . )
Algunos directorios en /proc:
bus/ ⇒ Información específica sobre los diversos buses disponibles en el
sistema y los dispositivos conectados
driver/ ⇒ Información para drivers (módulos) específicos que el núcleo
está usando
net/ ⇒ Proporciona una visión exhaustiva de diversos parámetros y
estadísticas de red
scsi/ ⇒ Información sobre dispositivos SCSI conectados (o simulados como
SCSI)
sys/ ⇒ Proporciona información sobre el sistema y permite al administrador
activar y desactivar características del núcleo:
· sys/dev/ ⇒ Parámetros para dispositivos particulares en el sistema
· sys/fs/ ⇒ Información referente a varios aspectos del sistema de
ficheros
· sys/kernel/ ⇒ Archivos de configuración que afectan directamente al
funcionamiento del núcleo
· sys/net/ ⇒ Información sobre la configuración de red en funcionamiento
· sys/vm/ ⇒ La configuración del subsistema de memoria virtual del núcleo
Tema 10. Periféricos – p. 6/34
Módulos del núcleo
El núcleo de Linux:
Está organizado siguiendo una arquitectura monolítica y un
diseño modular
Por defecto incluye un soporte mínimo
El resto de características (soporte para distintos SF,
dispositivos, . . . ) se cargan, de forma dinámica, mediante los
módulos del núcleo, según se van necesitando
Esta carga dinámica de módulos permite la incorporación en
“caliente” de nuevo código al núcleo, sin necesidad de reiniciar el
sistema
Los módulos son "trozos de sistema operativo", en forma de ficheros
objeto (.ko), que se pueden insertar y extraer en tiempo de
ejecución, añadiendo o eliminando la funcionalidad que incorporan
Tema 10. Periféricos – p. 7/34
Módulos del núcleo (ii)
El código de los módulos cargados pasa a ser parte del propio
núcleo y, por lo tanto, se ejecuta en el modo núcleo (o supervisor) del
procesador, con acceso a todas las funciones del núcleo, a las
funciones exportadas por módulos previamente insertados y a todo
el hardware de la máquina sin restricciones
La única diferencia con código enlazado en el núcleo es la
posibilidad de extraer el módulo una vez que ha realizado su labor o
ha dejado de ser útil, liberando así todos los recursos usados
Los módulos permiten incluir funcionalidad al núcleo de forma que se
soporten, por ejemplo:
Distintos sistemas de ficheros (ext3, ext4, jfs, vfat, . . . )
Los distintos dispositivos hardware instalados (tarjeta de red,
sonido, gráfica, . . . ). (Normalmente se conocen como drivers)
Distintos protocolos de red
Tema 10. Periféricos – p. 8/34
Módulos del núcleo (iii)
Algunos módulos tienen dependencias ⇒ necesitan que otros
módulos sean cargados previamente para poder cargarse (y por tanto
funcionar correctamente)
Cada núcleo instalado tiene sus propios módulos
/lib/modules/numero_version_kernel/kernel/ ⇒ directorio
en el que están los módulos
/lib/modules/numero_version_kernel/kernel/drivers ⇒ Los
módulos para la gestión de los dispositivos
/lib/modules/numero_version_kernel/kernel/fs ⇒ Los módulos para
la gestión de los sistemas de ficheros
/lib/modules/numero_version_kernel/kernel/net ⇒ Los módulos para
la gestión de los distintos protocolos de red
Si se compila el núcleo, se puede seleccionar que determinadas
funcionalidades que se cargan como módulos, se incluyan por
defecto en el núcleo. Así, el núcleo incluirá esa funcionalidad y no
habrá que cargarla como módulo a posteriori cuando se necesite
Tema 10. Periféricos – p. 9/34
Módulos del núcleo (iv)
¿Cuándo se cargan los módulos?
initrd.img ⇒ Le proporciona al núcleo, en el momento del
inicio del sistema, determinados módulos que necesita para
acceder al sistema por primera vez (por ejemplo a un SF, a un sistema
RAID, al disco duro o a otros dispositivos hardware)
/etc/rc.d/rc.sysinit ⇒ En el proceso de arranque se
cargan los módulos de todos los dispositivos presentes
Directamente con la orden modprobe algunos módulos que necesita
Con start_udev se cargan los módulos de todos los dispositivos que hay
conectados al arrancar (y aún no se ha cargado su módulo)
Determinados scripts de inicio de demonios (/etc/init.d/)
cargan los módulos que precisan con modprobe
En “caliente”, al conectar un nuevo dispositivo Udev lo detectará
y cargará el módulo correspondiente
El administrador, a “mano”, si lo necesita
Tema 10. Periféricos – p. 10/34
Módulos del núcleo (v)
lsmod ⇒ Muestra un listado de los módulos cargados, informando
sobre el nombre, su tamaño, el recuento de usos y sus
dependencias. Obtiene los datos de /proc/modules
Module
nfsd
lockd
nfs_acl
Size
275600
71300
3120
Used by
9
1 nfsd
1 nfsd
modinfo ⇒ Muestra información sobre un módulo del núcleo
(fichero, autor, descripción, licencia, dependencias, parámetros, etc.)
[root@xxxx ˜]# /sbin/modinfo vfat
filename: /lib/modules/2.6.30.10-105.2.23.fc11.x86_64/kernel/fs/fat/vfat.ko
author:
Gordon Chaffee
description: VFAT filesystem support
license:
GPL
srcversion:
EFC768E1C562451391FF83A
depends:
fat
vermagic:
2.6.30.10-105.2.23.fc11.x86_64 SMP mod_unload
Tema 10. Periféricos – p. 11/34
Módulos del núcleo (vi)
insmod ⇒ Carga módulos, pero no resuelve dependencias
rmmod ⇒ Descarga módulos cargados, pero no tiene en cuenta
dependencias
modprobe
Carga módulos, verificando sus dependencias y cargando previamente los
módulos necesarios (se recomienda usar en vez de insmod)
-r ⇒ Descarga un módulo y los módulos de los que dependía
-l ⇒ Muestra un listado de todos los módulos disponibles
−−show-depends ⇒ Muestra las dependencias de un módulo
depmod ⇒ Genera el fichero modules.dep y los ficheros de mapas
(modules.usbmap, modules.pcimap, . . . )
modules.dep ⇒ Contiene un listado con las dependencias entre módulos. Está
en el directorio /lib/modules/numero_version_kernel/
Los ficheros de mapas son como bases de datos de módulos para un tipo de
dispositivo concreto, que indican qué dispositivos soportan cada uno de los
módulos disponibles. Sirven para seleccionar el módulo a usar para un
dispositivo conectado. Están en /lib/modules/numero_version_kernel/
Tema 10. Periféricos – p. 12/34
Módulos del núcleo (vii)
Con los ficheros del directorio /etc/modprobe.d/ se puede
cambiar el comportamiento de modprobe:
Especificar opciones o parámetros para un módulo
Asignar “alias” (o nombres alternativos) a un módulo
Corregir el comportamiento normal de modprobe, como por
ejemplo insertando más de un módulo o ejecutando un fichero
Entre las posibles opciones están:
alias nombre_alias nombre_modulo ⇒ Asignar un alias a un módulo
options nombre_modulo opciones ... ⇒ Especificar opciones
install nombre_modulo orden_a_ejecutar ⇒ Ejecutar la orden
indicada en vez de insertar el módulo, como se haría normalmente
remove nombre_modulo orden_a_ejecutar ⇒ Similar a la opción
“install”, pero al eliminar un módulo
include nombre_fichero ⇒ Incluir otros ficheros de configuración, si se
indica un directorio se incluyen todos los ficheros que haya en él
Tema 10. Periféricos – p. 13/34
Módulos del núcleo (viii)
Posibles ejemplos
alias scsi_hostadapter libata
alias scsi_hostadapter1 pata_via
options snd-via82xx index=0
alias snd-card-1 snd-mpu401
options snd-card-1 index=1
options snd-mpu401 index=1
alias eth2 r8169
alias eth3 via-rhine
alias snd-card-0 snd-via82xx
options snd-card-0 index=0
Tema 10. Periféricos – p. 14/34
Conectando un dispositivo
Cuando el núcleo detecta que ha ocurrido un evento, normalmente
hardware, lo notifica al software que se ejecuta en modo usuario:
El evento será: “se ha conectado un nuevo dispositivo” o “se ha
desconectado un dispositivo”
El software en modo usuario realizará las tareas necesarias,
según el evento, para poder usar el dispositivo (o dejar de usarlo)
Es muy útil para crear el fichero especial del dispositivo conectado, cargar los
módulos para poder manejar el dispositivo, ejecutar programas de
inicialización, montar el dispositivo, . . .
El objetivo es que al conectar un dispositivo se pueda usar
directamente (sin intervención del usuario en el proceso de preparación)
Inicialmente, incluye soporte para dispositivos USB y PCI (Cardbus),
y puede automáticamente configurar algunos interfaces de red
Tema 10. Periféricos – p. 15/34
Udev
Udev ⇒ Manejador de dispositivos dinámicos (Userspace device
manager )
Recibe las notificaciones del núcleo sobre los eventos de cambios en
el hardware y realiza las tareas oportunas:
Proporciona un directorio de dispositivos, /dev/, dinámico, que
contiene sólo los ficheros de los dispositivos conectados en un
momento dado ⇒ Crea o elimina los ficheros especiales de
dispositivo o renombra las interfaces de red, según se conectan
o desconectan dispositivos
Carga los módulos necesarios para manejar ese dispositivo
Ejecuta programas de inicialización, si es necesario
Mantiene una base de datos sobre los dispositivos presentes en
el sistema
El demonio udevd es el proceso encargado de hacer estas tareas
cuando el núcleo le informa del evento producido
Tema 10. Periféricos – p. 16/34
Udev (ii)
El núcleo informa a udevd pasándole:
Como parámetro el nombre del subsistema del núcleo específico
cuyo evento es procesado (“usb”, “scsi_device”, “pci”, . . . )
En variables de entorno, información sobre la acción que se ha
producido (“ACTION”, “DEVPATH”, . . . )
Al conectar un dispositivo ⇒ udevd lee de SYSFS información sobre
el dispositivo y obtiene sus atributos (como la etiqueta, el no de serie o el no
del bus del dispositivo). Estos atributos determinan un nombre único a
asignarle al fichero especial de dispositivo a crear
Al desconectar un dispositivo ⇒ udevd obtiene de la base de datos
el nombre del fichero de dispositivo a eliminar
udevd usa una serie de ejecutables que hay en /lib/udev/ para
realizar algunas de las tareas
Tema 10. Periféricos – p. 17/34
Udev (iii)
Funcionamiento de udevd
1. El núcleo le informa si un dispositivo es conectado/desconectado
2. Mira en /sys/ si el driver proporciona un fichero dev que
contiene el número mayor y menor para el fichero del dispositivo
3. Usa las reglas que están /etc/udev/rules.d/ para saber qué
tiene que hacer. En concreto:
Crear el fichero especial de dispositivo y los enlaces
simbólicos al mismo con los nombres alternativos propuestos
Establecer los permisos y los propietarios del fichero especial
de dispositivo creado
Si es necesario, cargar los módulos para poder trabajar con el
dispositivo
Si se le indica, ejecutar los programas especificados, por
ejemplo, para la inicialización
Tema 10. Periféricos – p. 18/34
Udev (iv)
Los ficheros de reglas de Udev
Las reglas le indican a udevd el nombre a asignar al fichero
especial de dispositivo, los permisos y propietarios, si es
necesario ejecutar un programa, y que cargue el módulo
Los ficheros de reglas están en el directorio
/etc/udev/rules.d/
udevd procesa todos los ficheros de reglas en orden alfabético
El nombre de los ficheros suele ser
“número_dos_dígitos-nombre_descriptivo.rules”:
50-udev-default.rules o 60-cdrom_id.rules
Las reglas locales se podrían guardar en un fichero llamado
/etc/udev/rules.d/99-local.rules
Se recomienda mantener el nombre por defecto para el
dispositivo e incluir otros nombres alternativos como “enlaces
simbólicos”
Tema 10. Periféricos – p. 19/34
Udev (v)
Formato de las reglas de Udev
Una regla está formada por una lista de una o más claves
separadas por comas: key [, key]
Hay dos tipos de claves: de comprobación y de asignación
Si todas las claves de comprobación de una regla se cumplen, se
“ejecuta” la clave de asignación, que permitirá:
Asignar un nombre al fichero especial de dispositivo, permisos o propietario
Establecer un “enlace simbólico” a ese fichero de dispositivo
Ejecutar un programa como parte del manejo del evento: cargar un módulo
Si no se cumple ninguna regla, no se ejecuta nada y asigna el
nombre por defecto para el fichero especial de dispositivo
Cada clave tiene un comportamiento distinto que depende del
operador usado. Los posibles operadores son:
==
Comparación igualdad
!=
=
Asignar un valor
+=
Comparación de desigualdad
Añadir un valor a los ya asignados
Tema 10. Periféricos – p. 20/34
Udev (vi)
Formato de las reglas de Udev
Claves de comprobación:
ACTION ⇒ coincide con la acción indicada por el kernel
BUS ⇒ coincide el tipo de bus del dispositivo
ATTR{fichero_sys} ⇒ coincide con el valor de un atributo sysfs del
“dispositivo” del evento
ATTRS{fichero_sys} ⇒ busca en el directorio del dispositivo (devpath) y
en sus directorios “padre” un dispositivo con un atributo sysfs que coincida
con el indicado
KERNEL ⇒ concuerda el nombre que el núcleo asigna al dispositivo
PROGRAM ⇒ ejecutar el programa externo, la clave es “verdad” si el programa
termina correctamente (valor de salida 0)
ENV{var} ⇒ comprueba una variable de entorno
Tema 10. Periféricos – p. 21/34
Udev (vii)
Formato de las reglas de Udev
Claves de asignación:
NAME ⇒ indica el nombre del fichero de dispositivo en el directorio /dev/
SYMLINK ⇒ permite especificar nombres adicionales
OWNER, GROUP, MODE ⇒ propietario, grupo propi. y permisos del fichero
RUN ⇒ ejecutar un programa
IMPORT{tipo} ⇒ importa el resultado o el contenido del fichero en variables
de entorno. Donde “tipo” puede ser un programa a ejecutar o un fichero a leer
ENV{var} ⇒ exporta una variable de entorno
En las claves de comprobación se pueden usar “comodines”
En “NAME” y “SYMLINK” se pueden usar operadores especiales:
%n ⇒ será sustituido por el número asignado por el núcleo. Por ejemplo,
’sda3’ tiene el número ’3’
%k ⇒ representa el nombre que el núcleo le da al dispositivo
Tema 10. Periféricos – p. 22/34
Udev (viii)
Ejemplos de reglas de Udev
# Valores por defecto para propietario, grupo propietario y permisos
KERNEL=="*", OWNER="root", GROUP="root", MODE="0600"
# Asignando el grupo propietario y los permisos
SUBSYSTEM=="block", GROUP="disk", MODE="0640"
#Averiguando el valor de la variable ID_SERIAL, si está vacı́a
KERNEL=="sd*[!0-9]", ENV{ID_SERIAL}=="", IMPORT{program}="/sbin/usb_id -x"
KERNEL=="fd[0-9]*", NAME="%k", SYMLINK="floppy/%n" #Asignando un nombre
BUS=="usb", ATTRS{serial}=="L04", NAME="%k", SYMLINK="hp1300"
BUS=="usb", ATTRS{vendor}=="FUJIFILM", ATTRS{model}=="M100", NAME="%k", \
SYMLINK+="camera%n", SYMLINK+="fuji%n"
#/dev/sda, /dev/sda1,..., y /dev/uhd, /dev/uhd1,... (tantos como particiones)
BUS=="usb", KERNEL=="sd*", ATTRS{product}=="USB 2.0 Storage Device", \
NAME="%k", SYMLINK="uhd%n"
KERNEL=="sd[a-z]", BUS=="scsi", ATTRS{removable}=="1", \
PROGRAM="/etc/udev/scripts/check-cdrom.sh %k DVD-R", \
SYMLINK+="dvdwriter%e"
ACTION=="add", SUBSYSTEM=="?*", ENV{MODALIAS}=="?*", \
RUN+="/sbin/modprobe $env{MODALIAS}"
Tema 10. Periféricos – p. 23/34
Udev (ix)
Identificando dispositivos a través de los ficheros del SYSFS:
El sistema de ficheros SYSFS (/sys/) guarda pequeños
ficheros (normalmente tienen un atributo por fichero) debajo de un árbol
de directorios que proporcionan información sobre el hardware
Las claves “ATTR” y “ATTRS” en las reglas de Udev permiten
buscar y usar información en estos ficheros
Por ejemplo, para una cámara conectada hay un fichero en
/sys/block/sdb/device/model que contiene “USB 2.0M
DSC”, por lo que se puede usar la clave ATTRS{model}==“USB
2.0M DSC”
Se pueden utilizar cualquier fichero del directorio /sys/, hasta
un máximo de 5
Es necesario encontrar un directorio en /sys/ que se
corresponda con el hardware e incluya un fichero llamado “dev”.
Todos estos directorios están en /sys/block o en /sys/class
Tema 10. Periféricos – p. 24/34
Udev (x)
Identificando dispositivos a través de los ficheros de “SYSFS” . . .
Una vez encontrado un directorio de ese tipo, la herramienta
udevinfo muestra información sobre el dispositivo que se
puede usar en las reglas. Se puede ejecutar:
# udevinfo -a -p /sys/path/to/hardware/info
Para localizar el directorio se puede usar también udevinfo:
# udevinfo -q path -n /dev/sdc
/block/sda
# udevinfo -a -p ‘udevinfo -q path -n /dev/sdc‘
looking at device ’/block/sdc’:
KERNEL=="sdc"
SUBSYSTEM=="block"
DRIVER==""
ATTR{capability}=="13"
ATTR{stat}=="
44
503
1148
ATTR{size}=="2031616"
ATTR{removable}=="1"
ATTR{range}=="16"
ATTR{dev}=="8:32"
284
0
0
Tema 10. Periféricos – p. 25/34
Udev (xi)
# udevinfo -a -p ‘udevinfo -q path -n /dev/sdc‘
.....
looking at parent device ’/devices/pci0000:00/0000:00:1d.7/usb1/1-5’:
KERNELS=="1-5"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{serial}=="575104000138"
********
ATTRS{product}=="USB BAR
"
ATTRS{manufacturer}=="
"
ATTRS{quirks}=="0x0"
ATTRS{maxchild}=="0"
ATTRS{version}==" 2.00"
ATTRS{devnum}=="4"
..........
looking at parent device ’/devices/pci0000:00/0000:00:1d.7/usb1’:
KERNELS=="usb1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{serial}=="0000:00:1d.7"
********
ATTRS{product}=="EHCI Host Controller"
Tema 10. Periféricos – p. 26/34
Udev (xii)
¿Cómo se crean el resto de ficheros del directorio
/dev/ (los que están allí nada más arrancar)?
Al empezar el arranque, el fichero initrd.img crea
expresamente una serie de dispositivos (como las particiones, los
dispositivos de las terminales, /dev/zero o /dev/null)
Cuando el Init toma el control, se ejecuta start_udev (es
lanzado por /etc/rc.d/rc.sysinit) que crea los ficheros indicados
en /etc/udev/devices y lanza el demonio udevd
En el directorio /etc/udev/makedev.d/ se pueden crear
ficheros que contengan los nombres de los dispositivos a crear
en el arranque
Tema 10. Periféricos – p. 27/34
Otras herramientas
lsusb ⇒ Visualiza información sobre todos los buses USB del sistema y todos los
dispositivos conectados a ellos
-v ⇒ Imprimir información detallada de los dispositivos
-D device ⇒ Información sólo sobre el dispositivo indicado, donde, por ejemplo
“device” se especifica como /proc/bus/usb/001/001
Bus 002 Device 002: ID 046d:c016 Logitech, Inc.
Bus 001 Device 001: ID 0000:0000
lspci ⇒ Visualiza información sobre todos los buses PCI del sistema y todos los
dispositivos conectados a ellos
-v ⇒ Imprimir información detallada de los dispositivos
00:02.0 VGA compatible controller: Intel Corp. 82852/855GM
Integrated Graphics Device (rev 02)
hwbrowser ⇒ Visualiza información gráficamente sobre los dispositivos instalados
en el sistema
lshw ⇒ Listado detallado del hardware conectado al equipo
lshw-gui ⇒ Visualiza gráficamente un listado detallado del hardware del equipo
Tema 10. Periféricos – p. 28/34
HAL (Hardware Abstraction Layer)
HAL es una capa de abstracción del hardware:
Proporciona información sobre los dispositivos hardware que hay
conectados en el sistema
Para cada dispositivo, mantiene información detallada del mismo
Permite que el software a nivel de “escritorio” pueda reaccionar
ante los cambios de configuración del hardware (le informa de los
cambios producidos)
Para HAL cada elemento hardware es un “objeto” de dispositivo, al
que asigna un identificador único y tiene un conjunto de propiedades
almacenadas como clave/valor
El valor de estas propiedades lo obtiene del propio hardware, de
ficheros de información de los dispositivos o de la configuración
actual del dispositivo
El valor de estas propiedades determinará el tratamiento que hay
que hacer al dispositivo
Tema 10. Periféricos – p. 29/34
HAL (ii)
HAL puede informar a otras aplicaciones cuando un dispositivo es
añadido o eliminado, o cuando cambian las propiedades del mismo,
para que estas aplicaciones actúen en consecuencia:
Se conecta un “pen-drive” ⇒ avisa a un programa para que monte el dispositivo
Se inserta un cd de música ⇒ avisa a un programa para que lo reproduzca
Se inserta un cd de datos ⇒ lo notifica a un programa que lo montará
El demonio hald es el encargado de hacer esta tarea:
Mantiene la base de datos de los objetos hardware (obteniendo la
información de los ficheros de información de los dispositivos y del propio HW)
Controla el “ciclo de vida” de los dispositivos
Proporciona una descripción rica y amplia de las características
de los elementos hardware
Notifica los cambios hardware:
Mediante “callouts” a los componentes a nivel de sistema
Mediante el D-BUS a aplicaciones a nivel de “escritorio”
Tema 10. Periféricos – p. 30/34
HAL (iii)
Los “callouts” son programas que se invocan cuando la lista de
dispositivos manejada por HAL cambia o las propiedades de un
dispositivo cambian
Estos programas permiten mantener de forma “correcta” el sistema,
p.e. cambiando los permisos de un fichero de dispositivo, preparando
el sistema para montar el SF o configurando el subsistema de red
Los programas “callouts” están indicados en los ficheros de
“información” del HAL (/usr/share/hal/fdi/) y son ejecutados
por el demonio hald cada vez que se produce un cambio hardware
Ejemplos de programas “callouts”:
(suelen estar en /usr/libexec/)
hal_lpadmin ⇒ Programa de CUPS para añadir/eliminar una impresora que se
conecta/desconecta (es el paquete hal-cups-utils)
hal-storage-mount ⇒ Realiza el montaje del dispositivo conectado
hal-storage-unmount ⇒ Desmonta el dispositivo
hal-storage-eject ⇒ “Expulsar” el cd
Tema 10. Periféricos – p. 31/34
HAL (iv)
Las aplicaciones pueden usar HAL para obtener información de los
dispositivos e interactuar con el dispositivo a través del núcleo
Ejemplos de estas aplicaciones serían: programas para manejar un
cámara conectada o para montar de forma automática un pen–drive
Un ejemplo de aplicaciones a nivel de escritorio que hacen uso de la
información de HAL es gvfs que, de forma automática, monta los
nuevos dispositivos, abre el explorador de ficheros o reproduce cd’s
de música o de vídeo, . . . , (antes lo hacía gnome-volume-manager)
En el caso de KDE, el demonio kded es el encargado de recibir las
notificaciones de los cambios hardware y actuar en consecuencia.
Por ejemplo, si el dispositivo conectado es un pen–drive:
Informa al usuario del evento y le pregunta si desea “abrir” el dispositivo. En caso
afirmativo, ejecuta “konqueror” para el directorio que hace de punto de montaje
Tema 10. Periféricos – p. 32/34
HAL (v)
hald-addon-* ⇒ Escuchan cambios en los dispositivos que hald
no detecta (insertar un cd en el lector) e informa al hald para que actúe
lshal ⇒ Muestra un listado detallado de todos los dispositivos
hardware que hay conectados en el sistema
−−monitor ⇒ Ejecutado con esta opción, monitoriza los cambios producidos al
conectar o desconectar un dispositivo, o cambiar sus propiedades
hal-device ⇒ Lista todos los dispositivos conectados
gnome-device-manager ⇒ Herramienta gráfica que lista los
dispositivos conectados, monitorizando los posibles cambios
D-BUS es un sistema para comunicación entre procesos, que
proporciona un sistema de bus de mensajes para realizar dicha tarea
Proporciona una librería que permite establecer y realizar una conexión entre dos
aplicaciones
Un demonio gestiona la conexión y envía los mensajes de una aplicación a la otra
HAL lo usa para comunicar cambios HW a las aplicaciones a nivel de “escritorio”
Tema 10. Periféricos – p. 33/34
The magic SysRq key
Es un combinación “mágica” de teclas con la que se pide al núcleo
que realice una tarea concreta en caso de “emergencia”, que hará
salvo que esté completamente bloqueado
Se activa poniendo un “1” en el fichero /proc/sys/kernel/sysrq
Para activarla siempre en el fichero /etc/sysctl.conf se pone:
kernel.sysrq = 1
La combinación de teclas es AltGr + PetSis + tecla, donde
algunas opciones son:
‘b’ ⇒ reinicia el sistema inmediatamente sin sincronizar o desmontar los discos
‘s’ ⇒ sincroniza todos los sistemas de ficheros montados
‘u’ ⇒ remonta todos los sistemas de ficheros en modo de sólo lectura
‘p’ ⇒ muestra información en la consola sobre el estado de los registros y los
flags del procesador
‘t’ ⇒ muestra información sobre las tareas en ejecución y su información
También se puede escribir el carácter en /proc/sysrq-trigger
(por ejemplo para reiniciar “echo b > /proc/sysrq-trigger”)
Tema 10. Periféricos – p. 34/34