OpenBSD mantiene soporte para dispositivos legados con su modelo de driver genérico
El proyecto sigue manteniendo operativos controladores para hardware obsoleto mediante una arquitectura de bus abstracta y revisiones de código estrictas.
OpenBSD ha vuelto a poner el foco en su filosofía de soporte de hardware arcaico. Mientras la mayoría de los sistemas operativos modernos abandonan controladores para dispositivos que ya no se fabrican, el proyecto de security‑first mantiene una capa de abstracción que permite que tarjetas SCSI de los años 80 o tarjetas de red poco documentadas sigan funcionando.
Arquitectura del driver
El núcleo del modelo de OpenBSD se basa en las APIs bus_space y bus_dma, que ocultan operaciones de I/O y DMA independientemente del bus subyacente (PCI, ISA, etc.). Un driver se registra mediante una estructura cfattach que contiene las funciones match y attach. En la fase de autoconfiguración, el kernel recorre el árbol de dispositivos y llama a cada match; si este devuelve éxito, se ejecuta attach y el dispositivo queda enlazado al subsistema correspondiente.
El proceso se ilustra con un árbol simplificado:
mainbus → pci* → scsi*
│ │ │
match/attach match/attach match/attach
Cada driver de bus itera sobre sus hijos, aplicando los mismos pasos. Para hardware sin registros PCI estándar, los match recurren a heurísticas de sondeo que pueden implicar lecturas directas de puertos I/O.
Ejemplo de código
A modo de demostración, el artículo incluye un driver ficticio para una tarjeta de sonido ISA de 16 bits. El código muestra cómo se usa bus_space_map para mapear el rango de puertos (0x300‑0x307), leer un registro de firma y, si coincide, declarar el dispositivo como presente. La función de attach guarda el bus_tag, establece la interrupción mediante isa_intr_establish y registra el dispositivo en el kernel.
int medieval_match(struct device *parent, struct cfdata *cf, void *aux) {
struct isa_attach_args *ia = aux;
bus_space_tag_t iot = ia->ia_iot;
bus_space_handle_t ioh;
if (bus_space_map(iot, 0x300, 8, 0, &ioh) != 0) return 0;
int ok = (bus_space_read_1(iot, ioh, 0) == 0x5A);
bus_space_unmap(iot, ioh, 8);
return ok;
}
Coste y compromisos
Mantener estos controladores aumenta la huella del kernel y el tiempo de compilación. Cada nuevo driver implica más código que debe revisarse y probarse, lo que contrasta con la política de muchas distribuciones que prefieren eliminar soporte para reducir la superficie de ataque. OpenBSD, sin embargo, considera que la portabilidad incluye la capacidad de reutilizar hardware legado en entornos críticos donde la sustitución no es viable.
Por qué importa
Para administradores de sistemas que gestionan infraestructura heredada —por ejemplo, servidores de backup con controladores SCSI antiguos— la continuidad del soporte evita costosos reemplazos y permite migrar a un entorno más seguro sin perder funcionalidad. La arquitectura modular y el riguroso proceso de revisión garantizan que, aunque el hardware sea raro, su integración siga siendo fiable.
En definitiva, el enfoque de OpenBSD muestra que la obsolescencia rápida no es una imposición inevitable; con una capa de abstracción bien diseñada, incluso los dispositivos más “medievales” pueden seguir operando bajo un sistema moderno y seguro.
