Do dyskusji na temat oporu maintainerów przed wprowadzeniem Rust do jądra dołączył Linus Torvalds, który wyjaśnił, że nikt nie zmusza maintainerów do nauki języka Rust, korzystania z kodu w Rust ani uwzględniania obecności kodu Rust w jądrze. Maintainerzy mogą spokojnie kontynuować pracę wyłącznie z kodem w C i nie muszą mieć do czynienia z Rust. Jednak tacy maintainerzy nie mogą wpływać na to, jak Rust rozwija się w jądrze, na przykład nie mogą ingerować w organizację zewnętrznej interakcji kodu Rust z kodem ich podsystemu.
Maintainerzy, którzy są zainteresowani promowaniem Rust, mogą być zaangażowani w rozwój i wtedy mają możliwość wpływania na budowanie bindów w Rust oraz mogą uczestniczyć w utrzymaniu interfejsów w Rust. Maintainerzy, którzy nie chcą mieć do czynienia z Rust, mogą nie martwić się o pracę bindów w Rust, ale nie będą mogli również wpływać na ich rozwój.
W ten sposób wokół programistów używających wyłącznie języka C formuje się swoista bariera ochronna, która odgradza ich od problemów związanych z Rust i pozwala na niekontaktowanie się z Rust. Ale ta bariera działa w obie strony, więc jeśli programista nie chce mieć do czynienia z Rust, nie ma możliwości wpływania na rozwój Rust. Innymi słowy: „nikt nie ma obowiązku zajmować się Rust” nie oznacza, że „każdy maintainer może wetować jakikolwiek kod w Rust”. Zakłada się, że w rzeczywistości podział maintainerów nie będzie tak radykalny i niektórzy maintainerzy zaczną uwzględniać bindy w Rust i współpracować z ich twórcami, ale nie zanurzą się zbyt aktywnie w ten proces.
Jeśli chodzi o sytuację z potwierdzaniem powiązań Rust w subsystemie DMA, z pominięciem utrzymującego, który starał się zablokować przyjmowanie takich powiązań, Linus skrytykował działania Christophora Helwiga. Według Linusa, Christoph przekroczył swoje uprawnienia i próbował wpłynąć na kod, który nie dotyczył subsystemu DMA, został zrealizowany w osobnym podkatalogu i nie wpływał na kod, za który odpowiadał Christoph. Christoph próbował kontrolować, w jaki sposób jest używana subsystems DMA, a jego działania można porównać do prób zakazu używania DMA w jakimś sterowniku, tylko dlatego, że nie podobał mu się ten sterownik. Wniosek: mimo że utrzymujący odpowiadają za swój kod, nie odpowiadają za to, jak i przez kogo wykorzystany jest wynik pracy tego kodu.
Źródło: opennet.ru
