Linus Torvalds hat sich der Diskussion über den Widerstand der Maintainer gegen die Einführung von Rust in den Kernel angeschlossen und erklärt, dass niemand die Maintainer zwingt, die Programmiersprache Rust zu lernen, Rust-Code zu verwenden oder die Existenz von Rust-Code im Kernel zu berücksichtigen. Die Maintainer können weiterhin ausschließlich mit C-Code arbeiten und müssen keinen Kontakt zu Rust haben. Solche Begleiter können jedoch nicht beeinflussen, wie Rust im Kernel entwickelt wird, zum Beispiel können sie 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 erhalten dann die Möglichkeit, den Aufbau von Rust-Bindings zu beeinflussen und können an der Pflege von Rust-Schnittstellen teilnehmen. Maintainer, die nichts mit Rust zu tun haben wollen, müssen sich keine Sorgen um die Arbeit der Rust-Bindings machen, aber sie werden auch nicht in der Lage sein, deren Entwicklung zu beeinflussen.
Auf diese Weise entsteht um Entwickler, die nur die Programmiersprache C verwenden, eine Art Schutzwall, der sie vor Problemen im Zusammenhang mit Rust schützt und es ihnen ermöglicht, keinen Kontakt zu Rust zu haben. Aber dieser Wall funktioniert in beide Richtungen; wenn ein Entwickler nicht mit Rust zu tun haben möchte, hat er keine Möglichkeit, die Förderung von Rust zu beeinflussen. Mit anderen Worten: "Niemand muss sich mit Rust befassen" bedeutet nicht, dass "jeder Maintainer ein Veto gegen jeden Rust-Code einlegen kann". Es wird angenommen, dass die Teilung der Maintainer in der Praxis nicht so radikal sein wird und einige Begleiter beginnen werden, Rust-Bindings zu berücksichtigen und mit ihren Entwicklern zusammenzuarbeiten, ohne sich jedoch zu intensiv in diesen Prozess einzubringen.
Was die Situation bezüglich der Bestätigung von Rust-Bindings über das DMA-Subsystem angeht, um den Wartenden, der versucht, die Annahme solcher Bindings zu blockieren, hat Linus Christoph Hellwig kritisiert. Seiner Meinung nach hat Christoph seine Befugnisse überschritten und versucht, auf einen Code Einfluss zu nehmen, der nicht den Code des DMA-Subsystems betraf, in einem separaten Unterverzeichnis implementiert wurde und nicht den Code beeinflusste, für den Christoph verantwortlich war. Christoph versuchte zu kontrollieren, wofür das DMA-Subsystem verwendet wird, und seine Handlungen lassen sich mit dem Versuch vergleichen, die Verwendung von DMA in einem bestimmten Treiber zu verbieten, nur weil ihm dieser Treiber nicht gefiel. Fazit: Trotz der Tatsache, dass die Maintainer für ihren Code verantwortlich sind, sind sie nicht dafür verantwortlich, wie und von wem das Ergebnis ihrer Arbeit genutzt wird.
Quelle: opennet.ru
