Christoph Hellwig, Maintainer der DMA-Subsystem, KVM, Slab Allocator und PowerPC-Architektur im Linux-Kernel, der zu seiner Zeit Mitglied des technischen Ausschusses der Linux Foundation war und Kläger in einem mit der GPL verbundenen Rechtsstreit gegen VMware, weigerte sich, Patches zu bestätigen, die die Entwicklung von Treibern in der Programmiersprache Rust unterstützen. Die vorgeschlagenen Patches fügte Wrapper über mehrere Funktionen des DMA-Subsystems hinzu, die die Verwendung von DMA in Treibern in der Programmiersprache Rust ermöglichen sollten.
Als Grund für die Ablehnung wurde die Komplexität der Wartung des Codes bei Vorhandensein von Wrappern in anderen Sprachen sowie das Bestreben erwähnt, die Programmierschnittstellen zu DMA in lesbarem C-Format zu erhalten, ohne sie durch unverständliche Wrapper zu verwässern. Christoph schlug vor, direkt auf die ursprüngliche C-DMA-API in jedem Treiber in Rust zuzugreifen, um keine zusätzlichen Abstraktionen zu schaffen, von denen die Kernel-Wartenden abhängig wären.
Die Patch-Entwickler gaben an, dass sie die gesamte Wartung des Codes in Rust übernehmen würden, bereit sind, die Patches eigenständig zu warten und die Wrapper in ein separates Unterverzeichnis (rust/kernel/dma.rs) auszulagern. Als Antwort darauf legte Christoph ein Veto („Nacked-by“) gegen die Annahme der mit Rust verbundenen Patches ein und erklärte, dass er keinen weiteren Wartenden benötige. Christoph äußerte, dass, wenn die Wrapper-Entwickler die Unwartbarkeit von Linux durch das Mischen mehrerer Sprachen in einer Codebasis erreichen wollten, sie dies in ihrem eigenen Treiber tun sollten, anstatt diesen Krebsgeschwür auf die Hauptsubsysteme des Kernels auszubreiten.
Gleichzeitig stellte Christoph klar, dass er nichts gegen die Programmiersprache Rust hat und sie als eine der besten neuen Sprachen betrachtet. Aber er ist gegen die Vermischung von Code in verschiedenen Sprachen. Laut Christoph setzt er sich für die Schaffung neuer Projekte in Rust ein, ist jedoch gegen die Vermischung von Rust in großen C-Codebasen, da diese Vermischung die Wartung des Kernels als integriertes Projekt erheblich erschwert.
Der Kern der Probleme mit der Begleitung liegt darin, dass Rust-Bindings die Begleitperson von dem Code in Rust abhängig machen. Auf den ersten Blick scheint es, dass die Bindings nur Ergänzungen zu C-Strukturen und -Funktionen sind, die sich nicht auf die Entwicklung und Pflege von C-Code auswirken. Das ist jedoch nicht der Fall. Bei Vorhandensein solcher Bindings müssen Entwickler von Subsystemen, die in C geschrieben sind, die Auswirkungen ihrer Änderungen auf die Funktionsfähigkeit der Bindings berücksichtigen. Jede Änderung der Datenstrukturen oder internen Funktionen in C kann die Notwendigkeit zur Änderung des Binding-Codes hervorrufen, daher müssen Änderungen am C-Code, die die Bindings betreffen, verfolgt und mit dem Rust-Code synchronisiert werden. Viele Begleiter sind nicht bereit, die zusätzliche Verantwortung für die Behebung von Problemen, die im Rust-Code auftreten, zu übernehmen, und beabsichtigen nicht, ihre Zeit mit der Verfolgung des Status der Rust-Bindings zu verbringen.
Die Situation mit der Komplexität der Begleitung ist nicht theoretisch. An der Diskussion beteiligte sich Jason Gunthorpe, Wartungsleiter von TPM, VFIO und Infiniband bei NVIDIA, der ein Beispiel für die Ablehnung eines Pull-Requests von Linus Torvalds anführte, der Änderungen im Subsystem zur Speicherverwaltung enthielt, da diese Änderung zu einem Fehler beim Versuch führte, den Kernel mit Rust-Unterstützung zu kompilieren. Der Fehler trat auf, weil die Begleiter des Rust-Codes die notwendigen Änderungen nicht in den Binding-Generator (bindgen) eingefügt hatten. Damit waren die Begleiter des Subsystems zur Speicherverwaltung bei der Förderung einer Änderung, die aus Sicht des C-Codes und des Kernels insgesamt völlig korrekt war, von optionalem externem Code im Kernel abhängig, für den andere Personen verantwortlich sind.
Die Ablehnung, den Binding-Code für DMA-Aufrufe zu akzeptieren, stellte die Entwickler des Projekts Rust for Linux vor eine Herausforderung, da ohne solche Bindings die Entwicklung vollständiger Treiber in Rust erschwert wird. Hector Martin, Wartungsleiter des Codes zur Unterstützung von ARM-Chips von Apple und Leiter des Projekts Ashai Linux, schlug als Lösung des Konflikts vor, die Bindings direkt über Linus Torvalds zu akzeptieren, um den Begleiter des DMA-Subsystems zu umgehen. Wenn Linus einer solchen Verletzung der Hierarchie und der bestehenden Praxis zustimmt, könnte dies zu einer Krise im Management der Kernel-Entwicklung führen; falls er ablehnt, würde dies das Fortschreiten von Rust im Kernel stoppen.
Als Option erwähnte Hektor, Christoph zur Verantwortung zu ziehen wegen eines Verstoßes gegen den Verhaltenskodex aufgrund eines Kommentars, in dem Christoph Rust mit einem bösartigen Tumor verglich. Darüber hinaus schrieb Hektor, dass er von all den bürokratischen Hürden müde sei, nicht bereit sei, einfach den etablierten Prozessen zu vertrauen und deutete auf die Einbeziehung sozialer Netzwerke hin. Dave Airlie, der Maintainer des DRM-Subsystems, riet davon ab, den Konflikt weiter anzufeuern, und betonte, dass toxisches Verhalten von beiden Seiten inakzeptabel sei, unabhängig davon, ob der Diskussionsbeitrag recht oder unrecht hat.
Linus Torvalds beteiligte sich an der Diskussion und wies darauf hin, dass das Problem möglicherweise bei Hektor selbst und seiner Selbstsicherheit liegt, dass er etwas besser wisse als andere und nicht beim aktuellen Kernel-Entwicklungsprozess, der funktioniert. Der Kernel-Entwicklungsprozess hat seine Probleme, aber das ist die Lebensrealität – es gibt nichts Perfektes im Leben. Versuche, über soziale Netzwerke Mobbing zu betreiben, schrecken Linus von einer Zusammenarbeit mit Hektor ab. Linus legt Wert auf technische Diskussionen und Patches, nicht auf Druck über soziale Netzwerke.
Als Antwort beantragte Hektor, sich von den Maintainer der ARM/APPLE-Plattform zu entfernen, da er das Vertrauen in den im Kernel angewandten Entwicklungsprozess und das Community-Management verloren hatte. Er erklärte außerdem, dass die Entwicklung der ARM/Apple Plattform außerhalb des Haupt-Kernels von Linux fortgesetzt werden würde. Im Kernel bleibt ein weiterer Maintainer für die ARM/Apple Plattform – Sven Peter, der die Unterstützung der Plattform im Kernel fortsetzen möchte.
Quelle: opennet.ru
