El kernel de Linux se prepara para la actualización a Rust 1.77

Artículo original ↗ Discusión en Hacker News ↗

El paso de Linux a toolchains más nuevas de Rust, incluida la actualización planificada a Rust 1.77, está provocando debate sobre cuánto debería depender el kernel de funciones inestables del compilador y qué significa eso para el mantenimiento a largo plazo. Los comentaristas sopesan los beneficios de Rust —seguridad de memoria, abstracciones modernas y soporte evolutivo para asignadores— frente a preocupaciones prácticas como el arranque del compilador, el tamaño binario y la proporción aún diminuta de código del kernel escrito en Rust. Hay un amplio acuerdo en que Rust seguirá siendo opcional e incremental en el kernel por ahora, sirviendo como banco de pruebas para dar forma tanto al lenguaje como a sus herramientas para el trabajo de sistemas de bajo nivel.

Versionado de Rust y uso de funciones inestables en el kernel

  • Para proyectos ordinarios que usan Rust estable, las actualizaciones del compilador son en su mayoría compatibles hacia atrás; herramientas como clippy y cargo fmt ayudan a seguir los cambios de estilo y lint.
  • Rust-for-Linux usa deliberadamente funciones nightly/inestables, así que las actualizaciones pueden requerir correcciones no triviales.
  • Esto se considera necesario para ejercer funciones que faltan (por ejemplo, offset_of, APIs de asignador) y ayudar a empujarlas hacia la estabilización.
  • Estimación citada: ~0.5 horas por millón de líneas de Rust para actualizar compiladores en bases de código grandes; Rust-for-Linux tiene una sobrecarga mayor debido al uso de nightly.

Asignadores y gestión de memoria

  • El kernel necesita asignación de memoria de granularidad fina, fallible y por tipo de objeto, lo que lo empuja hacia las APIs inestables de Allocator en lugar de solo GlobalAlloc.
  • allocator_api proporciona construcción fallible (por ejemplo, try_new) y flexibilidad que las APIs estables no tienen.
  • La biblioteca estándar por sí sola puede usar funciones inestables; las crates de terceros no pueden hacerlo en estable.

Tamaño binario y dependencias

  • Muchas quejas sobre el tamaño binario de Rust están ligadas a:
    • La maquinaria de depuración/panic (por ejemplo, backtrace, formato consciente de Unicode).
    • Enlace estático de std.
    • Árboles de dependencias pesados y monomorfización.
  • En contextos no-std (microcontroladores, kernel) los binarios pueden ser mucho más pequeños.
  • La separación de símbolos de depuración y el despojado, además de los próximos valores predeterminados de Cargo, reducirán los tamaños; pero el “hello world” de Rust sigue teniendo una sobrecarga constante relativamente grande frente a C.
  • Algunos argumentan que los grandes árboles de compilación y cachés (cientos de MB) son problemáticos; otros señalan que esto es comparable con toolchains modernas y que Rust en el kernel no arrastrará grandes grafos de dependencias.

Alcance y estructura de Rust en el kernel

  • El código Rust es actualmente una fracción diminuta del kernel (del orden de ~0.03–0.05% de las líneas).
  • La mayor parte es infraestructura; los drivers en Rust siguen siendo “errores de redondeo”, con ejemplos como una reescritura del binder de Android.
  • El kernel usa core y un alloc personalizado, pero no std.

Arranque, LFS y toolchains

  • Preocupación: la historia de arranque de Rust es “fea” y podría amenazar Linux From Scratch (LFS).
  • Contraargumento: LFS ya asume un compilador C en el host; de forma similar podría asumir un compilador Rust en el host y usar solo rustc para producir archivos objeto.
  • En comparación con arrancar otros compiladores complejos (por ejemplo, GHC), la situación de Rust es criticada pero no única.

Seguridad de bajo nivel, punteros y elección del lenguaje

  • La discusión sobre operaciones inseguras con punteros y macros frente a aritmética de punteros segura resalta sutilezas de UB y compensaciones de rendimiento.
  • Aclaración de las capas de la biblioteca de Rust: core (primitivas del lenguaje), alloc (tipos en heap), std (funciones dependientes del SO).
  • Algunos quieren no solo una reescritura en un lenguaje, sino verificación formal al estilo de seL4.
  • Se plantea la pregunta: “¿Por qué Rust en lugar de Zig?”
    • Un lado valora las fuertes garantías de seguridad de memoria de Rust.
    • Otro sostiene que los errores de memoria pueden manejarse con pruebas y que la seguridad de Rust tiene sus propias compensaciones; no se alcanzó consenso.