Linus Torvalds hat sich zu den Bedenken der Maintainer hinsichtlich der Einführung von Rust in den Kernel geäußert. Er stellte klar, dass niemand die Maintainer zwingt, die Sprache Rust zu erlernen, Rust-Code zu verwenden oder bei der Integration von Rust-Code in den Kernel zu berücksichtigen. Die Maintainer können weiterhin ausschließlich mit C-Code arbeiten, ohne sich mit Rust auseinanderzusetzen. Allerdings können solche Maintainer nicht beeinflussen, wie sich Rust im Kernel entwickelt, sie können beispielsweise nicht in die Organisation der externen Interaktion von Rust-Code mit dem Code ihrer Subsysteme eingreifen.
Maintainer, die an der Förderung von Rust interessiert sind, können in die Entwicklung einbezogen werden und dadurch die Möglichkeit haben, die Bindungen in Rust zu beeinflussen und an der Pflege der Schnittstellen in Rust teilzunehmen. Maintainer, die mit Rust nichts zu tun haben wollen, brauchen sich nicht um die Arbeiten an den Rust-Bindungen zu kümmern, aber sie werden auch keine Einflussmöglichkeiten auf deren Entwicklung haben.
So bildet sich um Entwickler, die ausschließlich die Programmiersprache C verwenden, eine Art Schutzwall, der sie vor Problemen im Zusammenhang mit Rust abschirmt und es ihnen ermöglicht, nicht mit Rust in Berührung zu kommen. Dieser Wall funktioniert jedoch in beide Richtungen; wenn ein Entwickler nicht mit Rust arbeiten möchte, hat er auch nicht die Möglichkeit, den Fortschritt von Rust zu beeinflussen. Mit anderen Worten: „Niemand ist verpflichtet, mit Rust zu arbeiten“ bedeutet nicht, dass „jeder Maintainer ein Veto gegen jeden Rust-Code einlegen kann“. Es wird davon ausgegangen, dass die Trennung der Maintainer in der Praxis nicht so radikal sein wird und einige Betreuer beginnen werden, Rust-Bindungen zu berücksichtigen und mit deren Entwicklern zusammenzuarbeiten, ohne jedoch zu intensiv in diesen Prozess einzutauchen.
In Bezug auf die Situation mit der Bestätigung von Rust-Bindings für das DMA-Subsystem, die umgangen werden, wurde Christoph Hellwig von Linus scharf kritisiert. Linus ist der Meinung, dass Christoph seine Befugnisse überschritten hat und versucht hat, Einfluss auf den Code zu nehmen, der keinerlei Verbindung zum DMA-Subsystem hatte, in einem separaten Unterverzeichnis implementiert wurde und nicht den Code betraf, für den Christoph verantwortlich war. Christoph hat versucht zu kontrollieren, wofür das DMA-Subsystem verwendet wird, und seine Maßnahmen sind mit dem Versuch vergleichbar, die Nutzung von DMA in einem bestimmten Treiber zu verbieten, nur weil ihm dieser Treiber nicht gefiel. Fazit: Trotz der Verantwortung der Maintainer für ihren Code tragen sie nicht die Verantwortung dafür, wie und von wem das Ergebnis dieser Arbeit verwendet wird.
Quelle: opennet.ru
