Den ganzen Februar über waren wir verschiedene Neuigkeiten teilen auf bei Problemen und Meinungsverschiedenheiten die in der Linux-Kernel-Entwickler-Community generiert wurden für die Entwicklung in Rust.
Auch Einige der Schwergewichte der Gemeinschaft haben ihre Position bekannt gegeben und schlimmer noch, einige haben ihre Ämter niedergelegt als Betreuer einiger Linux-Kernel-Subsysteme.
Angesichts dieser Welle von Diskussionen, die außer Kontrolle zu geraten scheint, Linus Torvalds hat die Sache selbst in die Hand genommen. y hat sich an der Diskussion beteiligt um zum Widerstand einiger Betreuer gegen die Einführung von Rust im Linux-Kernel.
Laut Linus ist kein Betreuer gezwungen, zu lernen, zu verwenden oder sogar den Code betrachten, der in Rosten Sie, wenn Sie es nicht wollen, da sie weiterhin ausschließlich mit C arbeiten können.
Am Mittwoch, den 19. Februar 2025 um 22:42 Uhr, Christoph Hellwig schrieb:
>
Im Dokument heißt es, dass für die Verwendung von Rust kein Subsystem erforderlich ist. Das ist bewiesen.
> für Linus falsch sein. Und obwohl Sie es vielleicht nicht wussten, als
> Als Sie das Dokument verfasst haben, haben Sie es unbedingt dadurch verfasst, dass Sie es auf der Liste gepostet haben.Ich war voller Hoffnung und habe es versucht, um zu sehen, ob dieser lange Thread Ergebnisse bringen würde.
in etwas Konstruktives, aber das scheint rückwärts zu gehen (oder zumindest
zumindest nicht vorwärts).Tatsache ist, dass der Pull Request, gegen den Sie Einspruch erhoben haben, den DMA NICHT BERÜHRT HAT
ÜBERHAUPT KEINE SCHICHT.Er war buchstäblich nur ein weiterer Benutzer in einer völlig anderen Situation.
Unterverzeichnis, das den von Ihnen verwalteten Code in keiner Weise verändert hat,
Form oder Gestalt.
JedochWenn ein Betreuer sich dazu entscheidet, nicht mitzuwirken, hat er auch keine Möglichkeit, Einfluss zu nehmen weder in der Art und Weise, wie es entwickelt wird, noch in der Art und Weise, wie seine externen Links in den Code seines eigenen Subsystems integriert werden.
Torvalds erklärte, dass diejenigen Betreuer, die daran interessiert sind, weiter voranzukommen mit Rost wird in der Lage sein, an seiner Entwicklung teilzunehmen, den Bau zu beeinflussen von Verknüpfungen und unterstützen bei der Pflege der entsprechenden Schnittstellen. Umgekehrt werden diejenigen, die sich gegen die Arbeit mit Rust entscheiden, vor den Problemen geschützt, die bei der Verwendung auftreten können. Allerdings werden sie auch von der Einflussnahme auf die Weiterentwicklung ausgeschlossen. Dieser Ansatz schafft eine Art Barriere, die zwar diejenigen schützt, die sich ausschließlich C widmen, sie gleichzeitig aber daran hindert, zur Verbesserung der Rust-Integration beizutragen.
In dieser E-Mail geht es also nicht um eine „Rust-Richtlinie“. In dieser E-Mail geht es um eine
Ein viel größeres Problem: Als Betreuer sind Sie für Ihren Code verantwortlich.
Sicher, aber Sie haben keine Kontrolle darüber, wer das Endergebnis verwendet und wie.Sie müssen Rust nicht mögen. Um ihn musst du dir keine Sorgen machen. Das heißt…
Es wurde von Anfang an klargestellt, dass niemand
gezwungen, plötzlich eine neue Sprache lernen zu müssen, und dass Menschen, die
Wenn Sie ausschließlich auf der C-Seite arbeiten möchten, können Sie dies weiterhin tun.
Diese Situation schafft in gewisser Weise eine Schutzbarriere.für diejenigen, die nur mit C arbeiten, Isolierung von den damit verbundenen Komplexitäten und potenziellen Nachteilen zum Rust-Code. Gleichzeitig verhindert dieselbe Isolation jedoch, dass sie Einfluss auf die Weiterentwicklung von Rust nehmen können. Das bedeutet, dass das Motto „Niemand muss sich mit Rust befassen“ nicht jedem Betreuer erlaubt, in dieser Sprache geschriebenen Code zu sperren.
La Die Aufgabenverteilung ist organisiert So können diejenigen, die sich für Rust interessieren, an verschiedenen Aspekten arbeiten, während diejenigen, die sich nicht beteiligen möchten, nicht gezwungen sind, ihren Arbeitsablauf zu ändern. Allerdings können sie die Entwicklung der in Rust geschriebenen Komponenten nicht ändern.
Die Kontroverse verschärfte sich, als die Frage der Rust-Link-Genehmigung über das DMA-Subsystem aufkam. In diesem Fall wurde der Widerstand eines Betreuers, der die Annahme solcher Links blockieren wollte, ignoriert, und Linus kritisierte offen das Vorgehen von Christoph Hellwig.
Torvalds zufolge hatte Hellwig seine Befugnisse überschritten. indem er versuchte, Code zu beeinflussen, der in einem separaten Unterverzeichnis implementiert war und daher das DMA-Subsystem, für das er verantwortlich war, nicht beeinflusste. In Torvalds‘ Worten ist Hellwigs Haltung vergleichbar mit dem Versuch, DMA in einem Controller zu deaktivieren, nur weil es ihm nicht gefällt, was inakzeptabel ist.
Letztlich ist zwar jeder Betreuer für seinen eigenen Code verantwortlich, es kann jedoch nicht von ihm verlangt werden, die Verwendung dieses Codes zu kontrollieren oder über seine Integration in größere Projekte zu entscheiden.