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äger in einem mit der GPL verbundenen Rechtsstreit gegen VMware auftrat, verweigerte die Bestätigung von Patches, die die Unterstützung für die Entwicklung von Treibern in der Programmiersprache Rust betrafen. Die vorgeschlagenen Patches fügten Wrapper für mehrere Funktionen des DMA-Subsystems hinzu, die die Verwendung von DMA in Treibern in Rust ermöglichten.
Als Grund für die Ablehnung wurde die Komplexität der Wartung des Codes bei Vorhandensein von Wrappern in anderen Sprachen angeführt und das Bestreben, die Programmierschnittstellen zu DMA in lesbarer Form in C zu belassen, ohne sie mit unverständlichen Wrappers zu überladen. Christoph schlug vor, direkt auf die ursprüngliche C-API von DMA in jedem Treiber in Rust zuzugreifen, um zusätzliche Abstraktionen zu vermeiden, von denen die Kernelpflege abhängt.
Die Patch-Entwickler haben erklärt, dass sie die gesamte Wartungsarbeit für den Code in Rust übernehmen werden, die betreffenden Patches selbstständig unterstützen und die Wrapper in ein separates Unterverzeichnis (rust/kernel/dma.rs) ausgelagert haben. Als Antwort hat Christoph ein Veto („Nacked-by“) gegen die Annahme der mit Rust verbundenen Patches eingelegt und darauf hingewiesen, dass er keinen weiteren Betreuer benötigt. Christoph erklärte, dass die Entwickler der Wrapper, wenn sie die Unmöglichkeit der Wartung von Linux aufgrund der Vermischung mehrerer Sprachen in einer Codebasis erreichen wollen, dies in ihrem eigenen Treiber tun sollten und nicht diese Krebsgeschwulst auf die Kern-Subsysteme ausweiten sollten.
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ürwortet er die Schaffung neuer Projekte in Rust, ist aber gegen das Mischen von Rust mit großen Codebasen in C, da eine solche Vermischung die Wartbarkeit des Kerns als integriertes Projekt erheblich beeinträchtigt.
Das Kernproblem bei der Betreuung besteht darin, dass Rust-Bindungen die Betreuer von Rust-Code abhängig machen. Auf den ersten Blick scheinen die Bindungen nur Erweiterungen für 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üssen die Entwickler von Subsystemen, die in C geschrieben sind, die Auswirkungen ihrer Änderungen auf die Funktionalität der Bindungen berücksichtigen. Jede Änderung an den Datenstrukturen oder internen Funktionen in C kann die Notwendigkeit zur Anpassung des Bindungscodes zur Folge haben, weshalb Änderungen im C-Code, die sich auf die Bindungen auswirken, verfolgt und mit dem Code in Rust synchronisiert werden müssen. Viele Betreuer sind nicht bereit, die zusätzliche Verantwortung für die Behebung von Problemen im Rust-Code zu übernehmen und wollen keine Zeit mit der Überwachung des Zustands der Rust-Bindungen verschwenden.
Die Situation bezüglich der Komplexität der Unterstützung ist nicht spekulativ. In die Diskussion wurde Jason Gunthorpe, Maintainer für TPM, VFIO und Infiniband bei NVIDIA, einbezogen, der ein Beispiel für die Ablehnung eines Pull-Requests durch Linus Torvalds anführte, der Änderungen im Speicherverwaltungssystem beinhaltete. Diese Änderung führte zu einem Fehler beim Versuch, den Kernel mit Unterstützung für Rust zu kompilieren. Der Fehler trat auf, weil die Entwickler des Rust-Codes die notwendigen Änderungen im Bindings-Generator (bindgen) nicht vorgenommen hatten. So waren die Entwickler des Speicherverwaltungssystems beim Vorantreiben der Änderung, die aus Sicht des C-Codes und des Kernels insgesamt völlig korrekt war, von optionalem Fremdcode im Kernel abhängig, für den andere Personen verantwortlich sind.
Die Ablehnung, den Wrapper-Code über DMA-Aufrufe hinzuzufügen, hat die Entwickler des Projekts Rust for Linux vor ein Dilemma gestellt, da die Entwicklung vollständiger Treiber in der Programmiersprache Rust ohne solche Wrappers erschwert wird. Hector Martin, der Maintainer des Codes zur Unterstützung von ARM-Chips von Apple und Leiter des Ashai Linux-Projekts, schlug als Lösung des Konflikts vor, die Annahme des Wrappers direkt über Linus Torvalds zu erwirken, um den zuständigen DMA-Unterstützer zu umgehen. Sollte Linus einer solchen Verletzung der Hierarchie und der etablierten Praktiken zustimmen, könnte dies zu einer Krise in der Entwicklung des Kernels führen; lehnte er ab, würde dies den Fortschritt von Rust im Kernel stoppen.
Alternativ erwähnte Héctor, Christoph für einen Verstoß gegen den Verhaltenskodex zur Verantwortung zu ziehen, da Christoph Rust mit einem bösartigen Tumor verglich. Zudem schrieb Héctor, dass er von all den bürokratischen Hürden müde 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ängig davon, ob der Diskussionsteilnehmer im Recht ist oder nicht.
An der Diskussion nahm Linus Torvalds teil, der anmerkte, dass das Problem möglicherweise bei Héctor selbst liegt und seiner Überzeugung, er wüsste etwas besser als andere, und nicht im aktuellen Entwicklungsprozess des Kernels, der funktioniert. Der Prozess der Kernel-Entwicklung hat Probleme, aber das ist die Realität — im Leben gibt es nichts Perfektes. Versuche, über soziale Medien zu mobben, demotivieren Linus, etwas mit Héctors Ansatz zu tun zu haben. Für Linus sind technische Diskussionen und Patches von Bedeutung, nicht Druckausübung durch soziale Medien.
In seiner Antwort hat Hector eine Anfrage zur Entfernung seiner Person von den unterstützenden Plattformen ARM/APPLE gestellt, da er das Vertrauen in den im Kernel angewandten Entwicklungsprozess und das Community-Management verloren hat. Er erklärte auch, dass die Entwicklung der ARM/Apple-Plattform außerhalb des Hauptkerns von Linux fortgesetzt wird. Im Kernel bleibt ein weiterer Hauptbetreuer für die ARM/Apple-Plattform – Sven Peter, der die Unterstützung der Plattform im Kernel fortsetzen möchte.
Quelle: opennet.ru
