- Se envió un pull request al repositorio del kernel de Linux con código en Rust que implementa la API de Direct Memory Access.
- Christoph Hellwig, mantenedor intermedio del kernel de Linux, rechazó el cambio diciendo que no se debía incorporar código en Rust al kernel de Linux, y así comenzó la disputa.
- A medida que la disputa fue creciendo, Christoph Hellwig comparó a Rust con células cancerosas.
- Hector Martin, principal responsable de Asahi Linux, reaccionó contra ese comentario sobre el cáncer y lanzó duras críticas en redes sociales, involucrando a Linus Torvalds.
- Linus Torvalds le advirtió a Hector Martin que "el problema eres tú mismo" y que no hiciera "brigading" en redes sociales.
- Actualmente, Hector Martin pidió renunciar como mantenedor del código upstream de Linux que da soporte a hardware compatible con Apple Arm.
28 comentarios
El resumen solo menciona los hechos ocurridos, pero al final del texto original (está en coreano) se agregan dos datos de contexto adicionales para entender mejor lo sucedido.
Creo que es mejor gestionar el proyecto con un solo lenguaje, pero aparte de eso, la forma en que intentan convencer a sus colegas es pésima.
Es absurdo doblegar a alguien por la fuerza.
Este es el hilo del correo del PR:
https://lwn.net/ml/all/…
Por lo que se ve, no es un PR que modifique la implementación de DMA ni que toque directamente la API de DMA, sino uno que escribió bindings FFI para poder acceder a la API de DMA desde Rust.
Y aun así rechazaron ese PR con la respuesta escueta: "No rust code in kernel/dma, please." https://lwn.net/ml/all/20250108135951.GA18074@lst.de/
Luego, cuando preguntaron entonces cuál sería la forma correcta de hacerlo, respondió: "Keep the wrappers in your code instead of making life painful for others." https://lwn.net/ml/all/20250108151858.GB24499@lst.de/
(De hecho, eso es exactamente lo que hicieron. El PR no modifica
kernel/dma, sino el subárbolrust/kernel.)Claro, si se agregan bindings FFI existe la carga de que, cuando cambie la API de DMA, también haya que actualizar los bindings FFI de Rust,
pero incluso habiendo dicho que el lado que toca Rust se encargaría de eso por su cuenta, no estoy seguro de que sea correcto que alguien que no es responsable de ese árbol reaccione así.
(Christoph Hellwig es el maintainer de
kernel/dma: https://docs.kernel.org/process/maintainers.html#dma-mapping-helpers)Por eso parece que Hector Martin metió a Linus en el hilo:
https://lwn.net/ml/all/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/
Pero lo que se comentó en el hilo inmediatamente anterior también es bastante interesante:
si aparece un breaking change en la API y el equipo de Rust no responde lo bastante rápido, el build se rompe y Linus deja de aceptar el PR.
Si lo pienso como un problema entre el módulo que introdujo el breaking change y otro módulo distinto, a mí me parece que el lado con Rust sale mejor parado.
El módulo x introdujo un breaking change, y el módulo y no pudo reaccionar lo bastante rápido:
En el kernel de Linux, la mayor parte de las partes donde Rust usa
unsafeson las que hacen wrapping con C.Además de eso, también están las partes de control de hardware donde hay que manipular memoria directamente, pero son muy pocas.
La parte donde se aplica Rust es el desarrollo de drivers. No hace falta tocar, ni se puede, la gestión de memoria, la block layer ni el kernel mismo.
Hay mucho más código de drivers que código del propio kernel. Y además, la mayoría de los puntos donde surgen problemas también están en el código de drivers.
Yo creo que lo correcto es que la parte de desarrollo de drivers se haga en un lenguaje con mayor seguridad de memoria y mejor seguridad que C.
No sé si será Rust, Zig o algún otro.
También coincido en que Rust es excesivamente complejo para desarrollar aplicaciones comunes y que es difícil de aprender rápido para los programadores de C.
Aun así, espero que, sea cual sea el lenguaje, al menos el desarrollo de drivers cambie a un lenguaje moderno.
En mi empresa anterior, me tomó aproximadamente 7 años desarrollar y estabilizar un driver de apenas unos pocos miles de líneas, y aunque no se puede simplificar por completo, diría que alrededor de 3 años fueron solo de depuración.
La mayoría eran bugs relacionados con memoria. Los errores lógicos como deadlocks eran pocos.
No se ve bien usar un proyecto grande como campo de pruebas para su propio lenguaje.
Si las cosas se tuercen, hace falta volver a los viejos tiempos en que se hacía un fork.
En un kernel que maneja todo el dispositivo, por más que usen Rust, en cuanto empiecen a usar
unsafeno puedo evitar pensar que termina siendo código difícil de leer y con problemas.No es como si fuera un proyecto sin lanzamientos principales, de esos tipo 0.91, 0.92, 0.99, 0.991 y cosas así; no entiendo por qué están porteando partes que ya funcionaban bien.
Y tampoco es que haya aparecido un gran bug y, de paso que lo arreglaban, lo hayan cambiado por algo más seguro.
Ese PR no es un port. Es un PR que agrega bindings FFI del lado de Rust para que la API de DMA existente también pueda usarse en módulos basados en Rust escritos desde cero. Y eso fue lo que bloqueó la persona responsable de DMA.
Es una pena que el cuerpo del artículo no incluya la cita original. Me dio curiosidad, así que busqué y leí la fuente; aunque tampoco creo haberlo entendido del todo, me parece que hay bastante contexto adicional como para contarlo simplemente tal como aparece en el original.
El título del artículo fue cambiado al nombre original.
Gracias por gestionarlo.
Resulta que agregar Rust a una base de código grande en C no es tan divertido como parecía. Si la idea es mejorar la seguridad de memoria, al final las áreas
unsafeigual terminan creciendo, así que la efectividad real no parece tan grande.... Al final no parece tener mucho más significado que ampliar el área donde se usa Rust.... así que parece una consecuencia natural que eso provoque el rechazo de los desarrolladores de C que ya estaban ahí. Tal vez sería mejor enfocarse en un proyecto de kernel que de verdad empiece con Rust desde cero.Vaya, la calidad del texto fue mejor de lo que esperaba; lo leí con gusto y me pareció entretenido.
Lo que Torvalds quiso decir con que el problema eres tú era que, independientemente de la adopción de Rust, las redes sociales no pueden ser la respuesta a los problemas técnicos, pero visto solo este resumen, parece que puede prestarse a malentendidos.
Fue una decisión inevitable para Héctor Martin.
Si todos los mandos intermedios de Linux están llenos de expertos en C, ¿de verdad iban a aceptar las opiniones de los pocos desarrolladores de Rust?
https://youtu.be/opTJH76wJxs?si=WHR0_1uPpSlpDTHr muestra cómo el debate termina escalando en una controversia.
¿No se suponía que hasta Torvalds permitía Rust?
Torvalds no dijo ni una sola palabra sobre Rust en esa discusión.
Cuando hay una disputa sobre opiniones técnicas, el debate debe llevarse con fundamentos técnicos; lo que está diciendo es que no intenten terminar la disputa creando opinión pública en redes sociales.
Si se creen tan buenos, entonces hagan un fork del kernel y escriban todo en Rust. En vez de eso, no intenten meterse poco a poco como un cáncer. Parece que hay muchas opiniones así.
No sé si habría sido distinto si ese código hubiera tocado
kernel/dmapara hacerlo más fácil de usar desde Rust,pero en realidad era código que añadía una capa FFI que envuelve
kernel/dmaenrust/kernel/dma.No tocaba el código original.
En la práctica, el punto central era algo como:
No me gusta que usen mal la FFI oficial de DMA hecha en Rust y luego vengan a preguntarme.
Y aun así dijo algo que no tenía mucho sentido, como que mejor dejaran que cada driver armara su propia FFI por su cuenta.
Ese es Redox. Todavía debe haber partes que no soporta, así que por eso irán a Linux...
https://vt.social/@lina/113064510447670892
Lo que escribiste parece ser exactamente las palabras de Hellwig, pero no estoy seguro de que se pueda considerar que esa opinión sea la de la mayoría.
Hola. Gracias por compartir un buen artículo. Lo leí con gusto.
Sin embargo, después de revisar el texto original y su título, quise dejar un comentario porque hay un punto que me preocupa un poco.
https://news.hada.io/guidelines
> En principio, por favor usen el título original del artículo o súbanlo con el título traducido al coreano.
Eso es lo que se sugiere ahí, y después de leer el contenido de ese artículo, creo que el título "La controversia sobre Rust en el kernel de Linux vuelve a encenderse" describe mejor el contenido que "Linus Torvalds: 'El problema eres tú'", ya que este último incluso podría prestarse más a malinterpretar el contenido que el título original.
Gracias de nuevo por el resumen y por presentar el artículo. Que tengas un buen día.
Genialísimo
Lo tendré en cuenta.
'm 'b ¡Que tengas un buen día! Gracias por compartir un buen artículo. \(__ )
Tenía la costumbre de agregar mi propio subtítulo al título para dar una explicación más precisa, pero no solo ese título no le pareció adecuado a otra persona, sino que además no sabía que existía una regla así. A partir de la próxima vez, lo publicaré exactamente como en el original.
Mientras que el título original permite entender de inmediato de qué trata, el título que cambiaste podría dar pie a que se malinterprete como algo sensacionalista. Es una opinión personal.
Gracias por la opinión.
Consideré que las declaraciones de Linus eran lo más importante, así que las puse en el título, pero parece que eso terminó distorsionándolo bastante.
Sin duda tendré más cuidado.