Hardware and Device Configuration Información general acerca del hardware Conceptos clave Los controladores de dispositivos se pueden compilar en una imagen estática de kernel o ejecutar como módulos de kernel. Los controladores de dispositivo ejecutados como módulos kernel pueden configurarse en el archivo /etc/modprobe.conf. Red Hat mantiene una base de datos de hardware compatible accesible en http://bugzilla.redhat.com/hwcert. Los mensajes de kernel se almacenan en el buffer dmesg. El contenido de un buffer dmesg se puede examinar con el comando dmesg. El archivo /var/log/dmesg contiene una instantánea del buffer dmesg tomada inmediatamente después del arranque más reciente. El archivo /proc/cpuinfo entrega información acerca de los procesadores del sistema. El archivo /proc/meminfo entrega información acerca de la memoria del sistema. El directorio /proc/ide/ entrega información acerca de los dispositivos IDE del sistema.
Hardware and Device Configuration Discusión Controladores de dispositivo Una de las funciones primarias del kernel de Linux es ofrecer acceso al hardware de la máquina. Algunos componentes de hardware, tales como el CPU o la memoria, son tan fundamentales que su administración es parte de la funcionalidad central del kernel. Otro hardware, como por ejemplo las tarjetas de interfaz, los dispositivos USB y los discos, utilizan componentes más especializados del kernel conocidos como controladores de dispositivos. Muchos controladores de dispositivos se configuran, por lo general al pasar parámetros al controlador de dispositivo a medida que se carga. Una de las razones de la popularidad del kernel de Linux es su diseño modular. Los controladores de dispositivo se pueden implementar de dos maneras: como parte de la imagen estática de kernel o como un módulo de kernel. La forma como se implementa un controlador de dispositivo determina cómo se especifican los parámetros de configuración (si hay alguno). La imagen estática del kernel La imagen estática del kernel es el archivo que se carga al iniciar su sistema. En Red Hat Enterprise Linux, el archivo de imagen convencionalmente reside en el directorio /boot con el número de versión vmlinuz-versión, donde versión se remplaza por el número de la versión de kernel. Los controladores de dispositivo utilizados en el proceso de arranque antes de que los sistemas de archivos estén disponibles, tales como los controladores del dispositivo IDE y los controladores de consola, suelen implementarse en la imagen central de kernel. Puesto que estos controladores de dispositivo se cargan como parte de la imagen de kernel misma, la única forma de pasarles los parámetros es en el tiempo de arranque. La mayoría de los gestores de arranque, tales como GRUP y LILO, le permiten a los usuarios pasar parámetros al kernel a medida que se arranca a través de la línea de comando del kernel. Aquí, solo presentamos el concepto de línea de comando de kernel. Más adelante en este curso trataremos la forma de configuración. Al leer el archivo /proc/cmdline reporta la línea de comando utilizada al arrancar la instancia actual del kernel. [root@station root]# cat /proc/cmdline ro root=label=/ vga=0x317 5 La documentación sobre algunos de los parámetros de tiempo de arranque más utilizados se pueden encontrar en la página del manual bootparam(7). Módulos del kernel Los controladores de dispositivo sumplementarios que no se necesitan durante las etapas iniciales del sistema de arranque, tales como los controladores de interfaz de red y los controladores de tarjetas de sonido, suelen implementarse como módulos del kernel. Los módulos de kernel existen como archivos en el sistema de archivos, por lo general por debajo del directorio /lib/modules/versión, donde de nuevo versión, se remplaza por la versión relevante del kernel. Los módulos de kernel de Linux se cargan "a solicitud": como el kernel trata primero de acceder a un dispositivo particular, el controlador de dispositivo para ese dispositivo se carga desde el sistema de archivo. Si el dispositivo correspondiente a un módulo de controlador de dispositivo particular no está presente (o no se utiliza), ese módulo de kernel nunca se carga. El comando lsmod generará una lista de los módulos de kernel cargados o igualmente se puede examinar el archivo /proc/modules. [root@station root]# lsmod Module Size Used by Not tainted sd_mod 13516 2 (autoclean) usb-storage 74656 1 scsi_mod 107544 2 [sd_mod usb-storage] parport_pc 19076 1 (autoclean) lp 8996 0 (autoclean) Los parámetros se pueden pasar a los controladores de dispositivos modulares cuando estén cargándose. Cada vez que un módulo es cargado "a solicitud" del kernel, el archivo /etc/modprobe.conf busca parámetros de módulo. Por ejemplo, el módulo de kernel sb que implementa el controlador de dispositivo para las tarjetas de sonido de SoundBlaster se puede configurar para esperar un tipo particular de tarjeta de sonido al pasar un parámetro de la forma tipo=n, donde N se remplaza por un número entero. Si se añade la línea correcta al archivo /etc/modprobe.conf, este parámetro se establecerá cada vez que el kernel cargue el módulo sb. [root@station root]# cat /etc/modprobe.conf options sb type=3 alias eth0 e100 alias eth1 airo alias snd-card-0 snd-intel8x0 install snd-intel8x0 /sbin/modprobe --ignore-install snd-intel8x0 && /usr/sbin/alsactl restore >/dev/null 2>&1 remove snd-intel8x0 { /usr/sbin/alsactl store >/dev/null 2>&1 : ; }; /sbin/modprobe -r --ignore-remove snd-intel8x0 alias usb-controller uhci-hcd Esta línea especifica los parámetros que se van a utilizar cada vez que el módulo de kernel sb se cargue de modo implícito. [Note] No es necesario "instalar" controladores de dispositivo La instalación de los controladores de dispositivo para dispositivos particulares no es problema para Linux como sí lo es para otros sistemas operativos. Debido a la naturaleza modular del kernel y a las libertades provistas por el software de código abierto, se incluyen por defecto módulos para los hardware más compatibles. Un controlador de dispositivo implementado como módulo de kernel sólo se carga si el hardware que administra se detecta, por lo tanto, el único recurso que se pierde es un poco de espacio en disco.
Aunque no se han discutido los detalles de un controlador de dispositivo en particular, esta discusión ha tratado de introducir los siguientes conceptos: Los controladores de dispositivo en Linux se pueden implementar ya sea de modo estático o modular. Los controladores de dispositivo estático se configuran en el tiempo de arranque a través de la línea de comando del kernel. Los controladores de dispositivo modular se configuran principalmente a través del archivo /etc/modprobe.conf en tiempo de carga. Detalles sobre la configuración de la línea de comando de kernel, administración de módulos de kernel en general y la función del archivo /etc/modprobe.conf se verán más adelante. Base de datos de hardware soportado por Red Hat Las ventajas y desventajas del modelo de desarrollo de código abierto son en particular relevantes al soporte de hardware. La desventaja: puesto que la comunidad de código abierto no suele relacionarse con los proveedores de hardware y desconoce información que aún no se ha publicado (o algunas veces cualquier información), la versión más reciente de una tarjeta de vídeo determinada, una tarjeta de sonido u otro dispositivo suele no ser compatible, (la aparición de Linux y sus distribuidores, tales como Red Hat, está cambiando esta tendencia). La ventaja es que alguien en la comunidad de código abierto querrá aprovechar las características del nuevo dispositivo y es muy probable que al final sea compatible. Debido a estas influencias que compiten, mantener el rastro del hardware compatible y del que no lo es puede ser un problema. Red Hat mantiene una base de datos de hardware compatible en http://bugzilla.redhat.com/hwcert. La base de datos de búsqueda ayuda a identificar hardware que es respaldado por la distribución de Red Hat (y los servicios de soporte técnico de Red Hat) y el hardware que se sabe que funciona, pero oficialmente no está respaldado por Red Hat. Fuentes de información de hardware Los siguientes recursos se pueden utilizar para ayudar a determinar qué hardware está instalado (y es reconocido por el kernel) en su sistema. Los mensajes de kernel, el buffer dmesg y /var/log/dmesg La primera prueba del hardware detectado es el flujo de mensajes que el kernel emite durante el arranque, salen rápidamente de la parte superior de la pantalla y aparentemente nunca se vuelen a ver. Estos mensajes y todos los mensajes emitidos por el kernel, se almacenan en el buffer de kernel dinámico conocido como el buffer dmesg. Dicho buffer es un "buffer de anillo". Cuando el espacio del buffer se ha utilizado todo con mensajes, comenzará a escribir los mensajes nuevos sobre los más viejos. El contenido actual del buffer dmesg puede vertirse en la salida estándar con el comando dmesg. Pronto después del arranque más reciente, el buffer comienza con los mismos mensajes vistos en el tiempo de arranque. [root@station root]# dmesg Linux version 2.6.9-5.EL (bhcompile@decompose.build.redhat.com) (gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) #1 Wed Jan 5 19:22:18 EST 2005 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000-000000000009f800 (usable) BIOS-e820: 000000000009f800-00000000000a0000 (reserved) BIOS-e820: 00000000000ca000-00000000000cc000 (reserved) BIOS-e820: 00000000000dc000-00000000000e0000 (reserved) BIOS-e820: 00000000000e4000-0000000000100000 (reserved) Sin embargo, si una máquina ha estado ejecutándose por un tiempo, el buffer será consumido por mensajes intermitentes de kernel y esta información se perderá. Durante el proceso de inicio de Red Hat Enterprise Linux, sin embargo, se registra en el archivo /var/log/dmesg una instantánea del buffer dmesg. Este archivo se sobrescribe en cada arranque por lo tanto su contenido mostrará el inicio más reciente. La utilidad kudzu La utilidad kudzu es una utilidad de arranque que detecta hardware recién creado o suprimido y configura la máquina de modo correcto. Aunque kudzu no reporta directamente el hardware detectado, el examinar su infraestructura ayuda a entender cómo se presenta la configuración de hardware en el sistema de Red Hat Enterprise Linux. Comenzaremos por analizar un directorio con el que se familiarizará a medida que el curso progrese, el directorio /etc/sysconfig. En Red Hat Enterprise Linux, este directorio sirve como repositorio general de información de configuración de software y hardware. [root@station root]# ls /etc/sysconfig/ apmd grub mouse system-config-users apm-scripts harddisks named redhat-logviewer authconfig hwconf network rhn clock i18n networking samba console init network-scripts sendmail desktop installinfo ntpd squid dhcpd iptables pcmcia static-routes dhcrelay irda pgsql syslog firstboot keyboard rawdevices tux gpm kudzu system-config-securitylevel xinetd El archivo hwconf es una base de datos de texto del actual hardware detectado mantenido por kudzu. El archivo kudzu sirve para configurar qué tan agresivamente kudzu busca hardware recién detectado. Podría pensar que esta discusión se centrará en el archivo de configuración /etc/sysconfig/kudzu. En realidad, este archivo es de poco interés. Cuando kudzu realiza su búsqueda, podría enviar la basura a las líneas seriales y otras fallas menores. Si esto podría ser un problema, se puede poner en modo de "seguridad" editando la última línea, escribiendo SAFE=yes.
[root@station root]# cat /etc/sysconfig/kudzu # Set to anything other than 'no' to force a 'safe' probe on startup. # 'safe' probe disables: # - serial port probing # - DDC monitor probing # - PS/2 probing SAFE=no En su lugar, nuestra discusión se centrará en bases de datos utilizadas por kudzu. La primera, /etc/sysconfig/hwconf es una base de datos dinámica del hardware detectado actualmente. Una lectura rápida a este archivo le dará elementos para comprender el hardware de la máquina actual. [root@station root]# head /etc/sysconfig/hwconf - class: OTHER bus: PCI detached: 0 driver: agpgart desc: "Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge" vendorid: 8086 deviceid: 7190 subvendorid: 0000 subdeviceid: 0000 [root@station root]# grep desc /etc/sysconfig/hwconf desc: "Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge" desc: "Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge" desc: "Intel Corp. 82371AB/EB/MB PIIX4 ISA" desc: "Intel Corp. 82371AB/EB/MB PIIX4 IDE" desc: "Intel Corp. 82371AB/EB/MB PIIX4 ACPI" desc: "USB UHCI Root Hub" desc: "3Com Corporation 3c556 Hurricane CardBus" desc: "Generic Mouse (PS/2)" desc: "ESS Technology ES1983S Maestro-3i PCI Audio Accelerator" desc: "3Com Corporation Mini PCI 56k Winmodem" desc: "ATI Rage Mobility M3 AGP 2x" desc: "3.5" 1.44MB floppy drive" desc: "IBM-DJSA-210" desc: "Intel Corp. 82371AB/EB/MB PIIX4 USB" desc: "Texas Instruments PCI1420" desc: "Texas Instruments PCI1420" Las bases de datos restantes se encuentran en el directorio /usr/share/hwdata. Este directorio almacena catálogos de texto de hardware que el sistema de Red Hat Enterprise Linux espera encontrar. Por ejemplo, el archivo /usr/share/hwdata/pcitable presenta dispositivos PCI por ID de vendedor e ID de dispositivo. Cuando se detecta un dispositivo PCI particular, este archivo se utiliza para asociar un nombre de texto al dispositivo y posiblemente un módulo de kernel relevante que sirva como controlador de dispositivo del dispositivo. [root@station root]# ls /usr/share/hwdata/ CardMonitorCombos Cards MonitorsDB pci.ids pcitable upgradelist usb.ids [root@station root]# cat /usr/share/hwdata/pcitable 0x0675 0x1700 "unknown" "Dynalink IS64PH ISDN Adapter" 0x0675 0x1702 "hisax" "Dynalink IS64PH ISDN Adapter" 0x09c1 0x0704 "unknown" "Arris CM 200E Cable Modem" 0x0e11 0x0001 "ignore" "Compaq PCI to EISA Bridge" 0x0e11 0x0002 "ignore" "Compaq PCI to ISA Bridge" 0x0e11 0x0046 "cciss" "Compaq Smart Array 64xx" 0x0e11 0x0049 "unknown" "Compaq NC7132 Gigabit Upgrade Module" 0x0e11 0x004a "unknown" "Compaq NC6136 Gigabit Server Adapter" 0x0e11 0x0508 "tmspci" "Compaq Netelligent 4/16 Token Ring" 0x0e11 0x1000 "ignore" "Compaq Triflex/Pentium Bridge, Model 1000" Estos archivos de base de datos de texto proveen elementos para entender los tipos de hardware que Red Hat Enterprise Linux espera encontrar. El sistema de archivos /proc Otro recurso para determinar la configuración de hardware es un sistema de archivos proc. El sistema de archivos proc es un sistema de archivos virtual implementado por el kernel de Linux, montado en el directorio /proc. [root@station hwdata]# mount /dev/hda3 on / type ext3 (rw) none on /proc type proc (rw) usbdevfs on /proc/bus/usb type usbdevfs (rw) /dev/hda1 on /boot type ext3 (rw) El sistema de archivos virtual proc, junto con el dispositivo none, es montado en el punto de montaje /proc. Qué es un sistema de archivos virtual? Los archivos /procno existen en ningún medio físico. Podrían considerarse un producto de la imaginación del kernel, es decir un producto útil. Cuando se lee desde un archivo, el kernel retorna una respuesta generada dinámicamente, (algunos archivos dentro de /proc al escribirse, se pueden utilizar para cambiar parámetros dentro del kernel). Cuando el kernel ya no existe, como por ejemplo, cuando la máquina está apagada, los archivos en el sistema de archivos proc ya tampoco existen, en ninguna forma. En nuestra discusión de varios hardware nos enfocaremos en archivos dentro del sistema de archivos /proc. Más adelante en el curso nos centraremos en el uso del sistema de archivos /proc como mecanismo para la configuración de los parámetros de kernel. Mientras tanto, la página del manual proc(5), el comando cat y algún tiempo dedicado a explorar pueden servir de introducción. El navegador de Hardware GNOME Por último, mencionamos el navegador de Hardware GNOME, el cual puede iniciarse al seleccionar desde el menú principal del sistema Herramientas del Sistema:Navegador de Hardware o desde la línea de comando con hwbrowser. Esta aplicación gráfica recoge gran parte de la
información importante que se puede hallar en varias de las fuentes mencionadas anteriormente en una sola utilidad. Figure 1. El navegador de hardware GNOME Soporte de procesador Aparte de la familia de procesadores Intel x86 (y compatibles), la distribución de Red Hat Enterprise Linux soporta el IA-64 (procesadores Intel de 64 bits), Compaq Alpha y las iseries y eseries de IBM y arquitecturas S/390. Este curso y los certificados de RHCE, cubren solo la versión compatible de la distribución x86. Multiprocesamiento simétrico (SMP) Linux soporta múltiple procesamiento simétrico con compatibilidad hasta de 32 CPU, aunque más de ocho rara vez se implementan en la arquitectura x86. La granularidad del multiprocesador se presenta de forma natural en el nivel del proceso (i.e., con dos CPU, un único proceso no se ejecutará dos veces con la misma rapidez, pero dos procesos se pueden ejecutar simultáneamente, cada uno en una CPU independiente). Con el desarrollo esperado, Linux también soporta procesos multihilos, donde un solo proceso puede generar múltiples hilos de ejecución que se pueden ejecutar más tarde simultáneamente en múltiples CPU. /proc/cpuinfo El archivo del sistema de archivos proc /proc/cpuinfo entrega información acerca del CPU detectado, como se muestra en el ejemplo. [root@station root]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 6 cpu MHz : 548.323 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1094.45 Los siguientes campos tienden a proveer la información más útil. El número del procesador. En una sola maquina procesadora, el número es 0. En una máquina SMP, el archivo cpuinfo contiene múltiples estrofas, cada una identificada por un número de procesador distinto. El modelo de CPU. La velocidad de la CPU. El tamaño de la memoria caché de CPU, la cual reduce de modo significativo tiempos de acceso de memoria. Varias banderas, las cuales indican capacidades de la CPU. Por ejemplo, la bandera tsc indica que la CPU soporta el contador de marcas de tiempo (que sirve para precisar información de temporización), mientras que la bandera pae especifica que la CPU puede
Memoria soportar extensiones de dirección físicas (más información más adelante). Una estádística sesgada y a menudo mal utilizada que suele utilizarse para correlacionar ciclos de CPU al tiempo mundial real. Solo merece mencionarse debido a que suele utilizarse mal como medida de velocidad del procesador. En su lugar, utilice el parámetro anterior MHz. Debido a que la familia x86 tiene una arquitectura de 32 bits, se podría esperar que el kernel de Linux soporte 4 gigabytes de memoria (donde 2 elevado a la 32 potencia es igual a 4 gigabytes). Aunque esto es cierto, los detalles de la implementación necesitan más claridad. En su forma más sencilla, el kernel de Linux soporta hasta 1 Gigabyte de memoria. Se puede disponer de más memoria compilando en el soporte de "alta memoria", a través del cual se puede acceder a más memoria (aunque no toda al mismo tiempo). De modo intuitivo, hay algunos procesadores de 32 bits que soportan "extensiones de dirección física" (PAE), a través de las cuales un procesador de 32 bits puede acceder hasta 62 gigabytes de memoria (aunque de nuevo, no toda al mismo tiempo). Con el fin de ofrecer flexibilidad, la distribución de Red Hat se entrega con múltiples versiones de kernel. Si el instalador detecta un procesador de la generación Intel 586 (o menor), se instala un kernel configurado para un gigabyte de memoria. Si el instalador detecta un procesador Intel 686 (o Athlon), se instala un kernel configurado para 4 gigabytes de memoria. Un kernel configurado para utilizar extensiones PAE se incluye en el paquete RPM de kernel-bigmem, pero se debe instalar manualmente. El kernel "bigmen" soporta más de 4 gigabytes de memoria, pero solo se ejecuta en chips que soportan extensiones RAE. Aparte de garantizar que el kernel adecuado está instalado, no hay otras funciones para el administrador. El kernel debería detectar automáticamente toda la memoria disponible. /proc/meminfo El archivo del sistema de archivos proc /proc/meminfo proporciona estadísticas acerca de la cantidad de memoria detectada y la utilización actual de memoria como se observa en el siguiente ejemplo. [root@station root]# cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 261357568 123998208 137359360 0 14143488 60194816 Swap: 534634496 0 534634496 MemTotal: 255232 kb MemFree: 134140 kb MemShared: 0 kb Por ahora, nuestra discusión se limita a los siguiente campos: Los primeros tres números dan una cantidad total de la memoria física detectada y un análisis de cuánta memoria se utiliza y cuánto espacio libre tiene. El cuadro a continuación presenta la misma información reportada en tamaños convencionales de computadores (donde 1 "kb" = 1024 bytes). La mayoría de las estadísticas restantes en este archivo reportan en más detalle cómo se utiliza la memoria "usada". Volveremos a este tema más adelante. Discos duros Como los procesadores y la memoria, el kernel es responsable de la detección automática de los discos duros. Los discos duros suelen utilizar ya sea el protocolo de bus IDE o el SCSI. Linux utiliza la siguiente nomenclatura para cada uno. Discos IDE y /proc/ide El protocolo de bus IDE permite a los computadores tener múltiples controladores, cada uno de los cuales puede administrar dos discos (conocidos como los controladores "maestro" y "esclavo"). Muchos de los escritorios de computadores comunes se distribuyen con dos dispositivos IDE conocidos como "primarios " y "secundarios". Esta configuración permite la conexión de cuatro dispositivos IDE conocidos como dispositivos "maestro primario" y "esclavo primario", "maestro secundario" y "esclavo secundario". La función de un dispositivo particular se determina por su forma de conexión a la máquina. Linux se refiere a los dispositivos IDE como hdx, donde x se remplaza por una sola letra minúscula. Las letras se asignan directamente a las posiciones físicas del dispositivo. Table 1. Convenciones de nombre IDE para disco duro Nombre Posición hda maestro primario hdb esclavo primario hdc maestro secundario hdd esclavo secundario hde maestro terciario El directorio /proc/ide del sistema de archivos proc contiene subdirectorios para cada dispositivo IDE detectado llamado así por el dispositivo. (En realidad, los archivos son enlaces simbólicos, que refieren a subdirectorios de directorios llamados ide0, ide1. Estos directorios refieren al controlador ide primario, al controlador IDE secundario, etc) Un ls del directorio /proc/ide puede determinar
rápidamente qué discos IDE son reconocidos por el kernel. En el siguiente ejemplo, sólo se detecta un dispositivo (hda). [root@station ide]# ls /proc/ide/ drivers hda ide0 piix El subdirectorio relacionado con un disco específico contiene archivos que proveen información (a menudo de bajo nivel) acerca del disco, (en la siguiente salida, observe que el archivo llamado capacity se duplica! En un sistema normal de archivos, esto no se permitiría. En el sistema de archivo proc, es un error del kernel). [root@station ide]# ls /proc/ide/hda cache capacity geometry media settings smart_values capacity driver identify model smart_thresholds [root@station ide]# head /proc/ide/hda/* ==> /proc/ide/hda/cache <== 384 ==> /proc/ide/hda/capacity <== 11733120 ==> /proc/ide/hda/capacity <== 11733120 ==> /proc/ide/hda/driver <== ide-disk version 1.17 ==> /proc/ide/hda/geometry <== physical 12416/15/63 logical 730/255/63 ==> /proc/ide/hda/identify <== 045a 3080 c837 000f 0000 0000 003f 0000 0000 0000 2020 2020 2020 2020 2034 3256 ==> /proc/ide/hda/media <== disk ==> /proc/ide/hda/model <== IBM-DJSA-210 ==> /proc/ide/hda/settings <== name value min max mode ---- ----- --- --- ---- acoustic 0 0 254 rw address 0 0 2 rw bios_cyl 730 0 65535 rw bios_head 255 0 255 rw bios_sect 63 0 63 rw breada_readahead 8 0 255 rw bswap 0 0 1 r current_speed 66 0 70 rw Discos SCSI La nomenclatura de Linux para los discos SCSI no es tan transparente como para los discos IDE. Por lo general, Linux utiliza nombres de la forma sdx, donde x se remplaza por una o más letras minúsculas. Infortunadamente, los nombres no pueden asignarse directamente a la posición física del dispositivo, ni siquiera a un parámetro utilizado comúnmente referido como el ID SCSI. Linux suele referirse al primer SCSI detectado como sda, al segundo dispositivo como sdb y así sucesivamente. Sin embargo, predecir cuál de los dispositivos conectados considerará Linux el "primero", "segundo" y así sucesivamente, es bastante difícil. Peor aún, si se añade a la máquina un nuevo dispositivo SCSI, un disco preexistente llamado sdb se podría convertir (tras el reinicio) en sdc con el dispositivo recién conectado que toma el nombre de sdb. Aunque el sistema de archivos provee un directorio /proc/scsi y un archivo /proc/scsi/scsi que lista todos los discos detectados, ninguno proporciona información sobre los nombres de discos SCSI reconocidos actualmente. El mejor método es observar los mensajes del kernel (cuando son reportados por el comando dmesg o en el archivo /var/log/dmesg) sobre los discos SCSI detectados.
Hardware and Device Configuration Ejemplos Familiarizándose con una nueva máquina El usuario elvis ha iniciado sesión en su cuenta en una nueva máquina y quisiera saber algo más acerca de su hardware. Primero, examina la CPU de su máquina. [elvis@station elvis]$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 6 cpu MHz : 697.867 cache size : 256 KB fdiv_bug : no Observa que el procesador es un Intel Pentium III de 800 MHz con una memoria caché de 256 kilobytes. Luego examina la memoria de la máquina. [elvis@station elvis]$ cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 261357568 238727168 22630400 0 36249600 149045248 Swap: 534634496 106676224 427958272 MemTotal: 255232 kb MemFree: 22100 kb MemShared: 0 kb Buffers: 35400 kb Cached: 102472 kb SwapCached: 43080 kb Al observar la línea MemTotal: determina que la máquina tiene 256 megabytes de RAM. Luego revisa qué dispositivos están conectados, si son discos duros o CD- ROMS y el modelo. [elvis@station elvis]$ ls /proc/ide/ drivers hda hdb hdc ide0 ide1 piix [elvis@station elvis]$ head /proc/ide/hd*/media ==> /proc/ide/hda/media <== disk ==> /proc/ide/hdb/media <== disk ==> /proc/ide/hdc/media <== cdrom [elvis@station elvis]$ head /proc/ide/hd*/model ==> /proc/ide/hda/model <== Maxtor 51536H2 ==> /proc/ide/hdb/model <== ST310212A ==> /proc/ide/hdc/model <== LTN485
Hardware and Device Configuration Ejercicios en línea [Warning] Lab Exercise Objetivo: Determinar la información sobre la configuración del hardware en la máquina local. Tiempo estimado: 10 minutos. Specification Reúna la siguiente información sobre el hardware de su máquina y almacénela en los archivos especificados. Cada archivo debe contener una sola respuesta. Archivo ~/lab2.1/cpuspeed ~/lab2.1/cpucache ~/lab2.1/memsize ~/lab2.1/nicdriver ~/lab2.1/numide Contenido La velocidad de su procesador actual en megahertz. El tamaño de su caché de CPU en kilobytes. La cantidad de memoria física en megabytes. El nombre del módulo del kernel que sirve de controlador de dispositivo para su interfaz de red eth0, (si no tiene una interfaz eth0, ponga la palabra en inglés "none"). El número de dispositivos IDE conectados simultáneamente en su máquina. Si usted ha realizado el laboratorio correctamente, podrá generar salida similar a la siguiente, (no se preocupe si sus valores reales difieren). [student@station student]$ head lab2.1/* ==> lab2.1/cpucache <== 256 ==> lab2.1/cpuspeed <== 697.867 ==> lab2.1/memsize <== 255 ==> lab2.1/nicdriver <== 3x59x ==> lab2.1/numide <== 1 Resultados A title Question 1 1. Los archivos presentados anteriormente, cada uno contiene una respuesta de una sola palabra. grade
Hardware and Device Configuration Dispositivos PCI Conceptos clave El comando lspci lista todos los dispositivos PCI detectados. Incluyendo la información de configuración de la opción -v asociada con cada dispositivo. El archivo /proc/interrupts lista las tareas de la línea de solicitud de interrupción del sistema (IRQ) y la actividad. El archivo /proc/ioports lista las tareas del puerto E/S del sistema. El archivo /proc/iomem lista las direcciones físicas del RAM del sistema y los buffer de dispositivo de la memoria.
Hardware and Device Configuration Discusión El bus PCI El bus PCI juega un papel primordial en la mayoría de las arquitecturas x86compatibles. Todos los dispositivos PCI comparten un protocolo de configuración común, los dispositivos PCI incluyen dispositivos de tarjetas de expansión comunes, no solo tarjetas de sonido y controlador de red, sino también puentes que conectan otros buses con el bus PCI primario. Puede utilizar el comando lspci para listar todos los dispositivos PCI conectados, como en el siguiente ejemplo. [root@station root]# lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8375 [KM266/KL266] Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] 00:05.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03) 00:05.1 Input device controller: Creative Labs SB Audigy MIDI/Game port (rev 03) 00:05.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port 00:07.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100 model NC100 (rev 11) 00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74) 01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266] Este dispositivo conecta el AGP ("Puerto Gráfico avanzado"), utilizado por muchas tarjetas de vídeo, al bus PCI. La tarjeta de sonido Audigy es un ejemplo de un dispositivo PCI "multifuncional". Esta y las siguientes tres líneas identifican el dispositivo único realizando la función de los dispositivos individuales: una tarjeta de sonido, un controlador MIDI/joystick y un controlador FireWire. Estos dos dispositivos son dos tarjetas individuales de interfaz de red, (aunque no es evidente desde esta salida, uno se suministra con la tarjeta madre como componente "a bordo" y el otro es una tarjeta de expansión). Estos tres "dispositivos" PCI son ejemplos de controladores para buses alternos: el bus USB, el bus ISA y el bus IDE. El bus PCI suministra la infraestructura para los otros buses. Observe que los dispositivos IDE, ISA y USB no serán listados por el comando lspci, sólo los controladores de bus. El comando lspci es un buen punto de partida para averiguar qué hardware está conectado a una máquina desconocida. Recursos de hardware La arquitectura x86 ofrece mecanismos para que dispositivos de hardware interactúen con el kernel de linux. Cuando se agregan nuevos dispositivos a la máquina, se debe tener cuidado al compartir los siguientes recursos sin conflictos entre los diversos dispositivos. Línea de solicitud de interrupción (IRQ) y /proc/interrupts Cada dispositivo necesita alguna forma de llamar la atención del kernel como si le dijeran "hola, alguien acaba de mover el ratón y quiero decírselo" o "Hola, terminé de transferir ese bloque de información al disco tal como me lo pidió". Muchos dispositivos utilizan una línea de solicitud de interrupción o un IRQ, para este propósito. En la arquitectura x86, 15 líneas IRQ están disponibles y múltiples dispositivos pueden compartir una sola línea IRQ. El archivo del sistema de archivos proc /proc/interrupts muestra las líneas IRQ disponibles y los controladores de dispositivo que los están utilizando. El número absoluto de veces que se presenta una interrupción también se incluye (desde que la máquina arrancó).
[root@station root]# cat /proc/interrupts CPU0 0: 6091325 XT-PIC timer 1: 41608 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 0 XT-PIC ehci-hcd 5: 115473 XT-PIC usb-uhci 8: 1 XT-PIC rtc 10: 16384184 XT-PIC usb-uhci, eth0 11: 9720993 XT-PIC usb-uhci, eth1, Audigy 12: 848836 XT-PIC PS/2 Mouse 14: 190363 XT-PIC ide0 15: 1765002 XT-PIC ide1 NMI: 0 ERR: 0 En una máquina SMP, las interrupciones de hardware se hacen en CPU individuales y se incluiría una columna separada de actividad de interrupción para cada CPU. IRQ es utilizada sin variación por el controlador de dispositivo temporizador. El temporizador interrumpe el kernel en una tasa de 100 interrupciones por segundo, solicitando al kernel interrumpir el flujo normal de actividad y realizar cualquier tarea periódica pendiente. Tres controladores de dispositivo no relacionados (el controlador USB, una tarjeta de interfaz de red Ethernet y la tarjeta de sonido Audigy) comparten IRQ 11. El campo NMI cuenta el número de ocurrencias de "interrupciones no enmascarables". Dichas interrupciones se utilizan normalmente para señalar las condiciones de error del hardware de bajo nivel. Los puertos de E/S /proc/ioports Después de obtener la atención del kernel (al provocar una interrupción), los dispositivos suelen realizar algún tipo de transferencia de datos dentro o fuera del sistema. La arquitectura x86 proporciona un espacio de dirección de 16 bits para dispositivos, cuyas direcciones se conocen como puertos de Entrada y Salida. Cuando se comunican con el kernel a través de los puertos de E/S, el kernel y el dispositivo deben coincidir con los puertos que están utilizando. El archivo /proc/ioports del sistema de archivos proc muestra qué puertos han sido reclamados por cuál controlador de dispositivo, (las direcciones de puerto se presentan en dígitos hexadecimales). [root@station root]# cat /proc/ioports 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 03c0-03df : vesafb 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0cf8-0cff : PCI conf1 c000-c01f : Creative Labs SB Audigy c000-c01f : Audigy c400-c407 : Creative Labs SB Audigy MIDI/Game port c800-c8ff : Linksys Network Everywhere Fast Ethernet 10/100 model NC100 c800-c8ff : tulip Buffers de dispositivo de memoria y /proc/iomem Muchos dispositivos modernos implementan su propia memoria, la cual una vez ha sido asignada dentro de un espacio de dirección de memoria, se puede utilizar para transferir datos. Las tarjetas de vídeo son ejemplos clásicos de dispositivos que proporcionan sus propios buffer de memoria. El archivo del sistema de archivos proc /proc/iomem muestra todos los dispositivos cuyos buffer de memoria se han asignado dentro de una memoria física y las direcciones de memoria física asignadas a cada buffer, (listadas en dígitos hexadecimales).
[root@station root]# cat /proc/iomem 00000000-0009fbff : System RAM 0009fc00-0009ffff : reserved 000a0000-000bffff : Video RAM area 000c0000-000c7fff : Video ROM 000f0000-000fffff : System ROM 00100000-2dfeffff : System RAM 00100000-002766f6 : Kernel code 002766f7-00384807 : Kernel data e3000000-e3003fff : Creative Labs SB Audigy FireWire Port e3004000-e30043ff : Linksys Network Everywhere Fast Ethernet 10/100 model NC100 e3004000-e30043ff : tulip e3005000-e30057ff : Creative Labs SB Audigy FireWire Port e3006000-e30060ff : VIA Technologies, Inc. USB 2.0 e3006000-e30060ff : ehci-hcd e3007000-e30070ff : VIA Technologies, Inc. VT6102 [Rhine-II] e3007000-e30070ff : via-rhine En lo referente a este archivo, la memoria principal de la máquina (RAM o "Memoria de acceso aleatorio") se considera "apenas otro dispositivo" y asigna espacios de dirección física más bajos. No es necesario utilizar el espacio de dirección física de modo contiguo (sin espacios). Aquí, la asignación del RAM del sistema se interrumpe para asignar el dispositivo de vídeo VGA. La dirección de este dispositivo se produce al principio en el espacio físico de direcciones y por razones de herencia no se puede mover. La mayoría de los dispositivos modernos que implementan buffer de memoria se asignan a las direcciones superiores del espacio de dirección física. Dispositivos PCI de configuración La conexión de nuevos dispositivos al sistema de Red Hat Enterprise Linux, se realiza generalmente en dos etapas para configurar el kernel que va a utilizar el nuevo dispositivo. Primero, si el controlador de dispositivo para el dispositivo se implementa como un módulo de kernel, el módulo debe cargarse (si no lo está aún). Segundo, el controlador de dispositivo (y el dispositivo) debe configurarse para utilizar alguno o todos los dispositivos mencionados anteriormente de manera que no entren en conflicto con ningun otro dispositivo. A continuación se resume cómo se realiza esto para los dispositivos PCI. Por lo general, ambas etapas se presentan con una intervención mínima por parte del administrador. Carga de controladores de dispositivos modulares Cuando se inicia el sistema después de agregar un nuevo dispositivo PCI, kudzu reconocerá el nuevo dispositivo e interrumpirá el proceso de arranque. Si se asume que el usuario elige configurar el nuevo dispositivo, kudzu, buscará el dispositivo en el archivo /usr/share/hwdata/pcitable mediante el proveedor y el ID del producto examinado. Si la tarjeta se encuentra en el pcitable y el módulo de kernel se asocia con ésta, se crea un alias en el archivo modprobe.conf que conectará el controlador del dispositivo con su rol. A manera de ejemplo considere el siguiente archivo modprobe.conf, el cual se utiliza para configurar los mismos dispositivos hallados con el comando lspcianterior. [root@station root]# cat /etc/modprobe.conf alias eth0 tulip alias eth1 via-rhine alias snd-card-0 audigy alias usb-controller usb-uhci alias usb-controller1 ehci-hcd A menudo, el kernel sabe que debe cargar el módulo apropiado de kernel para cumplir con un rol en particular tal como "el controlador usb" o "la interfaz de red eth0" o el "controlador SCSI", pero no sabe cuál de los controladores de dispositivo modular que podría desempeñar esa función es el adecuado para el hardware local. Utilizando alias en el archivo modprobe.conf, cuando el kernel intenta cargar "la interfaz eth0", el controlador de dispositivo modular apropiado para el hardware local se carga (en este caso, el módulo del kernel tulip). El cuadro siguiente esboza algunas de los "roles" que el kernel conoce y que kudzu (o el instalador de Anaconda) configura modprobe.conf para desempeñarlas correctamente. No se preocupe si el cuadro trata conceptos con los cuales usted no está familiarizado aún, la mayor parte de estos se tratarán más adelante en este curso. Table 1. Alias comunes hallados en modprobe.conf
ethn Alias Role El controlador de dispositivo apropiado para la tarjeta de interfaz de red asociada con la interfaz de red ethn. El controlador del dispositivo apropiado para la tarjeta de sonido asociada con el espacio en snd-card-n el subsistema de sonido. controlador- usb El controlador de dispositivo apropiado para el controlador USB del sistema. scsi_hostadaptor El controlador de dispositivo apropiado para el controlador SCS del sistema. char-major-n block-major-n El controlador de dispositivo asociado con el número mayor de dispositivo de nodos de caractern. El controlador de dispositivo asociado con el número mayor de nodos de dispositivo de bloque N. También puede utilizar y suprimir palabras clave para especificar comandos personalizados utilizados cuando se carga o descarga un módulo particular o cuando se especifican opciones para que sea pasado a un módulo con la palabra clave de opciones. Asignación de recursos Además de cargar el módulo de kernel apropiado, los recursos se deben asignar al dispositivo. Esto suele hacerse en el tiempo de arranque mediante el protocolo Plug n' Play. Todos los dispositivos PCI utilizan un mecanismo común para anunciar las diferentes configuraciones compatibles (tales como IRQ 11 en el puerto de E/S 0xe000 o en el puerto IRQ 10 en el puerto de E/S 0xc800) y para asignar una configuración determinada. En el momento del arranque se examinan todos los dispositivos PCI y se especifican un conjunto de recursos no conflictivos para cada tarjeta. Esto suele ocurrir sin intervención del administrador. Si el comando lspci presentado anteriormente se utiliza con la opción -v reportará los recursos asociados con cada dispositivo. En el siguiente ejemplo, el comando lspci -v revela el puerto IRQ de E/S y la memoria física asignada a la tarjeta Linksys Ethernet (10, 0xc800, y 0xe300400, respectivamente). [root@station root]# lspci -v 00:07.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100 mod el NC100 (rev 11) Subsystem: Linksys: Unknown device 0574 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at c800 [size=256] Memory at e3004000 (32-bit, non-prefetchable) [size=1k] Expansion ROM at <unassigned> [disabled] [size=128k] Capabilities: [c0] Power Management version 2 Ocasionalmente, el administrador podría necesitar modificar estas tareas. Por lo general, esto puede hacerse con las líneas de opción en el archivo modprobe.conf para asociar parámetros con módulos de kernel adecuados. Los nombres de opción relevantes tienden a variar de un módulo a otro. En el apéndice A de Red Hat Enterprise Linux el manual de referencia lista los hardware comúnmente hallados, el módulo de kernel asociado con éste y los parámetros que pasan al módulo de kernel cuando se requiere.
Hardware and Device Configuration Ejemplos Exploración de una nueva máquina El usuario elvis continúa explorando una nueva máquina. Con el fin de descubrir qué dispositivos PCI están conectados a la máquina, elvis utiliza el comando lspci. [elvis@station elvis]$ /sbin/lspci 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)00:03.0 CardBus bridge: Texas Instruments PCI1420 00:03.1 CardBus bridge: Texas Instruments PCI1420 00:07.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:08.0 Multimedia audio controller: ESS Technology ES1983S Maestro-3i PCI Audio Accelerator (rev 10) 00:10.0 Ethernet controller: 3Com Corporation 3c556 Hurricane CardBus (rev 10) 00:10.1 Communication controller: 3Com Corporation Mini PCI 56k Winmodem (rev 10) 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M3 AGP 2x (rev 02) 02:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) 02:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) Al dar una mirada rápida a la lista observa una tarjeta de sonido ESS, una tarjeta de red 3Com, un Winmodem, una tarjeta de vídeo ATI y lo que parece ser una combinación de una tarjeta de modem Ethernet/Xircom (PCMCIA). Intrigado por saber cuáles módulos de kernel se utilizan como controladores de dispositivo para estos dispositivos, examina el archivo/etc/modprobe.conf. [elvis@station elvis]$ cat /etc/modprobe.conf alias parport_lowlevel parport_pc alias eth0 3c59x alias snd-card-0 maestro3 install snd-card-0 /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2> &1 : remove snd-card-0 /bin/aumix-minimal -f /etc/.aumixrc -S >/dev/null 2> &1 : alias usb-controller usb-uhci
Hardware and Device Configuration Ejercicios en línea [Warning] Lab Exercise Objetivo: Determinar la configuración del hardware de los dispositivos en su máquina local. Tiempo estimado: 10 minutos. Specification Reúna la siguiente información sobre el hardware de su máquina y almacénela en los archivos especificados. Cada archivo debe contener una sola respuesta. Archivo ~/lab2.2/irq1 ~/lab2.2/fpuports ~/lab2.2/videoram Contenido El nombre del dispositivo que está utilizando la línea 1 de solicitud de interrupción (IRQ -1). El rango de puertos E/S que están siendo utilizados por su dispositivo de máquina fpu. El rango de direcciones físicas que están siendo utilizadas por su Área de vídeo RAM de la máquina. Si usted ha realizado el laboratorio correctamente, podrá generar salida similar a la siguiente, (no se preocupe si sus valores reales difieren). [student@station student]$ head lab2.2/* ==> lab2.2/fpuports <== 00e0-00ef ==> lab2.2/irq1 <== rtc ==> lab2.2/videoram <== 000c0000-000c7fff Resultados A title Question 1 1. Los archivos presentados anteriormente, cada uno contiene una respuesta de una sola palabra. grade
Hardware and Device Configuration La USB y otros dispositivos conectables Conceptos clave El sistema utiliza una inftraestructura común para todos los dispositivos conectables listos para utilizar, la cual consta del comando /sbin/hotplug y scripts hallados en el directorio /etc/hotplug. Las bases de datos de texto determinan qué nuevos dispositivos de conexión listos para usar son compatibles con módulos de kernel almacenados junto con los módulos del kernel en el directorio /lib/modules/kernel-version/. El comando lsusb lista información acerca de todos los dispositivos USB conectados. La compatibilidad de Linux con dispositivos PCMCIA es anterior a la compatibilidad general para dispositivos de conexión listos para uso y en su lugar utiliza el demonio cardmgr, el directorio /etc/pcmcia y la base de datos de texto /etc/pcmcia/config de tarjetas compatibles y módulos asociados del kernel.
Hardware and Device Configuration Discusión Dispositivos de conexión en caliente Expectativas para dispositivos conectables en caliente En la lección anterior abordamos problemas relacionados con la configuración de dispositivos fijos, los cuales están presentes cuando el sistema arranca. En contraste, esta lección discute el soporte de Red Hat Enterprise Linux para dispositivos conectables en caliente. Con la llegada de las tarjetas PCMCIA, las USB, los dispositivos de FireWire. y los buses PCI y SCSI, los usuarios esperan poder agregar todos los dispositivos a su máquina en cualquier momento y hacer que los dispositivos "funcionen" con la mínima intervención administrativa. El manejo apropiado de los dispositivos conectables en caliente presenta varios problemas. Por ejemplo, cuando se añade un dispositivo a una máquina, se deben tener en cuenta las siguientes etapas de reacción. Cargar y configurar los controladores y dispositivos necesarios En el nivel de kernel, el controlador de dispositivo apropiado necesita descargarse y configurarse para el dispositivo. Este paso implica varios de los problemas discutidos anteriormente. Configuración del sistema administrativo El sistema suele responder al nuevo dispositivo a nivel de administración. Por ejemplo, si se agrega una nueva tarjeta de red USB, la interfaz adecuada debería activarse. Si se agrega un dispositivo que está ejecutando un disco duro, el disco debería montarse en el punto de montaje apropiado. Ambas acciones por lo general requieren privilegios de root. Inicio de aplicaciones Alguna aplicación podría iniciarse de parte del usuario. Si se conecta una cámara, se puede iniciar una utilidad de manipulación de imagen. Si se conecta un disco, se podría abrir una ventana de Nautilius, mostrando el directorio raíz del disco. Tanto como sea posible, se trata de ejecutar la configuración de estas etapas por fuera del kernel, utilizando scripts para implementar las políticas. Infraestructura de conexión en caliente del kernel de Linux Con el fin de admininstrar estos problemas, el kernel de Linux proporciona una infraestructura común para dispositivos conectables en caliente con dos componentes diferentes. Un punto de entrada común: /sbin/hotplug El kernel proporciona un punto de entrada común para activar la configuración de dispositivos conectables en caliente. Cada vez que un evento de conexión en caliente se presenta, (i.e., cada vez que un dispositivo es conectado o desconectado del sistema), el kernel llama al comando /sbin/hotplug con los argumentos adecuados. Bases de datos del controlador de dispositivos modulares
En segundo lugar, para asociar los controladores de dispositivo modular con los dispositivos adecuados, las bases de datos de texto ASCII coincidentes con el proveedor y los ID de dispositivo con módulos de kernel se generan directamente desde los módulos de kernel. Las bases de datos se hallan en el mismo directorio que contiene los módulos de kernel (/lib/modules/versiónkernel) y llamados modulesbusmap, donde BUS se remplaza por el bus adecuado como se ilustra en el siguiente ejemplo. [root@station usb]# ls /lib/modules/2.6.9-5.el/ build modules.generic_string modules.parportmap modules.usbmap kernel modules.ieee1394map modules.pcimap modules.dep modules.isapnpmap modules.pnpbiosmap El directorio /etc/hotplug Fuera del kernel, los scripts que soportan los dispositivos conectables en caliente se hallan en el directorio /etc/hotplug. Los puntos de entrada suelen llamarse /etc/hotplug/type.agent. donde TYPE se remplaza por el tipo apropiado de dispositivo. [root@station root]# ls /etc/hotplug/ blacklist net.agent pci.rc usb.distmap usb.usermap hotplug.functions pci usb usb.handmap ieee1394.agent pci.agent usb.agent usb.rc Para los dispositivos USB, la configuración personalizada para dispositivos particulares se puede especificar mediante el archivo usb.usermap. El archivo tiene la misma sintaxis de las bases de datos del módulo del kernel, pero en lugar de especificar un módulo del kernel, se puede especificar un script en el directorio /etc/hotplug/usb. Cuando un dispositivo especificado se conecte, el script apropiado puede responder. Otras fuentes de información Encontrará más información acerca de la configuración de los dispositivos conectables en caliente en el directorio /usr/share/doc/hotplug-*/ o en http://linux-hotplug.sourceforge.net/. El comando lsusb El comando lsusb presenta una lista de todos los dispositivos USB conectados y la información de configuración de USB de bajo nivel. En el siguiente ejemplo, el comando lsusb está identificando un disco USB conectado. [root@station root]# lsusb -v Bus 001 Device 002: ID 0d7d:1300 Apacer Device Descriptor: blength 18 bdescriptortype 1 bcdusb 1.10 bdeviceclass 0 Interface idvendor 0x0d7d Apacer idproduct 0x1300 bcddevice 0.50 imanufacturer 1 iproduct 2 USB DISK 2.0 iserial 3 07371C5003E3 bnumconfigurations 1
Dispositivos PCMCIA Los primeros dispositivos utilizados fueron las tarjetas PCMCIA que se encuentran en muchos laptops. Puesto que la infraestructura para el manejo de dispositivos PCMCIA se desarrolló antes de que se reconciera la necesidad de un mecanismo de conexión en caliente, la infraestructura PCMCIA no utiliza los mecanismos que tratamos anteriormente. Apesar de que la infraestructura común no se utiliza, los conceptos generales son similares. El demonio cardmgr Los eventos PCMCIA son manejados por el demonio cardmgr (un proceso que se ejecuta en el segundo plano). Cuando una tarjeta PCMCIA se inserta o se quita del sistema, el demonio cardmgr responde de acuerdo con la configuración hallada en el directorio /etc/pcmcia. El directorio /etc/pcmcia El directorio /etc/pcmcia/ contiene scripts que definen la forma como el sistema debería responder cuando se inserte o quite una tarjeta PCMCIA de la clase apropiada. Por ejemplo, cuando se inserta una tarjeta Ethernet, el script /etc/pcmcia/network crea su propia interfaz de red. El archivo /etc/pcmcia/config contiene una base de datos de tarjetas PCMCIA reconocidas y los módulos del kernel. apropiados para asociarse con ellos. La utilidad cardctl La utilidad de la línea de comando cardctl se puede utilizar para manejar tarjetas PCMCIA directamente. En el ejemplo anterior, el comando cardctl se utiliza para identificar las tarjetas PCMCIA que están insertadas actualmente. [root@station pcmcia]# cardctl ident Socket 0: product info: "Xircom", "CardBus Ethernet 10/100 + Modem 56", "CBEM56G", "1.3" manfid: 0x0105, 0x0103 function: 6 (network) Socket 1: no product info available Mayor información sobre el manejo de los dispositivos PCMCIA puede hallarse en la página de manual pcmcia(5).