Hardware y Dispositivos de Configuracion

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
sd_mod
13516
usb-storage
74656
scsi_mod
107544
parport_pc
19076
lp
8996
...
Used by
Not tainted
2 (autoclean)
1
2 [sd_mod usb-storage]
1 (autoclean)
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 ([email protected]) (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
apm-scripts harddisks
named
authconfig
hwconf
network
clock
i18n
networking
console
init
network-scripts
desktop
installinfo ntpd
dhcpd
iptables
pcmcia
dhcrelay
irda
pgsql
firstboot
keyboard
rawdevices
gpm
kudzu
system-config-securitylevel
system-config-users
redhat-logviewer
rhn
samba
sendmail
squid
static-routes
syslog
tux
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
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.
Memoria
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
capacity driver
identify model smart_thresholds
[root@station ide]# head /proc/ide/hda/*
==> /proc/ide/hda/cache <==
384
smart_values
==> /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
-------acoustic
0
address
0
bios_cyl
730
bios_head
255
bios_sect
63
breada_readahead
8
bswap
0
current_speed
66
...
min
--0
0
0
0
0
0
0
0
254
2
65535
255
63
255
1
70
max
--rw
rw
rw
rw
rw
rw
r
rw
mode
----
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
Contenido
~/lab2.1/cpuspeed
La velocidad de su procesador actual en megahertz.
~/lab2.1/cpucache
El tamaño de su caché de CPU en kilobytes.
~/lab2.1/memsize
La cantidad de memoria física en megabytes.
El nombre del módulo del kernel que sirve de controlador de dispositivo
~/lab2.1/nicdriver para su interfaz de red eth0, (si no tiene una interfaz eth0, ponga la
palabra en inglés "none").
~/lab2.1/numide
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
Alias
Role
ethN
El controlador de dispositivo apropiado para la tarjeta de interfaz de red asociada con la
interfaz de red ethN.
snd-card-N
El controlador del dispositivo apropiado para la tarjeta de sonido asociada con el espacio en
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
El controlador de dispositivo asociado con el número mayor de dispositivo de nodos de
caracterN.
block-major-N
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
Contenido
~/lab2.2/irq1
El nombre del dispositivo que está utilizando la línea 1 de solicitud de
interrupción (IRQ -1).
~/lab2.2/fpuports
El rango de puertos E/S que están siendo utilizados por su dispositivo de
máquina “fpu”.
~/lab2.2/videoram
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
kernel
modules.ieee1394map
modules.pcimap
modules.dep modules.isapnpmap
modules.pnpbiosmap
modules.usbmap
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
hotplug.functions pci
usb
ieee1394.agent
pci.agent usb.agent
usb.distmap
usb.handmap
usb.rc
usb.usermap
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).
Hardware and Device Configuration
Ejercicios en línea
[Warning]
Lab Exercise
Objetivo: Familiarizarse con módulos comunes del controlador de
dispositivos USB
Tiempo estimado: 20 minutos.
Specification
El archivo /lib/modules/kernel-version/modules.usbmap (donde kernel-version se
remplaza por la versión actual de kernel) contiene una base de datos ASCII de módulos de kernel
USB y el proveedor dispositivo ID de los dispositivos a los cuales se relacionan. Los primeros 20
caracteres de cada línea contienen el nombre del módulo de kernel, (si no está seguro de la versión
que está utilizando el kernel, el comando uname -r lo imprimirá en pantalla por usted).
Utilice la combinación cut, sort, uniq, grep y los comandos head para generar un cuadro de los
módulos de kernel USB, precedidos por el número de veces que se nombran. Guarde el cuadro en el
archivo ~/lab2.3/usbmodules.
Si ha completado el laboratorio correctamente, podrá generar una salida similar a la siguiente. No
se preocupe si el conteo de frecuencia o el nombre de los módulos difieren.
[student@station student]$ cat lab2.3/usbmodules
170 scanner
110 usb-storage
61 pegasus
35 ipaq
33 kaweth
30 io_edgeport
24 keyspan
20 wacom
20 pwc
19 visor
Resultados
A title
Question 1
1. El archivo ~/lab2.3/usbmodules que contiene un cuadro de los 10 módulos de Kernel
USB más comunes, precedido por el número de veces que se nombran.
grade
Hardware and Device Configuration
Nodos de dispositivos del sistema de archivos
Conceptos clave
„
„
„
„
Controladores de dispositivo de acceso de procesos a través del tipo especial de archivo
conocido como nodos de dispositivo.
Linux respalda básicamente dos tipos diferentes de dispositivos, los dispositivos blocky los
dispositivos character. Por consiguiente, los nodos del sistema de archivos pueden ser
bloques o nodos de caracter.
Cada nodo del dispositivo del sistema de archivos tiene un número mayor (que desglosa un
controlador de dispositivo particular en el kernel) y un número menor.
Los nodos del dispositivo del sistema de archivos se pueden crear con el comando mknod.
Hardware and Device Configuration
Discusión
" Todo es un archivo"
En las lecciones anteriores hablamos de los controladores de dispositivo como componentes
especializados del kernel, los cuales permiten al kernel comunicarse con varios dispositivos. Esta
lección trata el siguiente nivel: ¿de qué forma se comunican los procesos con los controladores de
dispositivo? Al administrar el flujo de información para y desde procesos, Linux (y Unix) tiene una
filosofía de diseño simple: todo es un archivo. Siguiendo esta filosofía, la pregunta anterior ya se
contestó: los procesos se comunican con controladores de dispositivo como si fueran archivos.
Por ejemplo, el controlador del dispositivo de la terminal para la consola virtual número 4 es
llamado por el nodo del dispositivo /dev/tty4. ¿Qué sucede cuando se escribe información en
este archivo?
[root@station root]# echo "hello world" > /dev/tty4
La información pasa al controlador del dispositivo de la terminal, el cual hace lo que un
controlador de dispositivo de terminal debería hacer cuando se escribe información en él: la
presenta en la terminal. Al cambiar a la consola virtual número 4, hallamos lo siguiente:
Red Hat Enterprise Linux ES release 4 (Nahant)
Kernel 2.6.9-5.EL on an i686
station login: hello world
El controlador del dispositivo de la terminal mostró la información que estaba escrita
en /dev/tty4 en la ubicación actual del cursor.
Nodos de dispositivos del sistema de archivos
Los archivos que hacen referencia a controladores de dispositivos se conocen como nodos de
dispositivo. El archivo de sistema de Linux soporta varios tipos de archivos. La mayoría de los
usuarios están familiarizados con tres: los archivos normales, los directorios y los enlaces
simbólicos (blandos). Los administradores del sistema suelen conocer dos más: nodos de bloque y
de dispositivos de caracteres. Por convención, los nodos de dispositivo se encuentran en el
directorio /dev. Cuando el kernel detecta un nuevo dispositivo, se agrega un nodo de dispositivo
para éste allí. Observe que esto contrasta con la conducta de versiones anteriores de Linux, donde
el nodo de dispositivo existía para cada dispositivo posible, ya sea que estuviera en uso o no.
[root@station
total 0
crw-rw---- 1
crw------- 1
crw------- 1
crw------- 1
lrwxrwxrwx 1
crw------- 1
...
brw-rw---- 1
brw-rw---- 1
brw-rw---- 1
brw-rw---- 1
brw-rw---- 1
root]# ls -l /dev
root
root
root
root
root
root
root
root
root
root
root
root
14, 12 Aug
10, 175 Aug
36,
8 Aug
14,
4 Aug
3 Aug
5,
1 Aug
5
5
5
5
5
5
16:30
16:30
16:30
16:30
16:30
16:30
adsp
agpgart
arpd
audio
cdrom -> hdc
console
root
root
root
root
root
disk
disk
disk
disk
disk
3,
3,
3,
3,
22,
5
5
5
5
5
16:30
16:30
16:30
16:30
16:30
hda
hda1
hda2
hda3
hdc
0
1
2
3
0
Aug
Aug
Aug
Aug
Aug
Cuando se listan con el comando ls -l, los nodos de dispositivos de bloque y caracter se reconocen
por el primer caracter en cada línea. Mientras los archivos regulares son identificados por un “-”, y
los directorios por una “d” los dispositivos de nodo de caracter se identifican por una “c” y los
dispositivos de nodos de bloque se identifican por una “b”.
¿Por qué dos tipos de nodos?
El sistema de archivos permite dos tipos de nodos de dispositivo porque el kernel de Linux
distingue entre dos tipos diferentes de dispositivos.
Dispositivos de caracteres
Los dispositivos de caracteres son dispositivos que pueden manipular datos como un flujo
único de bytes secuenciales (o "caracteres"). Los dispositivos de caracteres ofrecen una
forma natural para generar o recibir información. Ejemplos de dispositivos de caracteres
incluyen terminales, puertos seriales e impresoras.
Dispositivos de bloque
Los dispositivos de bloque son dispositivos que permiten acceso aleatorio y transferir
información en pedazos fijos o "bloques". Por lo general, los discos se consideran
dispositivos de bloque. Más importante, para la mejora del rendimiento de E/S, todas las
transferencias desde o hacia los dispositivos de bloque hacen uso de caché dentro del
kernel, algunas veces conocidas como "página caché". "buffer caché" o simplemente "caché".
La anatomía de un nodo de dispositivos
A continuación, el comando ls se utiliza para producir un listado largo de un archivo normal y el
nodo de dispositivo /dev/fd0.
[root@station
-rw-r--r-[root@station
brw-rw----
root]# ls -l /etc/passwd
1 root
root
4004 Sep 17 12:34 /etc/passwd
root]# ls -l /dev/fd0
1 root
floppy
2,
0 Jan 30 2003 /dev/fd0
Los archivos normales se utilizan para almacenar información en un disco duro. Por
consiguiente el comando ls -l reporta la cantidad de información almacenada en el archivo
(i.e, la longitud del archivo).
En contraste, los nodos de dispositivo, no se utilizan para almacenar información. En su
lugar, sirven como conducto, transfieren información hacia y desde un controlador de
dispositivo subyacente. Por lo tanto, el concepto de tamaño de archivo no tiene sentido. En
su lugar, el comando ls -l reporta dos números asociados con cada nodo de dispositivo, el
número mayor y el número menor.
Cada controlador de dispositivo en el kernel registra un número mayor, el cual es un número
entero que sirve para identificar ese dispositivo. El número mayor de un nodo dispositivo de
sistema de archivos se correlaciona con el número mayor del controlador de dispositivo al cual está
asociado. Una lista de controladores de dispositivo registrada con el kernel y sus números mayores,
se encuentra en el archivo del sistema de archivos proc /proc/devices. A continuación, observe
que los dispositivos de caracter y bloque se manejan por separado. El controlador del dispositivo de
caracteres con un número mayor que 2 es “pty”, mientras que el controlador de dispositivos de
bloque con un número mayor que “fd”.
[root@station root]# cat /proc/devices
Character devices:
1 mem
2 pty
3 ttyp
4 ttyS
5 cua
6 lp
...
143 pts
162 raw
180 usb
254 pcmcia
Block devices:
1 ramdisk
2 fd
3 ide0
7 loop
9 md
...
58 lvm
El número menor asociado con un nodo de dispositivos se trata como parámetro, el cual se pasa al
controlador de dispositivos cuando los datos se escriben desde o hacia el nodo. Los diferentes
controladores de dispositivos implementan números menores de forma diferente. Por ejemplo, el
controlador de disquetes, (bloque mayor número 2) utiliza el número menor para distinguir entre
formatos de disquetes, mientras que el controlador primario IDE (bloque mayor número 3) utiliza
el número menor para distinguir diferentes particiones en el disco duro (esto se verá más en detalle
en otro cuaderno).
[root@station
brw-rw---brw-rw---brw-rw---brw-rw---...
brw-rw---brw-rw---brw-rw---brw-rw---...
brw-rw---...
brw-rw---...
brw-rw---brw-rw---brw-rw---...
root]# ls -l /dev/fd*
1 root
floppy
1 root
floppy
1 root
floppy
1 root
floppy
/dev/hda*
2,
0 Jan
2,
4 Jan
2,
4 Jan
2, 12 Jan
30
30
30
30
2003
2003
2003
2003
/dev/fd0
/dev/fd0CompaQ
/dev/fd0d360
/dev/fd0D360
1
1
1
1
30
30
30
30
2003
2003
2003
2003
/dev/hda
/dev/hda1
/dev/hda10
/dev/hda11
root
root
root
root
disk
disk
disk
disk
3,
3,
3,
3,
0
1
10
11
Jan
Jan
Jan
Jan
1 root
disk
3,
2 Jan 30
2003 /dev/hda2
1 root
disk
3,
3 Jan 30
2003 /dev/hda3
1 root
1 root
1 root
disk
disk
disk
3,
3,
3,
4 Jan 30
5 Jan 30
6 Jan 30
2003 /dev/hda4
2003 /dev/hda5
2003 /dev/hda6
Resumiendo, los nodos de dispositivos tienen tres parámetros que sirven para asociar el nodo de
dispositivo a un controlador de dispositivo. Un archivo de tipo bloque o caracter, un número
mayor, y un número menor. Observe que el nombre de archivo del nodo del dispositivo no se
incluye en esta lista y no se utiliza para determinar el controlador de dispositivo apropiado.
Este esquema presenta problemas asociados con esto. Comúnmente, un nodo de dispositivo podría
existir, para lo cual no hay un controlador de dispositivo correspondiente en el kernel:
[root@station root]# echo "hello world" > /dev/sde
-bash: /dev/sde: No such device or address
Con menos frecuencia, podría haber un controlador de dispositivo en el kernel sin ningún nodo de
dispositivo que le haga referencia, por lo tanto, ninguna forma tradicional para procesos que
interactúen con él.
Manejo de nodos de dispositivos: mknod
Por lo general los administradores no necesitan manejar nodos de dispositivos directamente. La
mayoría de las distribuciones de Linux ocupan el directorio /dev con nodos de dispositivo para
cualquier dispositivo concebible, (Red Hat Enterprise Linux tiene más de 7.500 archivos en el
directorio /dev). No obstante, a veces, especialmente en entornos mínimos (tales como una shell
de rescate), los administradores pueden necesitar el comando mknod para crear nodos de
dispositivo.
El comando mknod espera ser llamado con cuatro argumentos. El primer argumento puede ser ya
sea una “c” (para especificar un nodo de dispositivo de caracter) o una “b” (para especificar un
nodo de dispositivo de bloque). Los dos argumentos siguientes son el número mayor y el número
menor, respectivamente.
Por ejemplo, nuestra demostración inicial (escribir a una cuarta consola) se puede repetir mediante
un nodo de dispositivo personalizado creado en el directorio de inicio de raíz. Primero, root busca
los nodos de dispositivos originales y el número menor.
[root@station root]# ls -l /dev/tty4
crw------1 root
root
4,
4 Sep 27 06:52 /dev/tty4
Luego, utiliza mknod para crear un nuevo nodo de dispositivo en su directorio de inicio, lo
observa con el comando ls -l y luego lo escribe en el nodo.
[root@station
[root@station
crw-r--r-[root@station
root]# mknod mytty4 c 4 4
root]# ls -l mytty4
1 root
root
4,
4 Sep 27 07:34 mytty4
root]# echo "hello my device node" > mytty4
¿Dónde está la información que escribió? En la cuarta consola virtual naturalmente:
Red Hat Enterprise Linux ES release 4 (Nahant)
Kernel 2.6.9-5.EL on an i686
station login: hello world
hello my device node
De nuevo, el nombre del nodo del dispositivo es irrelevante. Únicamente interesan el tipo y los
números mayores y menores. Además, no hay nada de especial acerca del directorio /dev aparte
de la convención.
¿Cómo se suprimen los nodos de dispositivos? De la misma forma que se suprimen del sistema de
archivos.
[root@station root]# rm mytty4
rm: remove character special file `mytty4'? y
Nodos de dispositivo más utilizados
Aunque el concepto de nodos de dispositivo se comparte con otras versiones de Unix, los nombres
tradicionalmente asociados con los nodos de dispositivo tienden a variar de un versión de Unix a
otra. A continuación se presenta una lista de nombres de Linux de los nodos de dispositivo más
utilizados, los cuales deben formar parte del conocimiento de trabajo de cada administrador de
Linux.
Table 1. Nodos de dispositivos de bloque comunes de Linux
Nombre de nodo
Dispositivo asociado
hda
Dispositivo IDE de maestro primario
hdb
Dispositivo IDE de esclavo primario
hdc
Dispositivo IDE de maestro secundario
hdd
Dispositivo IDE de esclavo secundario
sda
"Primer" dispositivo SCSI
sdb
"Segundo" dispositivo SCSI
fd0
Primer disquete
fd1
Segundo disquete
Table 2. Nodos de dispositivos de caracteres de Linux
Nombre de
nodo
Dispositivo asociado
ttyn
Número de consola virtual n
ttySn
Puerto serial n
lpn
Puerto paralelo n
null
Toda la información escrita a este dispositivo virtual se descarta.
cero
Cuando es leído, este dispositivo es una fuente infinita de ceros binarios.
urandom
Cuando es leído, este dispositivo es una fuente infinita de datos binarios
aleatorios.
Enlaces simbólicos como nombres funcionales
A menudo, las aplicaciones se interesan más en la función del dispositivo que en el nodo del
dispositivo real. Por ejemplo, la mayoría de los controladores CD-ROM implementan ya sea una
interfaz IDE o una SCSI y por lo tanto, se pueden solucionar mediante los nodos de dispositivo hdc
o sda. Sin embargo, a una aplicación de reproducción de audio de música, no le importaría si el
dispositivo fuera un dispositivo IDE o SCSI, sólo desearía utilizar el "CD-ROM".
Red Hat Enterprise Linux suele utilizar enlaces simbólicos en el directorio /dev para ayudar a
facilitar la configuración de estas aplicaciones. El siguiente cuadro lista los enlaces creados más
comunes y los tipos de dispositivos a los cuales apuntan.
Table 1. Los enlaces simbólicos más hallados en el directorio /dev
Nombre del enlace Muestra de nodos de dispositivo
/dev/cdrom
/dev/hdc, /dev/sdb
/dev/modem
/dev/ttyS0, /dev/ttyS1
/dev/pilot
/dev/ttyS0, /dev/usb/ttyS1
Creación de un nodo de dispositivo dinámico: udev
La técnica tradicional de Unix para dispositivos de acceso (nodos de dispositivo) ha resistido la
prueba del tiempo, pero no sin tener tropiezos. Por ejemplo, puede haber un conductor de
dispositivo en el kernel al cual no se puede acceder porque no hay un nodo de dispositivo
complementario en el sistema de archivos. En cambio, puede haber nodos de dispositivo en el
sistema de archivos sin el controlador de dispositivo correspondiente en el kernel, lo que lleva a la
confusión.
Estos problemas se exacerban con el incremento de popularidad de los dispositivos
intercambiables en caliente, los que la gente sólo espera conectar a la máquina y que "funcionen".
En un principio y hasta Red Hat Enterprise Linux 3, Red Hat resolvió el problema "Pre-poblando"
el directorio /dev con cada nodo de dispositivo posible, incluso si los correspondientes
controladores de dispositivos no estaban presentes. Como resultado, el directorio /dev tenía
literalmente miles de entradas.
Desde Red Hat Enterprise Linux 4 (y el kernel de Linux 2.6), Red Hat (y la comunidad de Linux)
está tratando de utilizar un método más inteligente para resolver el problema. El kernel ahora
implementa un dispositivo de notificación (conocido como "netlink", debido a que también está
asociado con la red), el cual se monitoriza con el nuevo demonio udevd.
La clave es que cuando el nuevo dispositivo se conecta a la máquina, el kernel notifica a udevd, el
cual consulta una base de datos de reglas en /etc/udev. Las reglas le dicen al demonio udevd
qué tipo de nodo de dispositivo debe crear para el dispositivo y qué propiedades y permisos debe
tener para aplicar al nodo.
De la misma manera, cuando se remueve el dispositivo, el demonio udevd responde de nuevo a
una notificación del kernel, esta vez quitando el nodo de dispositivo.
Curiosamente, el demonio udevd considera todos los dispositivos como dispositivos cambiable en
caliente. Los dispositivos permanentes "simplemente estaban allí" cuando el sistema estaba
cargando.
Hay un par de consecuencias para la nueva técnica.
1. La ventaja es que el directorio /dev tiene muchos menos nodos de dispositivo y los nodos
existentes son un reflección directa del hardware subyacente detectado.
2. La desventaja es que ya no podrá simplemente utilizar mknod para crear sus propios
nodos de dispositivos dentro del directorio /dev. Más precisamente, usted puede crear el
nodo pero debido a que el directorio /dev ahora está dinámicamente poblado por udevd,
no puede esperar a que el nodo sobreviva un reinicio.
Los detalles para configurar el demonio udevd van más allá del objetivo de este curso, pero el
interesado puede utilizar rpm -ql udev para obtener una lista de páginas del manual (tal como
udev(8)) y una documentación más completa en el directorio /usr/share/doc/udevversion.
Hardware and Device Configuration
Ejemplos
Crear una copia de seguridad del registro de arranque maestro del dispositivo
con el comando dd
En general, los nodos de dispositivos permiten acceso directo a dispositivos. Los nodos de
dispositivos asociados con discos les permiten a los usuarios leer el contenido del disco, byte por
byte, como si el disco fuera un archivo gigante. El comando dd se puede utilizar para extraer
longitudes específicas de datos desde sitios específicos de un archivo.
El primer bloque (512 bytes) de un disco duro de carga se refiere a un "registro de arranque
maestro" e incluye información sensible, como por ejemplo, el gestor de arranque y el cuadro de
partición del dispositivo. Como precaución, un administrador de sistema desea hacer una copia de
seguridad de esta información. Utiliza el comando dd para hacer una copia de los primeros 512
bytes del disco. Especifica que su archivo de entrada debe ser /dev/hda, su archivo de salida debe
ser /tmp/MBR.backup y que exactamente se debe transferir un bloque mediante un tamaño de
bloque de 512 bytes. Como resultado, termina con un archivo de 512 bytes exactos de longitud.
[root@station root]# dd if=/dev/hda of=/tmp/MBR.backup bs=512 count=1
1+0 records in
1+0 records out
[root@station root]# ls -l /tmp/MBR.backup
-rw-r--r-1 root
root
512 Sep 28 07:58 /tmp/MBR.backup
Si el registro de arranque maestro se daña alguna vez, se puede restaurar invirtiendo el comando
anterior.
[root@station root]# dd if=/tmp/MBR.backup of=/dev/hda
(Sin argumentos que determinen otra cosa, el comando dd transfiere todo el archivo de entrada).
Hardware and Device Configuration
Ejercicios en línea
[Warning]
Lab Exercise
Objetivo: Familiarizarse con los nodos de dispositivos del sistema de
archivos Linux.
Tiempo estimado: 10 minutos.
Specification
1. Cree el archivo ~/lab2.4/block-3-0, el cual contenga el nombre del nodo de dispositivo
de bloque asociado con el número mayor 3 y el número menor 0. Haga referencia al archivo
mediante una referencia absoluta.
2. Cree el archivo ~/lab2.4/char-1-8, que contenga el nombre del nodo de dispositivo de
caracter asociado con el número mayor 1 y el número menor 8. Haga referencia al archivo
mediante una referencia absoluta.
3. Cree el archivo ~/lab2.4/cdrom, que contenga el nombre del nodo del dispositivo al cual
apunte el enlace simbólico /dev/cdrom. Haga referencia al archivo mediante una
referencia absoluta (i.e. sin /dev/). Si su máquina no tiene un dispositivo de CD ROM (o el
archivo /dev/cdrom no existe) simplemente escriba la palabra "none".
4. Utilice el comando mknod para crear el nodo de dispositivo ~/lab2.4/myfd0. El nodo de
dispositivo debe tener las mismas propiedades que el nodo de dispositivo /dev/fd0, (usted
tendrá que utilizar una cuenta de root para realizar este paso).
Si ha realizado el laboratorio correctamente, debería poder generar una salida similar a la siguiente:
[student@station student]$ ls -l lab2.4/
total 12
-rw-rw-r-1 student student
10
-rw-rw-r-1 student student
9
-rw-rw-r-1 student student
10
brw-r--r-1 root
root
2,
0
[student@station student]$ head lab2.4/*
==> lab2.4/block-22-7 <==
/dev/hdd3
Sep
Sep
Sep
Sep
28
28
28
28
07:11
07:12
07:11
07:12
block-22-7
cdrom
char-1-8
myfd0
==> lab2.4/cdrom <==
/dev/sdc
==> lab2.4/char-1-8 <==
/dev/tty8
Resultados
A title
Question 1
1. El archivo ~/lab2.4/myfd0 que contiene el nombre de un dispositivo de bloque asociado
con el número mayor 3 y el número menor 0 como una referencia absoluta.
2. El archivo ~/lab2.4/char-1-8, que contiene el nombre del nodo de dispositivo de
caracter asociado con el número mayor 1 y el número menor 8 como referencia absoluta.
3. El archivo ~/lab2.4/cdrom, el cual contiene el nombre del nodo de dispositivo, al cual el
enlace simbólico del archivo /dev/cdrom apunta o la palabra "none".
4. El nodo de dispositivo ~/lab2.4/myfd0 el cual tiene las mismas propiedades del nodo de
dispositivo /dev/fd0.
grade
Limpieza
El nodo de dispositivo ~/lab2.4/myfd0 puede causar problemas extraños (si se incluyen como
un argumento para el comando grep, por ejemplo) y debería removerse después de que su
laboratorio sea calificado.
Hardware and Device Configuration
Monitorizar el funcionamiento
Conceptos clave
„
„
„
Linux utiliza una medida general de la actividad del sistema conocida como el "promedio de
carga".
Linux utiliza una memoria para dos propósitos fundamentales: compatibilidad con el
proceso y almacenamiento en caché de operaciones de dispositivo en bloque E/S.
El comando top se puede utilizar para monitorizar la actividad de procesamiento y la
actividad de memoria.
Hardware and Device Configuration
Discusión
Monitorizar el funcionamiento
Terminamos este cuaderno mencionando algunas de las herramientas y medidas más utilizadas
para monitorizar funcionamiento en sistemas de Linux
Funcionamiento de CPU
El comando uptime
Como el nombre lo indica, el comando uptime retorna cuánto tiempo las máquinas han estado
funcionando sin volver a arrancar o sin apagar.
[root@station root]# uptime
08:14:10 up 1:28, 4 users,
load average: 0.56, 0.23, 0.12
Aunque esta máquina ha estado despierta más de una hora y 28 minutos, Linux tiene tal
reputación de estabilidad que los servidores de red suelen utilizar uptimes medidos en meses en
lugar de horas.
Más relevante para el rendimiento de la CPU, el comando uptime también retorna una estadística
Linux (y Unix) conocida como el promedio de carga de la máquina (a menudo abreviada loadavg).
El promedio de carga es un promedio de tiempo del número de procesos que están en el estado de
"ejecutable" o "dormido voluntario". Por convención, tres tiempos de promedio se mantienen. Un
promedio de 1, un promedio de 5 minutos y un promedio de 15).
El comando top
La utilidad top lista en forma repetitiva procesos en la máquina, clasificados por orden de
actividad de la CPU. La lista se actualiza cada 5 minutos. Mientras se ejecuta top, el teclado está
"vivo", lo que implica que las pulsaciones de tecla se interpretan como comandos, sin tener que
pulsar la tecla ENTER. Principalmente, la tecla “q” abandona top, mientras que la tecla “h”
muestra una ayuda en la pantalla documentando otros comandos de pulsación de teclas.
Las tres líneas superiores del monitor top monitorizan la actividad de la CPU. La línea superior
retorna la misma información del comando uptime, principalmente incluyendo el promedio de
carga.
[root@station root]# top
top - 09:33:48 up 12:07, 5 users, load average: 0.23, 0.40, 0.30
Tasks: 91 total,
2 running, 88 sleeping,
0 stopped,
1 zombie
Cpu(s): 8.6% us, 3.7% sy, 0.3% ni, 86.7% id, 0.7% wa, 0.0% hi, 0.0% si
...
La segunda línea enumera los procesos que se están ejecutando en la máquina y el estado en que se
encuentran. Muchos procesos en el estado "ejecutable" (más formalmente llamados "en ejecución")
implicarían una máquina ocupada.
La tercera y cuarta líneas clasifican cómo la CPU se ha estado utilizando esta vez, mediante las
siguentes tres clasificaciones estándar de Unix.
usuario - "us"
Cuando la CPU está en el modo de "usuario" está funcionando en nombre de un proceso de
usuario. Los procesos que realizan cálculos intensivos computacionales tales como un
programa de manipulación de imagen o una biblioteca criptográfica, harían que la CPU
dedicara una gran cantidad de tiempo en el modo de usuario.
sistema - "si"
Cuando la CPU está en el modo de "sistema", está realizando actividades en nombre del
kernel. Por ejemplo, las interrupciones de hardware o llamadas al sistema en nombre del
proceso (tales como las operaciones de lectura y escritura). Los procesos que transfieren
grandes cantidades de datos desde y hacia el disco o desde y hacia las conexiones de red,
harían que la CPU consumiera una gran cantidad de tiempo en el modo de "sistema".
inactivo - "id"
Como el nombre lo indica, es el tiempo que tarda la CPU para calmar sus heridas porque no
hay procesos en el estado ejecutable.
Además, Red Hat Enterprise Linux rastrea las siguientes estadísticas:
nice - "ni"
Esta es la cantidad de tiempo que la CPU tarda en actuar en nombre de los procesos
ejecutados con "nice", para tener una prioridad de ejecución más baja. El tiempo que tarda
en este estado se cuenta como tiempo gastado en el estado de "usuario" o de "sistema".
espera E/S - "wa"
Es el tiempo de montaje que tarda la CPU inactiva debido a que dos componentes compiten
por el mismo recurso de E/S o un proceso está esperando a que finalice una operación E/S.
Interrupción de hardware - "hi"
Es la cantidad de tiempo que se tarda la CPU revisando las solicitudes de hardware de bajo
nivel o "las interrupciones". Como su nombre lo indica, el hardware puede interrumpir el
flujo normal de la ejecución de la CPU cuando la información pertinente está disponible, tal
como un ratón que se ha movido a otro sitio o una tarjeta Ethernet que ha recibido un
paquete a través de la red.
Interrupción de software - "si"
Es la cantidad de tiempo que tarda la CPU revisando tareas periódicas dentro del kernel,
tales como la administración del transporte de paquetes de red a la aplicación apropiada.
Utilización de memoria
Quizás la tarea más importante del kernel de Linux es la utilización eficiente de recursos en toda
ejecución del sistema, dificultando la respuesta a preguntas fáciles tales como "¿cuánta memoria
está utilizando el proceso?". No obstante, en general, los administradores pueden pensar que el
kernel de Linux está tratando de balancear las solicitudes de memoria de dos tareas importantes.
Memoria del proceso
Los distintos procesos ejecutándose en la máquina solicitan cada uno memoria del kernel. Para
procesos más pequeños, las solicitudes de memoria pueden ser tan modestas como 100 kilobytes o
menos por proceso. Aplicaciónes más grandes (en particular gráficas tales como el navegador de
red Firefox) pueden solicitar decenas de megabytes de memoria.
Disco E/S caché
El kernel de Linux trata de optimizar disco de E/S haciendo buffer en todas la operaciones de disco
(o más exactamente, el dispositivo de bloque). El proceso de leer o escribir información a un disco
o a la memoria es bastante más bajo. Cuando un proceso solicita leer información desde un disco,
la información es obviamente leída tan pronto como sea posible dentro de la memoria. No
obstante, cuando un proceso solicita escribir información a un disco, el kernel rápidamente
almacena la información en la memoria caché y retorna control al proceso. Cuando hay un
"momento quieto" (es decir, cuando haya unas cuantas operaciones pendientes para poder
funcionar) el kernel realizará una operación relativamente lenta para confirmar la información
depositada al disco.
¿Qué sucede si otro proceso (o el mismo) trata de leer la misma información desde el disco antes de
salir de la memoria caché? El kernel retorna la información desde el caché, circunvalando todo el
disco. Los archivos más utilizados, que suelen leerse o escribirse podrían consumir la mayoría de su
tiempo en la E/S caché, sólo en ocasiones cuando se ha sincronizado de nuevo con el disco. En
sistemas con grandes cantidades de memoria, el caché E/S de disco puede fácilmente utilizar más
de la mitad de éste. La administración correcta del caché E/S de disco mejora dramáticamente todo
el funcionamiento del sistema.
Monitorizar el uso de memoria con /proc/meminfo
Veamos de nuevo el contenido en /proc/meminfo, está vez centrándonos en la cantidad de
memoria asignada al caché de disco E/S.
[root@station ~]# cat /proc/meminfo
MemTotal:
255232 kB
MemFree:
4340 kB
MemShared:
0 kB
Buffers:
12096 kB
Cached:
138840 kB
...
Recuerde que la línea MemTotal lista memoria detectada y la línea MemFree lista cuánta
memoria se desaprovecha. Ahora nos centramos en las líneas Buffers y Cached. El archivo
meminfo distingue entre dos variedades sutiles de caché E/S. (la última es para
almacenamiento caché E/S relacionada con el contenido de archivos normales, el primero es
para las interacciones de dispositivo de bloque). Para nuestros propósitos, la suma
combinada de ambos se puede considerar la "caché E/S".
En esta máquina que contiene cerca de 256 megabytes de memoria física, cerca de 150 megabytes
(o más de la mitad) se asignan a la caché E/S.
Monitorizar la utilización de memoria con top
El comando top presentado anteriormente también monitoriza el consumo de memoria. Arriba
nos centramos en las primeras tres líneas de la visualización top relacionada con la actividad de la
CPU. Ahora nos enfocamos en aspectos de las siguientes tres líneas.
[root@station root]# top
top - 09:51:08 up 12:25, 6 users, load average: 0.00, 0.12, 0.28
Tasks: 91 total,
2 running, 88 sleeping,
0 stopped,
1 zombie
Cpu(s): 0.3% us, 0.0% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si
Mem:
514604k total,
505516k used,
9088k free,
219620k buffers
Swap: 1044216k total,
132k used, 1044084k free,
110568k cached
...
El campo lista la memoria física disponible.
El campo lista la cantidad de memoria disponible en uso.
Este campo lista la cantidad de memoria disponible actualmente.
Estos campos, combinados, dan una medida de la cantidad de memoria que se está
utilizando para almacenar en caché de disco E/S.
Los campos restantes en la última línea se relacionan con el uso de espacio swap de Linux (disco de
memoria virtual) y se abordará en el último cuaderno.
¿Por qué mi memoria está siempre 90% llena?
Después de observar la memoria dinámica de kernel de Linux durante varias operaciones, los
usuarios novatos de Linux suelen sorprenderse por su incapacidad para "liberar memoria", incluso
después de salir de grandes aplicaciones. ¿Por qué bajo Linux la memoria siempre está llena un
90%? Porque el kernel está haciendo justamente lo que se supone que debe estar haciendo, es
decir, utilizando sus recursos de la mejor manera posible. La memoria que no se haya utilizado por
procesos se asigna para mejorar la velocidad de las operaciones de E/S.
Hardware and Device Configuration
Ejemplos
Uso de top para analizar la actividad del sistema
El usuario elvis se ha dado cuenta que su máquina está muy lenta. Utiliza el comando top para
analizar el comportamiento de su máquina.
[elvis@station elvis]$ top
top - 08:09:40 up 3 days, 15:29, 2 users, load average: 12.19, 6.00, 2.34
Tasks: 103 total,
9 running, 93 sleeping,
0 stopped,
1 zombie
Cpu(s): 20.0% us, 79.8% sy, 0.0% ni, 0.2% id, 0.0% wa, 0.0% hi, 0.0% si
Mem:
255148k total,
245412k used,
9772k free,
52968k buffers
Swap: 1044216k total,
176k used, 1044040k free,
111860k cached
PID
15276
15278
15280
15282
15273
15367
1
USER
blondie
blondie
blondie
blondie
root
root
root
PR
25
25
25
25
17
16
16
NI
0
0
0
0
0
0
0
VIRT RES
5208 1428
5352 908
4720 1432
4932 904
3852 968
2848 964
1932 516
SHR
632
632
632
632
756
756
440
S
R
R
R
R
S
R
S
%CPU %MEM
26.6 0.3
25.3 0.2
24.3 0.3
23.3 0.2
0.3 0.2
0.3 0.2
0.0 0.1
TIME+
6:00.14
6:12.23
5:58.29
6:15.64
0:04.60
0:00.18
0:00.56
COMMAND
find
grep
find
grep
top
top
init
...
Primero observa el número de comandos grep y find que blondie parece estar ejecutando. Hace
las siguientes anotaciones:
El promedio de carga de 1 minuto, 12.19, es alto, mientras que el promedio de carga de 15
minutos, 2.34, es bajo en comparación. Esto implica que la máquina está respondiendo a una
actividad desbordada.
Su CPU está tardando mucho en el estado de "sistema", probablemente como resultado de
toda la actividad de E/S requerida por los comandos find y grep.
De los 256 megabytes de su máquina, 53 + 111 = 164 megabytes de memoria se utilizan para
almacenar en caché operaciones E/S. Como resultado, otros procesos en la máquina
probablemente responderán de un modo muy lento, pues tienen poca capacidad en memoria
física.
Hardware and Device Configuration
Ejercicios en línea
[Warning]
Lab Exercise
Objetivo: Familiarizarse con el comando uptime.
Tiempo estimado: 5 minutos.
Specification
1. Registrar la salida del comando uptime dentro del archivo~/lab2.5/uptime.
Resultados
A title
Question 1
1. El archivo ~/lab2.5/uptime que contiene la salida del comando uptime.
grade