En la lección anterior tratamos el disco como si fuera el dispositivo del sistema. Pero meteo-01 tiene mucho más: dos SSD NVMe, un disco mecánico, una tarjeta de red, un reloj de tiempo real, un terminal serie, un generador de números aleatorios y varios controladores USB. Y las estaciones meteorológicas que le envían datos tienen sensores, relojes y radios. Ninguno de estos dispositivos se parece a los demás: difieren en velocidad por un factor de un millón, en unidad de transferencia, en si se puede leer, escribir o ambas cosas, y en si responden en microsegundos o en minutos.

El sistema operativo tiene que ofrecer una interfaz coherente para todos ellos sin conocer los detalles de ninguno. Esta lección trata de cómo lo consigue: qué clasificación usa, por qué en UNIX "todo es un fichero", cómo aparecen los ficheros en /dev, y cuáles son las tres formas que tiene la CPU de hablar con un dispositivo. Terminaremos siguiendo el camino de una lectura de estación desde la tarjeta de red hasta el búfer del ingestor, dejando el mecanismo interno de las interrupciones para la lección siguiente, que lo desarrolla en detalle.

1. Por qué el sistema operativo uniformiza los dispositivos
2. La estructura del subsistema de E/S
3. Clasificación: bloque, carácter y red
4. "Todo es un fichero" y el directorio /dev
5. Números mayor y menor
6. udev y la creación dinámica de dispositivos
7. Buses y enumeración: lspci, lsusb, lsblk
8. Las tres formas de hablar con un dispositivo
9. Puertos de E/S y E/S mapeada en memoria
10. Técnicas del subsistema: buffering, caching, spooling y reserva
11. Tratamiento de errores y reintentos
12. El camino de una lectura de estación

Mira la variedad real a la que se enfrenta el núcleo de meteo-01:

Entre el teclado y la GPU hay nueve órdenes de magnitud de diferencia en velocidad. Y sin embargo, el programador del ingestor escribe:

y esa misma línea funciona si fd es un socket de red, un fichero en el SSD, un terminal o el generador de aleatorios. Esa uniformidad no es comodidad: es lo que hace posible escribir software.

Sin ella, cada programa tendría que conocer el modelo exacto de cada dispositivo. Un cambio de tarjeta de red obligaría a recompilar todas las aplicaciones. Es exactamente el problema que el sistema operativo como máquina extendida resuelve, y que planteamos en 01-01.

Los objetivos concretos del subsistema de E/S son cinco:

El subsistema se organiza en capas, cada una añadiendo abstracción sobre la anterior:

El reparto de responsabilidades:

El punto clave está en la capa independiente del dispositivo: es la que hace todo el trabajo común una sola vez, para que cada controlador solo tenga que implementar lo verdaderamente específico. Un controlador de red no tiene que saber nada de permisos, ni de nombres, ni de buffering: solo cómo hablar con su chip.

Y aquí conecta con la lección 01-05: los controladores viven dentro del núcleo en un sistema monolítico como Linux, cargados como módulos. Por eso un e1000e defectuoso puede tumbar la máquina entera, mientras que en un microkernel viviría en espacio de usuario a costa de más IPC.

Linux clasifica los dispositivos en tres grandes familias, y esa clasificación determina qué interfaz ofrece cada uno:

Dispositivos de bloque. La lección anterior trató su gestión completa: array de bloques numerados por LBA, planificación de peticiones, caché. La característica que los define es el acceso aleatorio: puedes leer el bloque 5.000 sin haber leído los 4.999 anteriores.

Dispositivos de carácter. Son un flujo: los bytes van llegando y no puedes retroceder. Un teclado, un puerto serie, un generador de aleatorios. No tiene sentido "buscar la posición 500" en un teclado.

La c inicial indica character device. Fíjate en que /dev/null y /dev/zero no corresponden a hardware alguno: son dispositivos virtuales implementados enteramente en software. /dev/null descarta todo lo que se le escribe; /dev/zero produce ceros infinitos. Que existan demuestra que la abstracción de dispositivo es lo bastante general como para envolver cosas que no son dispositivos.

Dispositivos de red. Son la excepción interesante: no tienen fichero en /dev.

La razón es de fondo: un fichero implica un flujo de bytes ordenado y sin pérdidas, y la red no es eso. Los paquetes pueden perderse, duplicarse o llegar desordenados, y cada uno lleva metadatos (direcciones, puertos, protocolo) que no encajan en read()/write(). Por eso UNIX inventó una abstracción distinta —el socket, con socket(), bind(), sendto(), recvfrom()— para lo que no cabía en la de fichero.

Es una lección de diseño valiosa: una abstracción buena tiene límites, y forzarla más allá de ellos produce interfaces peores. Los creadores de BSD lo reconocieron y crearon una segunda abstracción en lugar de deformar la primera.

Aun así, una vez abierto, un socket sí se maneja con un descriptor de fichero y admite read() y write(). La abstracción de fichero cubre el uso; solo la creación y la configuración necesitan interfaz propia.

El principio que define a UNIX: los dispositivos se presentan como ficheros especiales en el sistema de archivos.

Las consecuencias son enormes y muy prácticas:

Tres ventajas concretas de esto:

1. Un solo modelo de permisos. Que /dev/nvme0n1 pertenezca al grupo disk con permisos rw-rw---- es lo que impide que el usuario meteora lea el disco crudo saltándose los permisos del sistema de archivos. Sin el modelo de ficheros haría falta un sistema de permisos aparte para dispositivos.
2. Reutilización de herramientas. cat, dd, cp, grep funcionan sobre dispositivos sin haber sido programados para ello.
3. Composición. Puedes redirigir, canalizar y encadenar dispositivos como cualquier otra cosa.

Un ejemplo que aprovecha las tres a la vez:

Copia un dispositivo de bloque completo, lo comprime al vuelo y lo guarda. dd no sabe nada de NVMe, gzip no sabe nada de dispositivos, y ninguno de los dos ha necesitado saberlo.

Y el operador > de la shell aprovecha justo lo que vimos en 02-01: la shell hace fork, en el hijo abre el fichero como descriptor 1, y luego execve. El programa nuevo escribe en el descriptor 1 sin enterarse de nada.

Un fichero de dispositivo no contiene datos: contiene una referencia a un controlador. Esa referencia son dos números.

Analicemos la línea de /dev/sda campo a campo:

Donde un fichero normal mostraría su tamaño en bytes, un fichero de dispositivo muestra dos números separados por coma. Ese es el detalle que delata que no es un fichero corriente.

Ejemplos que aclaran la mecánica:

Todos tienen mayor 8 (el controlador de discos SCSI/SATA), y el menor los distingue: 0 es el disco sda entero, 1 y 2 sus particiones, 16 es el siguiente disco. La convención asigna 16 menores por disco, lo que permite 15 particiones cada uno.

Los mayores están registrados oficialmente:

Cuando abres /dev/sda, el núcleo lee el mayor (8), busca en esta tabla qué controlador lo ha registrado, y le pasa la operación junto con el menor para que sepa a qué disco se refiere. Ese es todo el mecanismo de despacho de E/S.

Puedes crear ficheros de dispositivo a mano, aunque hoy casi nunca haga falta:

Prueba conceptualmente reveladora: /dev/midisco con mayor 8 y menor 0 es exactamente /dev/sda. El nombre no significa nada; lo único que importa son los dos números. Los nombres son una convención humana.

Antiguamente /dev era un directorio normal con miles de ficheros creados de antemano por si acaso. Era un desastre: no se sabía cuáles correspondían a hardware presente, y conectar algo nuevo requería crear el fichero a mano.

Hoy /dev es un sistema de ficheros virtual (devtmpfs) que refleja el hardware realmente presente, gestionado por udev.

Cuando se conecta un dispositivo, la secuencia es:

Observarlo en directo es la mejor forma de entenderlo:

Y consultar todo lo que udev sabe de un dispositivo concreto:

Las líneas S: son enlaces simbólicos alternativos, y resuelven un problema muy real: el nombre nvme0n1 depende del orden de detección, que puede cambiar entre arranques. Los enlaces por identificador de serie no cambian nunca.

Por eso /etc/fstab debe usar UUID o /dev/disk/by-id/, nunca /dev/sda1. Si añades un disco y el orden cambia, un fstab con nombres directos puede montar el volumen equivocado. Lo veremos aplicado en Particiones, Montaje y Sistema de Archivos Virtual.

Puedes definir tus propias reglas. Un caso real de Meteora: una de las estaciones se conecta por USB-serie al servidor para diagnóstico, y quieres que aparezca siempre con el mismo nombre y accesible por el usuario meteora.

Cómo funciona cada parte:

• SUBSYSTEM=="tty": solo aplica a dispositivos de terminal serie.
• ATTRS{idVendor}/ATTRS{idProduct}: identifican el chip FTDI concreto.
• ATTRS{serial}: distingue esta estación de otra con el mismo chip. Sin él, dos adaptadores idénticos coincidirían con la regla.
• SYMLINK+=: crea /dev/meteora/estacion-norte, un nombre estable e independiente de si el núcleo la llamó ttyUSB0 o ttyUSB3.
• OWNER/GROUP/MODE: hacen el dispositivo accesible al usuario meteora sin necesidad de root.

Ese último punto es importante desde el punto de vista de seguridad: en lugar de ejecutar el proceso de diagnóstico como root para que pueda abrir el puerto serie, se le dan permisos exactos sobre ese dispositivo concreto. Es el principio de mínimo privilegio, que desarrollaremos en Principios de Protección y Control de Acceso.

Otra regla útil: fijar el planificador de E/S por tipo de dispositivo, retomando lo de la lección anterior.

Así el planificador correcto se aplica automáticamente en cada arranque y a cada disco que se conecte, según sea rotacional o no.

Los dispositivos se conectan a través de buses, y cada bus tiene su propio mecanismo de enumeración: la forma en que el sistema descubre qué hay conectado.

El identificador 03:00.0 sigue el formato bus:dispositivo.función, y es la dirección física de la tarjeta en la topología PCI. La versión detallada revela cómo habla el núcleo con ella:

Cada línea dice algo que usaremos:

• bus master: la tarjeta puede iniciar transferencias DMA por su cuenta, sin que la CPU copie los datos.
• IRQ 128: la línea de interrupción asignada. Aparecerá en /proc/interrupts.
• Memory at df200000 [size=128K]: sus registros están mapeados en memoria en esa dirección física.
• I/O ports at e000: además tiene puertos de E/S clásicos.
• MSI-X: Enable+ Count=5: usa interrupciones señalizadas por mensaje, con 5 vectores distintos.
• Kernel driver in use: igb: qué módulo la gestiona.

Esa última línea es la primera comprobación cuando un dispositivo no funciona: si no aparece, no hay driver cargado y el hardware está presente pero inerte. Es exactamente el escenario que vimos en 01-05 con lsmod y modinfo.

lsusb -t muestra el árbol con el driver de cada nodo (ftdi_sio para la estación) y la velocidad negociada (12 Mb/s, USB 1.1 completa, suficiente para un puerto serie).

Y el mapa completo de dispositivos de bloque, que vimos en la lección anterior:

Cuando la CPU necesita transferir datos con un dispositivo, hay tres mecanismos posibles. Este apartado los contrasta; el mecanismo interno de las interrupciones y del DMA es el tema de la próxima lección, aquí solo interesa cuándo se usa cada uno y cuánto cuesta.

La CPU consulta repetidamente un registro de estado del dispositivo hasta que indica que está listo, y entonces transfiere los datos ella misma, byte a byte o palabra a palabra.

• Ventaja: latencia mínima y simplicidad total. Sin interrupciones ni sincronización.
• Inconveniente: la CPU no hace nada más mientras espera.

Con un dispositivo lento el desperdicio es catastrófico:

Treinta millones de ciclos por letra. Aun así, la espera activa sigue siendo la opción correcta en tres casos: cuando el dispositivo responde en menos de lo que costaría una interrupción (unos pocos microsegundos), durante el arranque —cuando el sistema de interrupciones aún no está configurado—, y en un manejador de pánico, cuando ya no se puede confiar en nada más.

La CPU inicia la operación y se olvida: pone el proceso a dormir y planifica otro. Cuando el dispositivo termina, envía una interrupción y el núcleo despierta al proceso.

Reconocerás cada paso: son exactamente las transiciones del diagrama de estados de 02-01. Los estados S y D existen precisamente por esto.

• Ventaja: la CPU se aprovecha durante la espera.
• Inconveniente: cada interrupción cuesta entre 1 y 5 µs, y la CPU sigue copiando los datos byte a byte.

Y ahí está el problema que queda por resolver: con una tarjeta de red a 1 Gb/s recibiendo paquetes de 1.500 bytes:

Un cuarto de núcleo solo en atender interrupciones, sin contar la copia de los datos.

El DMA es un controlador que transfiere datos entre el dispositivo y la memoria sin intervención de la CPU. La CPU solo programa la operación (dirección de destino, tamaño) y recibe una única interrupción al final.

Transferir 1 MB desde un dispositivo:

Con números concretos para 1 MB desde el SSD:

Un factor de más de 150 frente a la E/S por interrupciones. Por eso todo dispositivo que mueva volumen usa DMA: discos, red, GPU, sonido. El bus master que veíamos en lspci es precisamente la capacidad de hacerlo.

Regla de decisión resumida:

Queda una pregunta: cómo se accede físicamente a los registros de un dispositivo. Hay dos enfoques.

x86 tiene un espacio de direcciones aparte, de 65.536 puertos, con instrucciones dedicadas:

Recordarás in y out de la tabla de instrucciones privilegiadas de 01-06: solo se pueden ejecutar en modo núcleo. Ese es el mecanismo que impide que un programa de usuario hable directamente con el hardware.

Ahí están los puertos históricos: 0x60 y 0x64 para el teclado, 0x3F8 para COM1, 0x70 para el reloj de tiempo real. Números que llevan sin cambiar desde el IBM PC de 1981.

Los registros del dispositivo se asignan a direcciones del espacio de memoria física. Leer o escribir en ellas es acceder al dispositivo.

Los 128 KB en 0xdf200000 son los registros de la tarjeta de red que vimos en lspci. El driver igb los ha reservado y accede a ellos con instrucciones normales de memoria.

Comparación de los dos enfoques:

MMIO ha ganado, y por una razón que ahora entiendes perfectamente: al vivir en el espacio de direcciones normal, la protección la aplica la MMU con la granularidad de página que estudiamos en 02-04. Se puede dar a un proceso acceso a los registros de un dispositivo concreto sin darle acceso a nada más. Con puertos de E/S la protección es de todo o nada.

Además, MMIO permite que un driver acceda a los registros con código C normal, sin ensamblador, lo que hace el código portable entre arquitecturas.

Un detalle crítico: las páginas de MMIO deben marcarse como no cacheables (bit PCD de la tabla de páginas, que vimos en 02-04). Si la CPU cacheara un registro de estado del dispositivo, leería un valor obsoleto de la caché en lugar del estado real del hardware, y el driver se colgaría esperando una condición que ya se cumplió. Es un ejemplo perfecto de cómo dos mecanismos correctos por separado —caché y MMIO— se destruyen mutuamente si no se coordinan.

La capa independiente del dispositivo aplica cuatro técnicas generales. Todas resuelven un desajuste distinto.

Un búfer es un área de memoria intermedia entre el productor y el consumidor. Resuelve tres problemas distintos:

Ya calculamos su impacto en 01-06: agrupar 170 lecturas antes de escribir reducía las llamadas al sistema en un factor de 167.

Por qué el doble búfer. Con un solo búfer aparece un problema de bloqueo:

Mientras el proceso procesa el búfer, el dispositivo no puede escribir en él y debe esperar. Y viceversa. Las dos partes se serializan.

Mientras el dispositivo llena el búfer A, el proceso procesa el B. Al terminar, intercambian. El rendimiento pasa de 1/(t_llenar + t_procesar) a 1/max(t_llenar, t_procesar).

Cálculo para el ingestor:

La generalización es el búfer circular con N posiciones, que es lo que usan las colas de sockets y las colas de descriptores de las tarjetas de red modernas.

Un búfer y una caché se confunden a menudo, pero son cosas distintas:

La caché de páginas de Linux es la caché de disco del sistema, y es la que veíamos como buff/cache en free -h:

Esos 4,3 GB son contenido de ficheros mantenido en RAM. Cuando el agregador lee 2026-08-31.dat por segunda vez, no toca el disco: los datos ya están ahí. Es la misma caché que respalda las páginas de mmap() que usamos en 02-04.

Comprobarlo es sencillo y muy ilustrativo:

20 veces más rápido la segunda vez, sin haber tocado el disco. Ese factor de 20 es lo que la caché de páginas aporta continuamente y de forma invisible.

Spool viene de Simultaneous Peripheral Operation On-Line. Es la técnica para dispositivos que no se pueden compartir intercalando operaciones.

Si dos procesos escriben simultáneamente en una impresora sin coordinación, la salida sale mezclada línea a línea. El spooling lo resuelve: cada trabajo se escribe completo en un directorio de cola, y un demonio los imprime uno a uno, en orden.

Lo interesante es que el spooling sigue muy vivo aunque las impresoras ya no importen: cron, el correo y las colas de mensajería usan el mismo patrón. La idea general —encolar trabajos en almacenamiento persistente y procesarlos secuencialmente con un único consumidor— es uno de los patrones más reutilizados de la informática.

En Meteora, el envío nocturno de backup al servidor remoto funciona así: los ficheros se dejan en un directorio de salida y un proceso los transfiere de uno en uno, reintentando los que fallan.

Algunos dispositivos deben usarse en exclusiva. El sistema ofrece mecanismos para reservarlos:

flock con LOCK_EX | LOCK_NB intenta un bloqueo exclusivo sin esperar: si otro proceso ya tiene el puerto, falla inmediatamente en lugar de quedarse colgado.

La reserva exclusiva introduce el riesgo de interbloqueo: si el proceso A tiene el puerto serie y espera el módem, y B tiene el módem y espera el puerto serie, ninguno avanza. Ese problema tiene lección propia: Interbloqueos.

El principio general: los errores se tratan lo más cerca posible del hardware, y solo suben si no se pueden resolver abajo.

Un ejemplo real de la cadena completa, visto desde el registro del núcleo:

Traducción de la traza:

• UNC (uncorrectable): el disco no ha podido leer un sector ni siquiera con su corrección de errores interna.
• El controlador reintentó varias veces (de ahí los 3 segundos entre la primera y la última línea).
• Al agotar los reintentos, generó un Medium Error.
• El sistema de archivos lo recibe como EIO, y el proceso que hizo read() obtiene -1 con errno = EIO.

Ese errno es exactamente el mecanismo que rastreamos hasta su origen en 01-06: un valor negativo devuelto por el núcleo que la libc convierte en -1 más errno.

Categorías de error y qué hacer con cada una:

EINTR merece insistencia porque es la fuente de errores más traicionera. Ya lo vimos en el ejemplo de buffering de 01-06: si llega una señal mientras el proceso está bloqueado en read() o write(), la llamada retorna con EINTR sin haber hecho nada. No es un error: hay que reintentar. Ignorarlo produce pérdidas de datos esporádicas e irreproducibles.

Cuatro líneas que evitan una clase entera de fallos intermitentes.

Cerramos aplicando todo a un recorrido concreto: una estación meteorológica envía una lectura de 24 bytes y el ingestor la recibe. Aquí vemos qué capas intervienen y qué hace cada una; el mecanismo interno de la interrupción y del DMA es el contenido de la próxima lección.

Recorrido con el papel de cada capa:

Fíjate en la división de trabajo. Los pasos 1-6 son específicos de esta tarjeta: solo el driver igb sabe cómo leer sus registros. A partir del paso 7 el código es común a todas las tarjetas de red del mundo: la pila IP/UDP no sabe ni le importa qué hardware trajo el paquete. Esa frontera es exactamente la que dibujamos en el diagrama de capas del apartado 2, y es la que permite que Linux soporte cientos de tarjetas distintas con una sola pila de red.

Y observa una cosa más: el ingestor no ha participado en nada de esto. Estaba dormido en estado S desde su read(). Todo el trabajo lo han hecho el hardware, el DMA, el manejador de interrupción y la pila de red. El proceso solo se despierta cuando ya hay datos esperándole.

Un cálculo de coste que motiva la próxima lección. Con 800 lecturas/segundo:

Ese es el problema de la tormenta de interrupciones, y su solución —que el sistema deje de usar interrupciones y pase a consultar activamente cuando la carga es alta— es uno de los mecanismos más elegantes del núcleo de Linux. Se llama NAPI y lo veremos en detalle a continuación.

Usar /dev/sda1 en /etc/fstab. El nombre depende del orden de detección y puede cambiar al añadir hardware. Usa siempre UUID= o /dev/disk/by-id/. El día que añadas un disco y el sistema no arranque, entenderás por qué.

Confundir búfer y caché. Un búfer contiene la única copia de datos en tránsito; perderlo pierde datos. Una caché contiene una copia de algo que existe en otro sitio; perderla solo cuesta rendimiento. drop_caches vacía cachés, nunca búferes con datos pendientes.

Ejecutar como root para acceder a un dispositivo. Casi siempre la solución correcta es una regla de udev que dé permisos exactos sobre ese dispositivo concreto al usuario que lo necesita. Root para leer un puerto serie es dar mil permisos para usar uno.

Ignorar EINTR. Es la causa más frecuente de fallos intermitentes en código de E/S. Cualquier read, write o close sobre un descriptor bloqueante debe contemplarlo.

Creer que un dispositivo de red debería tener fichero en /dev. No lo tiene, y es una decisión de diseño consciente: los paquetes no son un flujo de bytes fiable y ordenado. La abstracción correcta es el socket.

Interpretar mal lspci cuando algo no funciona. Si el dispositivo aparece pero no hay línea Kernel driver in use, el hardware está presente y sin driver. Si no aparece en absoluto, es un problema físico o de BIOS. Son dos diagnósticos completamente distintos.

Consejo de diagnóstico: cuando un dispositivo no funciona, el orden que funciona es: lspci/lsusb (¿lo ve el sistema?), lspci -v | grep -i driver (¿tiene driver?), dmesg -T | tail -50 (¿qué dijo el núcleo al detectarlo?), ls -l /dev/... (¿existe el nodo y con qué permisos?), y udevadm info --query=all --name=... (¿qué sabe udev?). Cinco comprobaciones que localizan el problema en la capa exacta.

Dada esta salida:

1. Clasifica cada entrada por tipo y explica cómo lo sabes.
2. ¿Por qué /dev/sda y /dev/sda1 comparten el mayor pero no el menor?
3. Si el usuario meteora (grupo meteora) ejecuta dd if=/dev/sda of=/tmp/copia bs=1M count=10, ¿funciona? ¿Y sobre /dev/meteora/estacion-norte?
4. ¿Qué representa el 7 en la última línea, donde las demás tienen dos números?
5. Escribe una regla de udev que dé al grupo meteora acceso de solo lectura a /dev/sda, y explica si es buena idea.

Para cada uno de estos dispositivos de Meteora, decide qué técnica de E/S es la adecuada (espera activa, interrupciones o DMA) y justifica con un cálculo:

• A: Sensor I²C en una estación, que devuelve 2 bytes en 8 µs tras la petición. Se consulta una vez por minuto. El microcontrolador va a 80 MHz.
• B: Tarjeta de red de meteo-01 recibiendo 800 lecturas/segundo de 24 bytes en paquetes UDP de 66 bytes.
• C: SSD NVMe leyendo los 17 MB de 2026-08-31.dat.
• D: Adaptador USB-serie de diagnóstico a 9.600 baudios, que envía 200 caracteres cada vez que se conecta.

Para cada uno indica la técnica, el cálculo del coste de CPU y qué pasaría si eligieras mal.

Has conectado una segunda tarjeta de red a meteo-01 para separar el tráfico de las estaciones del tráfico de la API, pero no aparece como interfaz. Diseña el procedimiento de diagnóstico completo:

1. Escribe la secuencia de órdenes que ejecutarías, en orden, y qué buscas en cada una.
2. Para cada uno de estos cuatro resultados posibles, di qué concluyes y qué harías:
   • a) lspci no muestra ninguna tarjeta nueva.
   • b) lspci la muestra pero sin línea Kernel driver in use.
   • c) lspci la muestra con driver, ip link la muestra como enp5s0 en estado DOWN.
   • d) dmesg muestra igb 0000:05:00.0: Failed to initialize MSI-X interrupts.
3. Una vez funcionando, escribe una regla de udev que le dé un nombre estable estaciones0 y explica por qué no basta con ip link set name.

Solución 1

1. Clasificación.

La señal más fiable es la columna donde un fichero normal pondría el tamaño: si hay dos números separados por coma, es un fichero de dispositivo.

2. Mismo mayor, distinto menor.

El mayor 8 identifica el controlador (sd, discos SCSI/SATA). Ambos son gestionados por el mismo driver, así que comparten mayor.

El menor identifica qué instancia concreta dentro de ese driver:

Una partición no es un dispositivo distinto: es una ventana sobre un rango de bloques del mismo disco físico. El driver sd recibe el menor, consulta su tabla de particiones y aplica el desplazamiento correspondiente.

La convención asigna 16 menores por disco: menores 0-15 para sda y sus 15 particiones, 16-31 para sdb, y así sucesivamente. Por eso /dev/sdb tiene menor 16.

3. Permisos del usuario meteora.

Sobre /dev/sda: NO funciona.

• Propietario root, con rw. meteora no es root.
• Grupo disk, con rw. Habría que comprobar si meteora pertenece a disk:

No pertenece.

• Otros: ---, sin ningún permiso.

Resultado: dd: failed to open '/dev/sda': Permiso denegado.

Y está bien que sea así. Acceso de lectura al disco crudo significa poder leer cualquier fichero del sistema saltándose por completo los permisos del sistema de archivos: /etc/shadow incluido. Es equivalente a ser root para lectura.

Sobre /dev/meteora/estacion-norte: SÍ funciona, si la regla de udev de la lección está activa.

El enlace apunta a ttyUSB0, y los permisos que cuentan son los del destino, no los del enlace (los lrwxrwxrwx de un enlace simbólico son siempre así y no significan nada). Con la regla:

Propietario meteora con rw: acceso concedido. Aunque dd sobre un puerto serie leería el flujo entrante, no un contenido con estructura.

4. El número 7 del enlace simbólico.

Es el tamaño en bytes del enlace, es decir, la longitud de la cadena que contiene:

Un enlace simbólico sí es un fichero de verdad: su contenido es la ruta de destino. Por eso muestra un tamaño donde los ficheros de dispositivo muestran mayor y menor. Los dispositivos reales no muestran tamaño porque no contienen nada: solo referencian un driver.

Comprobación:

5. Regla de udev para dar lectura de /dev/sda al grupo meteora.

Resultado: brw-r----- 1 root meteora 8, 0 /dev/sda.

¿Es buena idea? Rotundamente no.

El razonamiento:

1. Elude por completo los permisos del sistema de archivos. Leyendo el dispositivo crudo se accede a los bytes de todos los ficheros de ese disco, incluidos /etc/shadow y las claves privadas de TLS. Los permisos de fichero se aplican a través del sistema de archivos; el acceso al dispositivo lo salta.

2. Viola el principio de mínimo privilegio. Si el agregador necesita leer datos, necesita leer ficheros de /var/lib/meteora/lecturas/, no el disco entero. El permiso concedido es varios órdenes de magnitud mayor que la necesidad.

3. Amplía enormemente la superficie de ataque. Si alguien compromete un proceso que corre como meteora, obtiene lectura completa del disco.

4. No hay ningún caso legítimo en Meteora que lo requiera. Los usos reales del disco crudo —clonado, análisis forense, recuperación— son tareas administrativas puntuales, no operaciones de un servicio.

Alternativa correcta según lo que se necesite:

Esto concede exactamente una orden con exactamente unos argumentos, en lugar de acceso completo al disco. Es la diferencia entre una llave de una puerta y una llave maestra del edificio.

Solución 2

A: Sensor I²C, 2 bytes en 8 µs, una vez por minuto, microcontrolador a 80 MHz.

Técnica: espera activa.

Justificación:

• 640 ciclos es menos de lo que costaría una interrupción. Configurar el vector, guardar el contexto, ejecutar el manejador y restaurar cuesta del orden de 200-500 ciclos en un microcontrolador, más la complejidad del código. La interrupción sería más cara que la espera.
• Es un microcontrolador con FreeRTOS, como establecimos en 01-03. No hay multitarea pesada compitiendo: no hay nada mejor que hacer durante esos 8 µs.
• La simplicidad tiene valor propio en sistemas empotrados: menos código, menos estado, menos formas de fallar.

Si eligieras mal (interrupciones): funcionaría, pero con más código, más complejidad y más consumo de CPU que la propia espera. Un caso raro donde la solución "avanzada" es objetivamente peor.

B: Tarjeta de red, 800 lecturas/s en paquetes UDP de 66 bytes.

Técnica: DMA con interrupciones (y moderación de interrupciones).

Observación honesta: con solo 800 paquetes/s, DMA y las interrupciones puras dan un coste casi idéntico, porque el coste está dominado por la interrupción, no por copiar 66 bytes. El DMA gana claramente cuando los paquetes son grandes o abundantes.

Pero hay dos razones sólidas para usar DMA igualmente:

1. Escalabilidad. Si Meteora crece a 500.000 lecturas/s, sin DMA la copia sola consumiría un núcleo entero.
2. No es opcional. Las tarjetas modernas solo funcionan por DMA: el driver igb programa descriptores y la tarjeta escribe directamente en RAM. La E/S programada ya no existe en este hardware.

Si eligieras mal (espera activa): un núcleo entero consultando el registro de la tarjeta permanentemente, para recibir 52,8 KB/s. Absurdo.

C: SSD NVMe leyendo 17 MB.

Técnica: DMA, sin ninguna duda.

Y además hay un argumento cualitativo aún más fuerte:

Con espera activa, la CPU estaría bloqueada 4,9 ms sin hacer nada. A 3 GHz son casi 15 millones de ciclos perdidos, y equivale a más de un quantum completo del planificador (4 ms, según 02-02). Con DMA, esos 4,9 ms los aprovecha otro proceso.

Si eligieras mal: además del desperdicio, el proceso no podría bloquearse en estado S, rompiendo todo el modelo de planificación que estudiamos en 02-02.

D: USB-serie a 9.600 baudios, 200 caracteres al conectar.

Técnica: interrupciones (que es lo que hace el driver ftdi_sio).

Justificación: 1,04 ms por carácter es una eternidad para una CPU. Es exactamente el escenario para el que se inventaron las interrupciones: dispositivo lentísimo, datos escasos, esperas larguísimas.

Detalle interesante: USB no genera una interrupción por byte. El controlador USB agrupa las transferencias en paquetes y el chip FTDI tiene su propio búfer, así que 200 caracteres pueden llegar en 3 o 4 transferencias. Es buffering aplicado en el propio hardware, exactamente por las razones del apartado 10.

Si eligieras mal (espera activa): 208 ms de CPU bloqueada. En meteo-01, con ingestor recibiendo 800 lecturas/s, esos 208 ms significarían 166 lecturas sin atender. Un puerto serie de diagnóstico habría degradado el servicio de producción.

Resumen:

La regla que emerge: espera activa cuando la espera es más corta que la interrupción; DMA cuando hay volumen; interrupciones en todo lo demás.

Solución 3

1. Secuencia de diagnóstico.

La lógica del orden es ir de abajo arriba: hardware → driver → núcleo → interfaz. No tiene sentido investigar la configuración de red si el bus PCI ni siquiera ve la tarjeta.

2. Los cuatro escenarios.

a) lspci no muestra ninguna tarjeta nueva.

Conclusión: el problema está por debajo del sistema operativo. Linux no puede gestionar hardware que el bus PCI no enumera; no es un problema de drivers ni de configuración.

Causas posibles y qué hacer:

El reescaneo es útil porque descarta el caso de una tarjeta insertada en caliente que no fue detectada. Si tras él sigue sin aparecer, el problema es físico o de BIOS.

b) Aparece en lspci pero sin Kernel driver in use.

Conclusión: el hardware está presente y correctamente enumerado, pero no hay driver que lo gestione. La tarjeta existe e está inerte.

Si aparece Kernel modules: igb, el núcleo sabe qué módulo la gestionaría pero no lo ha cargado.

Si el módulo está en la lista negra, aparecerá en /etc/modprobe.d/:

Este es el escenario del driver e1000e defectuoso que vimos en 01-05: hardware presente, módulo ausente o bloqueado.

c) Aparece con driver, ip link la muestra como enp5s0 en estado DOWN.

Conclusión: todo el subsistema de dispositivos funciona correctamente. El driver está cargado, el núcleo ha creado la interfaz, udev la ha nombrado. Lo que falta es configuración de red o enlace físico.

Link detected es la comprobación decisiva en este escenario: separa un problema de cableado de uno de configuración, que son dos investigaciones completamente distintas.

Para hacerlo persistente:

d) dmesg muestra Failed to initialize MSI-X interrupts.

Conclusión: el driver se ha cargado pero no ha podido configurar las interrupciones, que como vimos en lspci son MSI-X con 5 vectores. Sin interrupciones funcionando, la tarjeta no puede avisar de que ha recibido paquetes.

Si dice Falling back to MSI interrupts, el driver ha degradado a MSI y probablemente funcione, aunque con menos paralelismo: en lugar de 5 vectores (uno por cola), tendrá uno solo, lo que reduce el rendimiento con carga alta.

Causas y soluciones:

Si funciona degradada a MSI, es aceptable para Meteora con 800 lecturas/s —ya calculamos que son 2,4 ms/s de CPU—, pero conviene resolverlo para tener margen de crecimiento. El detalle de MSI, MSI-X y por qué importan varios vectores es el contenido de la próxima lección.

3. Regla de udev para un nombre estable.

Explicación de cada condición:

• SUBSYSTEM=="net": solo interfaces de red.
• ACTION=="add": solo al aparecer el dispositivo.
• ATTR{address}: la dirección MAC, que es única e inmutable en el hardware. Es lo que garantiza que la regla identifique esta tarjeta y no otra.
• ATTR{type}=="1": tipo Ethernet, para no coincidir con interfaces virtuales.
• NAME=: el nombre definitivo. Ojo: para interfaces de red se usa NAME, no SYMLINK, porque la interfaz se renombra en lugar de crear un alias.

Por qué no basta con ip link set name:

El problema de fondo es el mismo que con /dev/sda1 en /etc/fstab: el nombre asignado por el núcleo depende de la enumeración del bus PCI, que puede cambiar al añadir o mover hardware. La tarjeta que hoy es enp5s0 puede ser enp6s0 mañana si insertas otra tarjeta en una ranura anterior.

Y hay un problema de orden aún más grave: ip link set name es una orden que se ejecuta después de que el sistema haya arrancado la red. Para entonces, systemd-networkd ya habrá intentado configurar enp5s0 con la configuración de estaciones0, o al revés, y la interfaz podría acabar con la IP equivocada. Con udev, el renombrado ocurre en el momento de la detección, antes de que nada más toque la interfaz.

En Meteora esto es especialmente importante: si estaciones0 (red de estaciones) y la interfaz de la API intercambiaran nombres tras un reinicio, el ingestor escucharía en la red equivocada y las lecturas se perderían sin ningún mensaje de error. Un fallo silencioso e irreversible, exactamente el que hay que diseñar para que no ocurra.

El subsistema de E/S existe para que read(fd, buf, 1024) funcione igual sobre un teclado a 100 B/s y sobre un NVMe a 3.500 MB/s, nueve órdenes de magnitud de diferencia. Lo consigue con una arquitectura en capas donde el software independiente del dispositivo hace todo lo común —nombres, permisos, buffering, caché, errores— y cada controlador solo implementa lo verdaderamente específico de su modelo.

La clasificación en bloque, carácter y red determina la interfaz: los de bloque admiten acceso aleatorio y se montan; los de carácter son flujos secuenciales; los de red no tienen fichero en /dev porque un flujo de bytes fiable no describe bien unos paquetes que pueden perderse y desordenarse, y por eso UNIX creó una segunda abstracción, el socket, en lugar de deformar la primera. El principio "todo es un fichero" unifica permisos, herramientas y composición, y descansa en un mecanismo sorprendentemente simple: los números mayor y menor, donde el mayor elige el controlador y el menor la instancia. udev puebla /dev dinámicamente y sus reglas resuelven dos problemas reales: nombres estables que no dependen del orden de detección, y permisos exactos que evitan tener que ejecutar como root.

Hay tres formas de hablar con un dispositivo, y elegir bien es cuestión de aritmética: espera activa cuando la espera es más corta que una interrupción (o durante el arranque y el pánico), interrupciones para dispositivos lentos con pocos datos, y DMA para todo lo que mueva volumen, con una reducción del coste de CPU de más de 150 veces. Los registros se alcanzan por puertos de E/S o por MMIO, y MMIO ha ganado porque su protección la aplica la MMU con granularidad de página, aunque exige marcar esas páginas como no cacheables. Finalmente, las técnicas del subsistema —buffering (con el doble búfer aportando un 62,5 % de mejora en el ingestor), caching (un factor de 20 en la segunda lectura del fichero diario), spooling y reserva— resuelven cada una un desajuste concreto, y el tratamiento de errores los resuelve lo más abajo posible, dejando arriba solo lo que requiere decisión.

Hemos seguido el camino de una lectura de estación desde la tarjeta hasta el búfer del ingestor y hemos identificado las capas, pero deliberadamente hemos dejado tres cajas sin abrir: qué hace exactamente la CPU al recibir una interrupción, cómo un controlador se registra ante el núcleo y qué contrato cumple, y cómo funciona el DMA por dentro. También ha quedado planteado un problema con números: a 500.000 lecturas por segundo, un núcleo entero se dedicaría solo a atender interrupciones. La solución a eso, y a todo lo anterior, está en Controladores, Interrupciones y Operaciones de E/S, que cierra el módulo.