Christoph Hellwig, der Maintainer der DMA-Subsysteme, KVM, Slab Allocator und der PowerPC-Architektur im Linux-Kernel, der einst im technischen Leitungsausschuss der Linux Foundation war und als Kl\u00e4ger in einem mit der GPL verbundenen Rechtsstreit gegen VMware auftrat, verweigerte die Best\u00e4tigung von Patches, die die Unterst\u00fctzung f\u00fcr die Entwicklung von Treibern in der Programmiersprache Rust betrafen. Die vorgeschlagenen Patches f\u00fcgten Wrapper f\u00fcr mehrere Funktionen des DMA-Subsystems hinzu, die die Verwendung von DMA in Treibern in Rust erm\u00f6glichten. <\/p>\n
Als Grund f\u00fcr die Ablehnung wurde die Komplexit\u00e4t der Wartung des Codes bei Vorhandensein von Wrappern in anderen Sprachen angef\u00fchrt und das Bestreben, die Programmierschnittstellen zu DMA in lesbarer Form in C zu belassen, ohne sie mit unverst\u00e4ndlichen Wrappers zu \u00fcberladen. Christoph schlug vor, direkt auf die urspr\u00fcngliche C-API von DMA in jedem Treiber in Rust zuzugreifen, um zus\u00e4tzliche Abstraktionen zu vermeiden, von denen die Kernelpflege abh\u00e4ngt. <\/p>\n
Die Patch-Entwickler haben erkl\u00e4rt, dass sie die gesamte Wartung des Codes in Rust \u00fcbernehmen werden, bereit sind, diese Patches selbst zu unterst\u00fctzen und die Wrapper in ein separates Unterverzeichnis (rust\/kernel\/dma.rs) ausgegliedert haben. In Antwort hat Christoph ein Veto («Nacked-by») gegen die Annahme der mit Rust verbundenen Patches eingelegt und klargestellt, dass er keinen weiteren Betreuer ben\u00f6tigt. Christoph sagte, dass, wenn die Wrapper-Entwickler die Unm\u00f6glichkeit der Wartung von Linux durch die Vermischung mehrerer Sprachen in einer Code-Basis erreichen m\u00f6chten, sie dies in ihrem Treiber tun sollten, anstatt diesen Krebs in die Hauptsubsysteme des Kerns zu verbreiten. <\/p>\n
Dabei stellte Christoph klar, dass er nichts gegen die Programmiersprache Rust hat und sie als eine der besten neuen Sprachen betrachtet, jedoch gegen die Vermischung von Code in verschiedenen Sprachen ist. Laut Christoph bef\u00fcrwortet er die Schaffung neuer Projekte in Rust, ist aber gegen das Mischen von Rust mit gro\u00dfen Codebasen in C, da eine solche Vermischung die Wartbarkeit des Kerns als integriertes Projekt erheblich beeintr\u00e4chtigt. <\/p>\n
Das Kernproblem bei der Betreuung besteht darin, dass Rust-Bindungen die Betreuer von Rust-Code abh\u00e4ngig machen. Auf den ersten Blick scheinen die Bindungen nur Erweiterungen f\u00fcr C-Strukturen und -Funktionen zu sein, die keinen Einfluss auf die Entwicklung und Pflege des C-Codes haben. Doch das ist nicht der Fall. Mit solchen Bindungen m\u00fcssen die Entwickler von Subsystemen, die in C geschrieben sind, die Auswirkungen ihrer \u00c4nderungen auf die Funktionalit\u00e4t der Bindungen ber\u00fccksichtigen. Jede \u00c4nderung an den Datenstrukturen oder internen Funktionen in C kann die Notwendigkeit zur Anpassung des Bindungscodes zur Folge haben, weshalb \u00c4nderungen im C-Code, die sich auf die Bindungen auswirken, verfolgt und mit dem Code in Rust synchronisiert werden m\u00fcssen. Viele Betreuer sind nicht bereit, die zus\u00e4tzliche Verantwortung f\u00fcr die Behebung von Problemen im Rust-Code zu \u00fcbernehmen und wollen keine Zeit mit der \u00dcberwachung des Zustands der Rust-Bindungen verschwenden. <\/p>\n
Die Situation bez\u00fcglich der Komplexit\u00e4t der Unterst\u00fctzung ist nicht spekulativ. In die Diskussion wurde Jason Gunthorpe, Maintainer f\u00fcr TPM, VFIO und Infiniband bei NVIDIA, einbezogen, der ein Beispiel f\u00fcr die Ablehnung eines Pull-Requests durch Linus Torvalds anf\u00fchrte, der \u00c4nderungen im Speicherverwaltungssystem beinhaltete. Diese \u00c4nderung f\u00fchrte zu einem Fehler beim Versuch, den Kernel mit Unterst\u00fctzung f\u00fcr Rust zu kompilieren. Der Fehler trat auf, weil die Entwickler des Rust-Codes die notwendigen \u00c4nderungen im Bindings-Generator (bindgen) nicht vorgenommen hatten. So waren die Entwickler des Speicherverwaltungssystems beim Vorantreiben der \u00c4nderung, die aus Sicht des C-Codes und des Kernels insgesamt v\u00f6llig korrekt war, von optionalem Fremdcode im Kernel abh\u00e4ngig, f\u00fcr den andere Personen verantwortlich sind. <\/p>\n
Die Ablehnung, den Wrapper-Code \u00fcber den DMA-Aufrufen anzunehmen, versetzte die Entwickler des Projekts Rust f\u00fcr Linux in eine Sackgasse, da ohne solche Wrapper die Entwicklung vollst\u00e4ndiger Treiber in Rust schwierig sein wird. Hector Martin, der Maintainer des Codes zur Unterst\u00fctzung der ARM-Chips von Apple und Leiter des Projekts Ashai Linux, schlug als m\u00f6glichen Weg zur Konfliktl\u00f6sung vor, die Annahme des Wrappers direkt \u00fcber Linus Torvalds zu erreichen, um den Betreuer des DMA-Subsystems zu umgehen. Wenn Linus solchen Regelversto\u00df und die festgefahrene Praxis zustimmt, k\u00f6nnte dies zu einer Managementkrise in der Kernel-Entwicklung f\u00fchren, und wenn er ablehnt, stoppt er die Fortschritte von Rust im Kernel. <\/p>\n
Alternativ erw\u00e4hnte H\u00e9ctor, Christoph f\u00fcr einen Versto\u00df gegen den Verhaltenskodex zur Verantwortung zu ziehen, da Christoph Rust mit einem b\u00f6sartigen Tumor verglich. Zudem schrieb H\u00e9ctor, dass er von all den b\u00fcrokratischen H\u00fcrden m\u00fcde sei, nicht bereit sei, einfach den etablierten Prozessen zu vertrauen, und auf die Nutzung sozialer Medien anspielte. Dave Airlie, der Maintainer des DRM-Subsystems, riet dazu, den Konflikt nicht weiter aufzuheizen und zu verstehen, dass toxisches Verhalten von beiden Seiten nicht akzeptabel ist, unabh\u00e4ngig davon, ob der Diskussionsteilnehmer im Recht ist oder nicht. <\/p>\n
Linus Torvalds trat in die Diskussion ein und wies darauf hin, dass das Problem m\u00f6glicherweise in Hector selbst und seiner \u00dcberzeugung, dass er etwas besser wei\u00df als andere, liegt und nicht im aktuellen Entwicklungsprozess des Kernels, der funktioniert. Der Entwicklungsprozess des Kernels hat Probleme, aber das ist die Realit\u00e4t \u2013 im Leben gibt es nichts Perfektes. Versuche, \u00fcber soziale Netzwerke zu mobben, sind das, was Linus die Lust nimmt, etwas mit Hectors Ansatz zu tun zu haben. F\u00fcr Linus z\u00e4hlen technische Diskussionen und Patches, nicht der Druck \u00fcber soziale Netzwerke. <\/p>\n