Configuración de hardware y dispositivos - UTEC

Anuncio
1
Configuración de hardware y dispositivos Capítulo 1 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.
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
2
Configuración de hardware y dispositivos 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.
3
Configuración de hardware y dispositivos [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.
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.
4
Configuración de hardware y dispositivos 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.
5
Configuración de hardware y dispositivos 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
users
apm-scripts harddisks
named
logviewer
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-configredhatrhn
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
6
Configuración de hardware y dispositivos [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)
7
Configuración de hardware y dispositivos 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
8
Configuración de hardware y dispositivos 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
9
Configuración de hardware y dispositivos 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.
10
Configuración de hardware y dispositivos 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:
0 14143488 60194816
Mem: 261357568 123998208 137359360
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
11
Configuración de hardware y dispositivos 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
smart_values
12
Configuración de hardware y dispositivos [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
mode
--------acoustic
0
rw
address
0
rw
bios_cyl
730
rw
bios_head
255
rw
bios_sect
63
rw
breada_readahead
8
rw
bswap
0
r
current_speed
66
rw
...
min
max
---
---
0
254
0
2
0
65535
0
255
0
63
0
255
0
1
0
70
--
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
13
Configuración de hardware y dispositivos 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.
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 CDROMS 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
14
Configuración de hardware y dispositivos ==> /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
Ejercicios en línea
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
~/lab2.1/nicdriver dispositivo 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
15
Configuración de hardware y dispositivos ==> lab2.1/memsize <==
255
==> lab2.1/nicdriver <==
3x59x
==> lab2.1/numide <==
1
Resultados
Question 1
1. Los archivos presentados anteriormente, cada uno contiene una respuesta de una
sola palabra.
Capítulo 2 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.
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
16
Configuración de hardware y dispositivos 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 [RhineII] (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
17
Configuración de hardware y dispositivos 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
...
18
Configuración de hardware y dispositivos 03c0-03df :
03f6-03f6 :
03f8-03ff :
0cf8-0cff :
c000-c01f :
c000-c01f
c400-c407 :
c800-c8ff :
NC100
c800-c8ff
...
vesafb
ide0
serial(auto)
PCI conf1
Creative Labs SB Audigy
: Audigy
Creative Labs SB Audigy MIDI/Game port
Linksys Network Everywhere Fast Ethernet 10/100 model
: 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.
19
Configuración de hardware y dispositivos 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
20
Configuración de hardware y dispositivos 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
...
21
Configuración de hardware y dispositivos 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.
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
Ejercicios en línea
22
Configuración de hardware y dispositivos 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
Question 1
1. Los archivos presentados anteriormente, cada uno contiene una respuesta de una
sola palabra.
23
Configuración de hardware y dispositivos Capítulo 3 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.
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
24
Configuración de hardware y dispositivos 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ón-kernel) 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.
25
Configuración de hardware y dispositivos [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
26
Configuración de hardware y dispositivos 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).
Ejercicios en línea
Lab Exercise
Objetivo: Familiarizarse con módulos comunes del controlador de dispositivos
USB
Tiempo estimado: 20 minutos.
Specification
archivo /lib/modules/kernel-version/modules.usbmap (donde kernelversion se remplaza por la versión actual de kernel) contiene una base de datos ASCII
El
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).
27
Configuración de hardware y dispositivos 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
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.
Capítulo 4 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.
" 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
28
Configuración de hardware y dispositivos 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
29
Configuración de hardware y dispositivos 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
30
Configuración de hardware y dispositivos 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---...
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
31
Configuración de hardware y dispositivos brw-rw---brw-rw---brw-rw---...
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
32
Configuración de hardware y dispositivos ¿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
33
Configuración de hardware y dispositivos Nombre de
nodo
Dispositivo asociado
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 "Prepoblando" el directorio /dev con cada nodo de dispositivo posible, incluso si los
34
Configuración de hardware y dispositivos 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/udev-version.
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.
35
Configuración de hardware y dispositivos 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).
Ejercicios en línea
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).
36
Configuración de hardware y dispositivos 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
content_view let_
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.
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.
37
Configuración de hardware y dispositivos Capítulo 5 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.
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.
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
38
Configuración de hardware y dispositivos 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.
Ejercicios en línea
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
Question 1
1. El archivo ~/lab2.5/uptime que contiene la salida del comando uptime.
Descargar