Christoph Hellwig, mantenedor de las subsistemas DMA, KVM, Slab Allocator y arquitectura PowerPC en el núcleo de Linux, que en su momento formó parte del comité técnico de la Linux Foundation y fue demandante en un litigio relacionado con la GPL contra VMware, se negó a validar los parches relacionados con el desarrollo de controladores en lenguaje Rust. Los parches propuestos añadían envolturas sobre varias funciones del subsistema DMA, permitiendo usar DMA en controladores escritos en Rust.
Como razón de su negativa, se mencionó la complicación del mantenimiento del código debido a las envolturas en otros lenguajes y el deseo de mantener las interfaces de programación de DMA en un formato legible en C, sin diluirse en envolturas confusas. Christoph propuso hacer llamadas directas a la API C original de DMA en cada controlador escrito en Rust, para no crear abstracciones adicionales de las que dependerá el mantenimiento del núcleo.
Los desarrolladores de los parches indicaron que se harían cargo de todo el trabajo de mantenimiento del código en Rust, listos para mantener esos parches de forma independiente y separaron las envolturas en un subdirectorio (rust/kernel/dma.rs). En respuesta, Christoph vetó ('Nacked-by') la aceptación de los parches relacionados con Rust y señaló que no necesitaba otro mantenedor. Christoph afirmó que si los desarrolladores de envolturas desean lograr la imposibilidad de mantenibilidad de Linux debido a la mezcla de varios lenguajes en una única base de código, deben hacerlo en su controlador, y no propagar esta plaga a los subsistemas centrales del núcleo.
Al mismo tiempo, Christoph aclaró que no tiene nada en contra del lenguaje Rust y lo considera uno de los mejores lenguajes nuevos, pero está en contra de mezclar código en diferentes lenguajes. Según Christoph, está a favor de la creación de nuevos proyectos en Rust, pero en contra de mezclar Rust en grandes bases de código en C, ya que tal mezcla reduce considerablemente la facilidad de mantenimiento del núcleo como un proyecto integrado.
El eje de los problemas con el soporte radica en que los wrappers de Rust hacen que los mantenedores dependan del código en el lenguaje Rust. A primera vista, parece que los wrappers son solo capas sobre estructuras y funciones de C que no afectan el desarrollo y mantenimiento del código en C. Sin embargo, no es así. Con la existencia de tales wrappers, los desarrolladores de subsistemas escritos en C deben considerar el impacto de sus cambios en la continuidad del funcionamiento de los wrappers. Cualquier modificación en las estructuras de datos o funciones internas en C puede llevar a la necesidad de cambiar el código de los wrappers, por lo que los cambios que afectan a los wrappers en el código de C deben ser monitoreados y sincronizados con el código en Rust. Muchos mantenedores no están dispuestos a asumir la responsabilidad adicional de corregir problemas que surgen en el código en Rust y no quieren perder tiempo monitoreando el estado de los wrappers de Rust.
La situación con la complicación del soporte no es meramente hipotética. Jason Gunthorpe, mantenedor de TPM, VFIO e Infiniband de NVIDIA, se unió a la discusión y ejemplificó el rechazo de Linus Torvalds a un pull request que contenía cambios en el subsistema de gestión de memoria, ya que dicha modificación causaba fallos al intentar compilar el núcleo con soporte para Rust. El fallo surgió porque los mantenedores del código en Rust no añadieron los cambios necesarios en el generador de wrappers (bindgen). Así, los mantenedores del subsistema de gestión de memoria, al avanzar con un cambio que era completamente correcto desde la perspectiva del código en C y del núcleo en general, se encontraron dependientes de un código opcional externo en el núcleo, por el cual son responsables otras personas.
La negativa a aceptar el código de los wrappers sobre las llamadas DMA dejó a los desarrolladores del proyecto Rust for Linux en una encrucijada, ya que sin tales wrappers será difícil desarrollar controladores completos en el lenguaje Rust. Héctor Martín, mantenedor del código para el soporte de chips ARM de Apple y líder del proyecto Ashai Linux, sugirió como posible solución al conflicto lograr que el wrapper fuera aceptado directamente a través de Linus Torvalds, eludiendo al mantenedor del subsistema DMA. Si Linus acepta tal violación de la subordinación y de las prácticas establecidas, podría provocar una crisis en la gestión del desarrollo del núcleo; si se niega, detendrá el avance de Rust en el núcleo.
Como opción, Héctor mencionó responsabilizar a Christoph por la violación del código de conducta debido a un comentario en el que Christoph comparó a Rust con un tumor canceroso. Además, Héctor escribió que estaba cansado de todas las burocracias, no estaba dispuesto a confiar simplemente en los procesos establecidos y sugirió involucrar a las redes sociales. Dave Airlie, mantenedor del subsistema DRM, aconsejó no escalar el conflicto y entender que el comportamiento tóxico es inaceptable por ambas partes, independientemente de si el participante de la discusión tiene razón o no.
La discusión fue abordada por Linus Torvalds, quien indicó que el problema podría estar en Héctor y su arrogancia al pensar que sabe algo mejor que otros, en vez de en el actual proceso de desarrollo del núcleo, que está funcionando. El proceso de desarrollo del núcleo tiene problemas, pero esa es la realidad: nada en la vida es perfecto. Los intentos de cacería a través de las redes sociales son lo que desalienta a Linus a tener algo que ver con el enfoque de Héctor. Lo que importa para Linus son las discusiones técnicas y los parches, no la presión a través de redes sociales.
En respuesta, Héctor envió una solicitud para ser eliminado de los mantenedores de la plataforma ARM/APPLE, ya que había perdido la fe en el proceso de desarrollo y el enfoque de gestión de la comunidad aplicado en el núcleo. También afirmó que el desarrollo de la plataforma ARM/Apple continuaría fuera del núcleo principal de Linux. La plataforma ARM/Apple todavía tiene otro mantenedor en el núcleo: Sven Peter, quien tiene la intención de seguir manteniendo la plataforma en el núcleo.
Fuente: opennet.ru
