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. <\/p>\n
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. <\/p>\n
Programi\u015bci \u0142at nie ukryli, \u017ce podejm\u0105 si\u0119 pe\u0142nej odpowiedzialno\u015bci za utrzymanie kodu w Rust, s\u0105 gotowi samodzielnie wspiera\u0107 te \u0142aty i przenie\u015bli obwolut\u0119 do osobnego podkatalogu (rust\/kernel\/dma.rs). W odpowiedzi Christoph wprowadzi\u0142 weto («Nacked-by») dla przyj\u0119cia powi\u0105zanych z Rust \u0142at i stwierdzi\u0142, \u017ce nie potrzebuje kolejnego opiekuna. Christoph oznajmi\u0142, \u017ce je\u015bli programi\u015bci obwoluty pragn\u0105, by niemo\u017cliwe sta\u0142o si\u0119 utrzymanie Linuksa z powodu mieszania r\u00f3\u017cnych j\u0119zyk\u00f3w w jednej bazie kodu, powinni to robi\u0107 w swoim sterowniku, a nie rozszerza\u0107 t\u0119 rakowat\u0105 zmian\u0119 na g\u0142\u00f3wne subsyst\u00e9my j\u0105dra. <\/p>\n
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. <\/p>\n
Istota problem\u00f3w z wsparciem polega na tym, \u017ce os\u0142ony Rust uzale\u017cniaj\u0105 wsparcie od kodu napisanego w j\u0119zyku Rust. Na pierwszy rzut oka wydaje si\u0119, \u017ce os\u0142ony s\u0105 jedynie nak\u0142adkami na struktury i funkcje C, kt\u00f3re nie maj\u0105 wp\u0142ywu na rozw\u00f3j i wsparcie kodu C. Jednak tak nie jest. W przypadku takich os\u0142on, programi\u015bci subsyst\u00e9m\u00f3w napisanych w C musz\u0105 uwzgl\u0119dnia\u0107 wp\u0142yw ich zmian na dalsz\u0105 funkcjonalno\u015b\u0107 os\u0142on. Ka\u017cda zmiana struktur danych lub wewn\u0119trznych funkcji w C mo\u017ce prowadzi\u0107 do konieczno\u015bci wprowadzenia zmian w kodzie os\u0142on, dlatego zmiany w kodzie C, kt\u00f3re wp\u0142ywaj\u0105 na os\u0142ony, musz\u0105 by\u0107 monitorowane i synchronizowane z kodem w Rust. Wielu wsparcia nie jest gotowych wzi\u0105\u0107 na siebie dodatkow\u0105 odpowiedzialno\u015b\u0107 za rozwi\u0105zywanie problem\u00f3w pojawiaj\u0105cych si\u0119 w kodzie Rust i nie zamierza traci\u0107 czasu na monitorowanie stanu os\u0142on Rust. <\/p>\n
Sytuacja ze skomplikowaniem wsparcia nie jest teoretyczna. Do dyskusji w\u0142\u0105czy\u0142 si\u0119 Jason Gunthorpe, maintainer TPM, VFIO i Infiniband z firmy NVIDIA, kt\u00f3ry przytoczy\u0142 przyk\u0142ad odrzucenia przez Linusa Torvaldsa pull requestu z zmianami w subsystemie zarz\u0105dzania pami\u0119ci\u0105, poniewa\u017c zmiana ta prowadzi\u0142a do awarii podczas pr\u00f3by kompilacji j\u0105dra z w\u0142\u0105czon\u0105 obs\u0142ug\u0105 Rust. Awaria wyst\u0105pi\u0142a, poniewa\u017c osoby wsparcia kodu Rust nie doda\u0142y niezb\u0119dnych zmian w generatorze os\u0142on (bindgen). W ten spos\u00f3b wsparcie subsyst\u00e9mu zarz\u0105dzania pami\u0119ci\u0105, wprowadzaj\u0105c zmiany, kt\u00f3re by\u0142y ca\u0142kowicie prawid\u0142owe z punktu widzenia kodu C i j\u0105dra jako ca\u0142o\u015bci, sta\u0142o si\u0119 zale\u017cne od opcjonalnego, zewn\u0119trznego kodu w j\u0105drze, za kt\u00f3ry odpowiadaj\u0105 inne osoby. <\/p>\n
Odmowa przyj\u0119cia kodu obwoluty nad wywo\u0142aniami DMA postawi\u0142a programist\u00f3w projektu Rust for Linux pod \u015bcian\u0105, poniewa\u017c bez tych obwolut opracowywanie pe\u0142nowarto\u015bciowych sterownik\u00f3w w j\u0119zyku Rust b\u0119dzie utrudnione. Hector Martin, opiekun kodu dla wsparcia chip\u00f3w ARM Apple i lider projektu Ashai Linux, zaproponowa\u0142 rozwi\u0105zanie konfliktu poprzez uzyskanie przyj\u0119cia obwoluty bezpo\u015brednio przez Linusa Torvaldsa, omijaj\u0105c opiekuna subsystemu DMA. Je\u015bli Linus zgodzi si\u0119 na to naruszenie hierarchii i ustalonej praktyki, mo\u017ce to doprowadzi\u0107 do kryzysu zarz\u0105dzania rozwojem j\u0105dra, a je\u015bli odm\u00f3wi \u2014 zatrzyma post\u0119py Rust w j\u0105drze. <\/p>\n
Jako opcj\u0119, Hektor wspomnia\u0142 o poci\u0105gni\u0119ciu Kristofa do odpowiedzialno\u015bci za naruszenie kodeksu post\u0119powania z powodu komentarza, w kt\u00f3rym Kristof por\u00f3wna\u0142 Rust do guza nowotworowego. Doda\u0142 r\u00f3wnie\u017c, \u017ce jest zm\u0119czony wszystkimi biurokratycznymi przeszkodami, nie jest got\u00f3w po prostu zaufa\u0107 ustalonym procesom i zasugerowa\u0142 zaanga\u017cowanie medi\u00f3w spo\u0142eczno\u015bciowych. Dave Airlie, maintainer podsystemu DRM, doradzi\u0142, aby nie zaognia\u0107 konfliktu i zrozumie\u0107, \u017ce toksyczne zachowanie jest niedopuszczalne z obu stron, niezale\u017cnie od tego, kto ma racj\u0119 w dyskusji. <\/p>\n
W dyskusj\u0119 w\u0142\u0105czy\u0142 si\u0119 Linus Torvalds, kt\u00f3ry zauwa\u017cy\u0142, \u017ce problem mo\u017ce tkwi\u0107 w samym Hectorze i jego przekonaniu, \u017ce wie co\u015b lepiej ni\u017c inni, a nie w aktualnym procesie rozwoju j\u0105dra, kt\u00f3ry dzia\u0142a. Proces rozwoju j\u0105dra ma swoje problemy, ale to \u017cyciowa rzeczywisto\u015b\u0107 \u2014 w \u017cyciu nie ma nic idealnego. Pr\u00f3bki n\u0119kania przez media spo\u0142eczno\u015bciowe to co\u015b, co zniech\u0119ca Linusa do jakichkolwiek wsp\u00f3lnych dzia\u0142a\u0144 z podej\u015bciem Hectora. Dla Linusa znaczenie maj\u0105 techniczne dyskusje i \u0142aty, a nie wywieranie presji przez media spo\u0142eczno\u015bciowe. <\/p>\n