El estado de Rust en el kernel 2026: la transformación en marcha

Cerramos el nivel bajando de los principios al mapa real. En 2026 Rust ya no es una promesa ni un experimento: es código en producción en subsistemas que tocan tu máquina ahora mismo. Pero su avance no tiene la forma de una conquista frontal, sino la de una marea que sube por los bordes — entra donde el código es nuevo, donde el bug es más caro, donde un mantenedor decidió que el futuro de su subsistema se escribe con seguridad de memoria. Ver dónde ha llegado, cómo llegó y qué falta es entender una transformación que ningún otro cambio de lenguaje en la historia del kernel había intentado.

El mapa de 2026: dónde vive ya Rust

La marea entró primero por los drivers, y desde ahí se extendió a las piezas donde la seguridad de memoria importa más. Este es el terreno consolidado:

Cada uno de estos frentes cumple la misma lógica de la lección 54.1: son código nuevo, de alto valor de seguridad, donde el use-after-free sería catastrófico y el legado en C, inexistente o ligero.

Aquel primer PHY se declaraba con una macro del propio subsistema de red, y su forma resume la promesa entera: el andamiaje lo pone el crate kernel, y la lógica del driver vive en métodos seguros sin un solo bloque unsafe a la vista.

// Esqueleto del primer driver de hardware real: un PHY Ethernet.
// La macro del subsistema genera el registro; la logica es segura.
kernel::module_phy_driver! {
    drivers: [PhyRTL8211F],
    device_table: [
        DeviceId::new_with_driver::<PhyRTL8211F>(),
    ],
}

impl Driver for PhyRTL8211F {
    fn read_status(dev: &mut phy::Device) -> Result<u16> {
        dev.genphy_read_status()      // envoltura segura sobre la API C
    }
}

Que un fabricante de hardware pudiera portar su driver a Rust siguiendo este molde, y que el resultado entrara upstream, fue la señal de que el modelo escalaba más allá de los ejemplos didácticos.

La política de gráficos: drivers nuevos solo en Rust

El movimiento más rotundo de 2026 vino del subsistema de gráficos. Tras años de abstracciones DRM en Rust madurando, el subsistema fijó la política que marca el cambio de era: los drivers de GPU nuevos solo se aceptan en Rust. No se toca ni un driver existente —la promesa de no reescribir C sigue intacta— pero la puerta de entrada a lo nuevo cambió de lengua. La razón es doble: las GPU modernas ejecutan firmware complejo con interfaces enormes y cambiantes, terreno fértil para bugs de memoria, y son un objetivo de seguridad de primer orden. Un subsistema donde la superficie de ataque crece decidió que su código futuro naciera con la clase de bug dominante ya eliminada.

// Un driver de GPU nuevo de 2026 se declara en Rust, sobre las
// abstracciones DRM del crate kernel: probe y remove en terreno seguro.
use kernel::{drm, prelude::*};

impl drm::Driver for MiGpu {
    fn probe(dev: &drm::Device<Self>) -> Result {
        pr_info!("GPU nueva inicializada sin una linea de unsafe en el driver\n");
        Ok(())
    }
}

Que la decisión naciera precisamente en gráficos no es casualidad. Una GPU moderna no es un periférico simple: es un coprocesador con su propio firmware, que el driver alimenta con estructuras de comando compartidas a través de memoria mapeada, gestionando ciclos de vida de objetos complejos —búferes, contextos, colas— con relaciones de propiedad enrevesadas. Es el hábitat perfecto del use-after-free. El caso más célebre lo demostró un driver comunitario para la GPU de Apple, escrito en Rust fuera del árbol, cuya autora mostró que la seguridad de tipos no solo prevenía bugs sino que hacía tratable un dominio que en C era una pesadilla de sincronización manual. Cuando el subsistema vio que las abstracciones DRM en Rust estaban maduras, exigir Rust para lo nuevo dejó de ser una apuesta y pasó a ser la opción prudente.

A partir de ahí el frente de gráficos se pobló deprisa. El driver para las GPU de NVIDIA basadas en el firmware GSP se planteó en Rust desde el diseño, y aparecieron esfuerzos equivalentes para las GPU integradas de otras arquitecturas, cada uno apoyado en las mismas abstracciones DRM compartidas. El patrón se repite: no se porta el pasado, se funda el futuro sobre una base común, y esa base —revisada una vez— rebaja el coste de cada driver siguiente. La política de aceptar solo Rust para lo nuevo no es entonces una barrera, sino el reconocimiento de que ya existe un camino mejor y bien pavimentado.

El proceso: cómo entra el código Rust

La incorporación no es un decreto sino un proceso gradual y negociado, subsistema por subsistema. La regla marco, repetida desde 2022, es que Rust no reemplaza C: el código existente se queda, y Rust se usa para lo nuevo y para las abstracciones que lo sostienen. Cada subsistema decide su propio ritmo, y cada abstracción segura se revisa y se fusiona por separado, atada al mantenedor que responderá por ella.

flowchart LR
API[API C del subsistema] --> ABS[Abstraccion segura en el crate kernel]
ABS --> REV[Revision del mantenedor del subsistema]
REV --> UP[Fusion upstream]
UP --> DRV[Drivers nuevos la usan sin unsafe]
DRV --> MANT[Mantenimiento a largo plazo]

El cuello de botella no es el compilador sino lo humano: hacen falta mantenedores que conozcan a la vez el subsistema en C y Rust, revisores que sepan auditar un bloque unsafe, y consenso para que una abstracción nueva entre en el crate kernel. Por eso el avance es desigual — veloz donde un mantenedor lo empuja, lento donde nadie aún lo ha adoptado.

Hay además una asimetría de esfuerzo que conviene entender. Escribir la abstracción segura de un subsistema es mucho más costoso que escribir un driver que la use: exige razonar cada bloque unsafe, documentar cada precondición y convencer al mantenedor de que el contrato es sólido. Pero ese coste se paga una vez y lo amortizan todos los drivers futuros. Por eso el trabajo pesado de 2022 a 2026 no fue escribir muchos drivers, sino construir y consolidar las abstracciones —de platform, de DRM, de red, de sincronización— que hacen que los drivers de después sean cortos y seguros. La lección 54.3 explicó por qué; este es el nivel donde se ve el resultado acumulado.

Esa promesa se ve, literalmente, en los Makefile del kernel de 2026: el C heredado y el Rust nuevo cuelgan del mismo subsistema, seleccionados por opciones de Kconfig independientes, sin que ninguno estorbe al otro.

# El driver heredado en C sigue ahi, intacto y mantenido.
obj-$(CONFIG_GPU_HEREDADA) += gpu_heredada.o
# El driver nuevo, en Rust, convive en el mismo arbol.
obj-$(CONFIG_GPU_NUEVA)    += gpu_nueva.o

Por qué es una transformación histórica

Conviene medir la escala. Desde su origen, el kernel se escribió esencialmente en dos lenguajes: C y ensamblador. Durante más de tres décadas no entró ningún otro en el núcleo. Rust es el primer lenguaje nuevo en la historia del kernel, y no uno cualquiera: es un lenguaje de sistemas con seguridad de memoria demostrada en compilación, incorporado no a un proyecto joven sino a la base de código en C más importante y más escrutada del mundo. La combinación —el codebase más crítico adoptando la herramienta que ataca su clase de bug más peligrosa— no tiene precedente comparable en la ingeniería de software de sistemas.

La resistencia inicial fue real y razonada, y merece respeto: introducir un segundo lenguaje duplica las toolchains, parte el conjunto de personas capaces de revisar un cambio dado, y añade una frontera FFI que hay que mantener correcta para siempre. Nada de eso es gratis. Lo que inclinó la balanza no fue el entusiasmo por un lenguaje de moda, sino la aritmética fría de la seguridad: si la mayoría de las vulnerabilidades graves son bugs de memoria, y si existe una herramienta que los elimina en compilación sin coste en runtime, el coste de no adoptarla —medido en CVE, en incidentes, en parches de emergencia— acaba superando al de adoptarla. La transformación de 2026 es la constatación de que esa cuenta, sostenida durante cuatro años de evidencia, dio positivo.