Cómo conviven Rust y C: bindings, FFI y el crate kernel

La primera idea equivocada sobre Rust en el kernel es imaginar una reescritura. No la hay ni la habrá: los cuarenta millones de líneas de C se quedan donde están, y Rust entra por el lado del código nuevo, donde el coste de un bug de memoria es más alto y el legado más ligero — los drivers. Para que eso funcione, Rust y C tienen que hablarse en el mismo proceso, compartir estructuras y llamarse mutuamente sin una capa de traducción en runtime. El puente que lo permite se apoya en un hecho antiguo: ambos lenguajes saben hablar la ABI de C.

Rust entra por el código nuevo

La regla que hizo posible aceptar Rust fue una promesa de no agresión: no se reescribe C que funciona. Un subsistema maduro y auditado no gana nada con una traducción que solo puede introducir regresiones. Rust se reserva para lo que se escribe desde cero, y ahí los drivers son el terreno natural: son la mayor parte del kernel, la que más gente nueva toca, la que más sufre use-after-free, y la que menos depende del núcleo interno. Un driver en Rust se compila a un .o, se enlaza en el mismo vmlinux y corre en el mismo espacio de direcciones que el C que lo rodea. No hay dos kernels: hay uno solo, con partes en cada lengua.

La FFI y la ABI C compartida

Que dos lenguajes convivan en un binario exige que acuerden cómo se pasan los argumentos, cómo se disponen las estructuras en memoria y qué nombre tiene cada símbolo. Ese acuerdo es la ABI, y el kernel usa la de C. Rust sabe emitir y consumir esa ABI cuando se lo pides con extern "C" y con #[repr(C)], la representación que ordena los campos como lo haría un compilador de C en lugar de reordenarlos a su gusto.

// Declarar una funcion C para llamarla desde Rust: esto es la FFI.
extern "C" {
    fn kfree(objp: *const core::ffi::c_void);
}

// Una struct compartida con C debe tener el layout de C, no el de Rust.
#[repr(C)]
struct Cabecera {
    longitud: u32,
    banderas: u32,
}

Llamar a kfree desde Rust es una operación unsafe: cruzar la frontera FFI abandona el territorio donde el compilador puede razonar, porque al otro lado hay C, que no ofrece ninguna garantía. Escribir esas declaraciones a mano para las decenas de miles de funciones del kernel sería inviable y frágil. Por eso no se escriben a mano.

bindgen: los headers C se vuelven Rust

bindgen es la herramienta que lee los headers de C y genera las declaraciones extern "C" y los #[repr(C)] equivalentes en Rust. El kernel mantiene un único header de entrada, rust/bindings/bindings_helper.h, que incluye los headers cuyas APIs quiere exponer. En cada compilación, bindgen lo procesa y produce un fichero Rust con miles de declaraciones.

// rust/bindings/bindings_helper.h  (fragmento)
#include <linux/slab.h>
#include <linux/mutex.h>
#include <linux/gpio/driver.h>

// bindings_generated.rs  (lo produce bindgen, simplificado)
extern "C" {
    pub fn mutex_lock(lock: *mut mutex);
    pub fn mutex_unlock(lock: *mut mutex);
}
#[repr(C)]
pub struct mutex {
    pub owner: atomic_long_t,
    /* ...campos generados desde el struct C... */
}

Estas declaraciones son deliberadamente crudas e inseguras: reflejan la API C tal cual, con punteros y sin garantías. No están pensadas para que las use un driver, sino para que las envuelva la capa segura de la lección siguiente. Viven en el crate bindings y se reexportan como kernel::bindings.

// rust/helpers/helpers.c
void rust_helper_spin_lock(spinlock_t *lock) { spin_lock(lock); }

El crate kernel y el build sin Cargo

Sobre los bindings crudos se asienta el crate kernel: la biblioteca estándar del kernel para Rust. Reexporta los bindings, ofrece las abstracciones seguras, define macros como pr_info! y module!, y expone un prelude con lo esencial. Un módulo mínimo no toca casi nada de esto directamente:

// SPDX-License-Identifier: GPL-2.0
use kernel::prelude::*;

module! {
    type: RustMinimo,
    name: "rust_minimo",
    author: "Autoria del driver",
    description: "Un modulo minimo en Rust",
    license: "GPL",
}

struct RustMinimo;

impl kernel::Module for RustMinimo {
    fn init(_module: &'static ThisModule) -> Result<Self> {
        pr_info!("Hola desde Rust\n");
        Ok(RustMinimo)
    }
}

Todo el kernel Rust es no_std: no hay biblioteca estándar, porque std presupone un sistema operativo debajo — precisamente lo que aquí estamos construyendo. Se usa core (el subconjunto sin asignación) más lo que el crate kernel provee. Y no hay Cargo: la construcción no la orquesta el gestor de paquetes de Rust sino Kbuild, que invoca rustc directamente con las mismas banderas de configuración que gobiernan el C.

obj-$(CONFIG_RUST_MINIMO) += rust_minimo.o

# Habilitar Rust en la configuracion y compilar con la toolchain LLVM
make LLVM=1 rustavailable      # comprueba que la toolchain Rust esta lista
make menuconfig                # General setup -> Rust support
make LLVM=1 -j$(nproc)

Que no haya Cargo sorprende a quien viene de Rust en espacio de usuario, pero es coherente: Cargo descarga dependencias de la red, gestiona versiones y presupone un sistema operativo debajo, y nada de eso tiene sentido en un kernel que debe compilarse de forma reproducible, sin red, con las mismas banderas exactas que gobiernan cada archivo de C. Kbuild ya hacía ese trabajo para C, así que Rust se somete a él: rustc se invoca como un compilador más de la cadena, con las opciones que fija Kconfig, y el .o que produce entra en el mismo enlazado que todo lo demás. El árbol trae además los pocos crates externos que necesita ya integrados —como pin-init, que resuelve la inicialización en el lugar de estructuras que no se pueden mover— para no depender de un registro remoto.