Christoph Hellwig, maintainer of the DMA subsystem, KVM, Slab Allocator, and PowerPC architecture in the Linux kernel, who was once a member of the technical governing committee of the Linux Foundation and acted as a plaintiff in a court case related to the GPL against VMware, has refused to confirm patches related to driver development support in the Rust programming language. The proposed patches added wrappers over several functions of the DMA subsystem, allowing the use of DMA in Rust drivers.
The reason for the refusal cited the complexity of maintaining code with wrappers in other languages and the desire to keep the software interfaces to DMA in a readable format in C, without diffuse and unclear wrappers. Christoph suggested directly calling the original C DMA API in each Rust driver to avoid creating additional abstractions that the kernel maintainers would have to rely on.
The patch developers stated that they would take on all the work of maintaining the Rust code, were ready to maintain these patches themselves, and moved the wrappers to a separate subdirectory (rust/kernel/dma.rs). In response, Christoph vetoed (‘Nacked-by’) the acceptance of Rust-related patches and indicated that he did not need another maintainer. Christoph stated that if the wrapper developers wanted to create maintainability issues for Linux by mixing multiple languages in one codebase, they should do this in their driver rather than spreading this cancerous growth to the core subsystems.
At the same time, Christoph clarified that he has nothing against the Rust language and considers it one of the best new languages, but he is against mixing code written in different languages. According to Christoph, he supports the creation of new projects in Rust but is against mixing Rust with large codebases in C, as such mixing significantly reduces the maintainability of the kernel as an integrated project.
Istota problemów z wsparciem polega na tym, że osłony Rust uzależniają wsparcie od kodu napisanego w języku Rust. Na pierwszy rzut oka wydaje się, że osłony są jedynie nakładkami na struktury i funkcje C, które nie mają wpływu na rozwój i wsparcie kodu C. Jednak tak nie jest. W przypadku takich osłon, programiści subsystémów napisanych w C muszą uwzględniać wpływ ich zmian na dalszą funkcjonalność osłon. Każda zmiana struktur danych lub wewnętrznych funkcji w C może prowadzić do konieczności wprowadzenia zmian w kodzie osłon, dlatego zmiany w kodzie C, które wpływają na osłony, muszą być monitorowane i synchronizowane z kodem w Rust. Wielu wsparcia nie jest gotowych wziąć na siebie dodatkową odpowiedzialność za rozwiązywanie problemów pojawiających się w kodzie Rust i nie zamierza tracić czasu na monitorowanie stanu osłon Rust.
Sytuacja ze skomplikowaniem wsparcia nie jest teoretyczna. Do dyskusji włączył się Jason Gunthorpe, maintainer TPM, VFIO i Infiniband z firmy NVIDIA, który przytoczył przykład odrzucenia przez Linusa Torvaldsa pull requestu z zmianami w subsystemie zarządzania pamięcią, ponieważ zmiana ta prowadziła do awarii podczas próby kompilacji jądra z włączoną obsługą Rust. Awaria wystąpiła, ponieważ osoby wsparcia kodu Rust nie dodały niezbędnych zmian w generatorze osłon (bindgen). W ten sposób wsparcie subsystému zarządzania pamięcią, wprowadzając zmiany, które były całkowicie prawidłowe z punktu widzenia kodu C i jądra jako całości, stało się zależne od opcjonalnego, zewnętrznego kodu w jądrze, za który odpowiadają inne osoby.
Odmowa przyjęcia kodu osłony nad wywołaniami DMA postawiła programistów projektu Rust for Linux w martwym punkcie, ponieważ bez takich osłon opracowanie pełnoprawnych sterowników w języku Rust będzie utrudnione. Hector Martin, maintainer kodu dla wsparcia chipów ARM Apple i lider projektu Ashai Linux, zaproponował jako rozwiązanie konfliktu, aby uzyskać akceptację osłony bezpośrednio przez Linusa Torvaldsa, omijając osobę odpowiedzialną za subsystém DMA. Jeśli Linus zgodzi się na takie naruszenie hierarchii i ustalonych praktyk, może to doprowadzić do kryzysu zarządzania rozwojem jądra, a jeśli odmówi – zatrzyma postęp Rust w jądrze.
Jako opcję, Hektor wspomniał o pociągnięciu Kristofa do odpowiedzialności za naruszenie kodeksu postępowania z powodu komentarza, w którym Kristof porównał Rust do guza nowotworowego. Dodał również, że jest zmęczony wszystkimi biurokratycznymi przeszkodami, nie jest gotów po prostu zaufać ustalonym procesom i zasugerował zaangażowanie mediów społecznościowych. Dave Airlie, maintainer podsystemu DRM, doradził, aby nie zaogniać konfliktu i zrozumieć, że toksyczne zachowanie jest niedopuszczalne z obu stron, niezależnie od tego, kto ma rację w dyskusji.
Do dyskusji dołączył Linus Torvalds, który wskazał, że problem może leżeć w samym Hektorze i w jego pewności, że wie coś lepiej od innych, a nie w aktualnym procesie rozwoju jądra, który działa. Proces rozwoju jądra ma swoje problemy, ale to życiowa rzeczywistość — w życiu nie ma niczego idealnego. Próbę nękania przez media społecznościowe Hektor postrzega jako coś, co odbiera Linusowi chęć do jakiejkolwiek współpracy z podejściem Hektora. Dla Linusa istotne są techniczne dyskusje i poprawki, a nie wywieranie presji poprzez media społecznościowe.
W odpowiedzi Hektor wysłał prośbę o usunięcie się z grupy maintainers platformy ARM/APPLE, ponieważ stracił wiarę w stosowany w jądrze proces rozwoju i podejście do zarządzania społecznością. Oświadczył również, że rozwój platformy ARM/Apple będzie kontynuowany poza głównym jądrem Linuksa. W jądrze pozostał jeszcze jeden maintainer platformy ARM/Apple — Sven Peter, który zamierza kontynuować utrzymanie platformy w jądrze.
Źródło: opennet.ru
