Linus Torvalds stellte seine Position zur Akzeptanz von Änderungen an Rust klar

Linus Torvalds beteiligte sich an der Diskussion über den Widerstand der Betreuer gegen die Einführung von Rust in den Kernel und erklärte, dass niemand die Betreuer zwinge, die Sprache Rust zu lernen, Rust-Code zu verwenden oder die Präsenz von Rust-Code im Kernel zu berücksichtigen. Betreuer können weiterhin sicher nur mit C-Code arbeiten und müssen Rust in keiner Weise beeinträchtigen. Allerdings können solche Betreuer keinen Einfluss darauf nehmen, wie sich Rust im Kernel entwickelt. Sie können sich beispielsweise nicht in die Organisation der externen Interaktion des Rust-Codes mit dem Code ihres Subsystems einmischen.

Maintainer, die an der Weiterentwicklung von Rust interessiert sind, können in die Entwicklung eingebunden werden und erhalten dann die Möglichkeit, auf die Erstellung von Rust-Bindings Einfluss zu nehmen und sich an der Wartung von Rust-Schnittstellen zu beteiligen. Betreuer, die sich nicht mit Rust befassen möchten, müssen sich zwar nicht um die Funktionsweise von Rust-Wrappern kümmern, können deren Entwicklung jedoch auch nicht beeinflussen.

Dadurch wird eine Art Schutzmauer um reine C-Entwickler errichtet, die sie vor Rust-bezogenen Problemen schützt und sie vollständig von Rust fernhält. Diese Mauer funktioniert jedoch in beide Richtungen. Wenn sich ein Entwickler also nicht mit Rust befassen möchte, hat er keine Möglichkeit, den Fortschritt von Rust zu beeinflussen. Mit anderen Worten: „Niemand muss sich mit Rust befassen“ bedeutet nicht, „jeder Betreuer kann gegen jeden Rust-Code ein Veto einlegen“. Es wird davon ausgegangen, dass die Aufteilung der Betreuer in der Realität nicht so radikal sein wird und dass einige Betreuer Rust-Bindings berücksichtigen und mit ihren Entwicklern zusammenarbeiten werden, ohne sich jedoch zu aktiv in diesen Prozess einzumischen.

In Bezug auf die Situation mit der Genehmigung von Rust-Bindings über das DMA-Subsystem unter Umgehung des Betreuers, der versucht, die Annahme solcher Bindungen zu blockieren, kritisierte Linus das Vorgehen von Christoph Helwig. Nach Linus‘ Meinung hatte Christophe seine Befugnisse überschritten und versucht, auf Code Einfluss zu nehmen, der den Code des DMA-Subsystems nicht betraf, in einem separaten Unterverzeichnis implementiert war und den Code, für den Christophe verantwortlich war, nicht betraf. Christophe versuchte zu kontrollieren, wofür das DMA-Subsystem verwendet wurde, und sein Vorgehen ist vergleichbar mit dem Versuch, die DMA-Verwendung in einem Treiber zu deaktivieren, nur weil ihm dieser Treiber nicht gefiel. Fazit: Obwohl die Betreuer für ihren Code verantwortlich sind, sind sie nicht dafür verantwortlich, wie und von wem die Ausgabe dieses Codes verwendet wird.

Source: opennet.ru