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\u00e4ger in einem mit der GPL verbundenen Rechtsstreit gegen VMware, weigerte sich, Patches zu best\u00e4tigen, die die Entwicklung von Treibern in der Programmiersprache Rust unterst\u00fctzen. Die vorgeschlagenen Patches f\u00fcgte Wrapper \u00fcber mehrere Funktionen des DMA-Subsystems hinzu, die die Verwendung von DMA in Treibern in der Programmiersprache Rust erm\u00f6glichen sollten. <\/p>\n
Als Grund f\u00fcr die Ablehnung wurde die Komplexit\u00e4t der Wartung des Codes bei Vorhandensein von Wrappern in anderen Sprachen sowie das Bestreben erw\u00e4hnt, die Programmierschnittstellen zu DMA in lesbarem C-Format zu erhalten, ohne sie durch unverst\u00e4ndliche Wrapper zu verw\u00e4ssern. Christoph schlug vor, direkt auf die urspr\u00fcngliche C-DMA-API in jedem Treiber in Rust zuzugreifen, um keine zus\u00e4tzlichen Abstraktionen zu schaffen, von denen die Kernel-Wartenden abh\u00e4ngig w\u00e4ren. <\/p>\n
Die Entwickler der Treiber haben angegeben, dass sie die gesamte Arbeit zur Wartung des Codes in Rust \u00fcbernehmen werden, bereit sind, diese Patches eigenst\u00e4ndig zu betreuen, und die Wrapper in ein separates Unterverzeichnis (rust\/kernel\/dma.rs) ausgelagert haben. Als Antwort legte Christoph ein Veto (\u201eNacked-by\u201c) gegen die Annahme der mit Rust verbundenen Patches ein und erkl\u00e4rte, dass er keinen weiteren Betreuer ben\u00f6tige. Christoph erkl\u00e4rte, dass, wenn die Entwickler der Wrapper die Unm\u00f6glichkeit einer Unterst\u00fctzung von Linux durch das Mischen mehrerer Sprachen in einer Codebasis erreichen wollen, sie dies in ihrem Treiber tun sollten und nicht diese Krebsmetastase auf die Hauptkernsubsysteme ausbreiten sollten. <\/p>\n
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\u00fcr die Schaffung neuer Projekte in Rust ein, ist jedoch gegen die Vermischung von Rust in gro\u00dfen C-Codebasen, da diese Vermischung die Wartung des Kernels als integriertes Projekt erheblich erschwert. <\/p>\n
Der Kern der Probleme mit der Begleitung liegt darin, dass Rust-Bindings die Begleitperson von dem Code in Rust abh\u00e4ngig machen. Auf den ersten Blick scheint es, dass die Bindings nur Erg\u00e4nzungen 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\u00fcssen Entwickler von Subsystemen, die in C geschrieben sind, die Auswirkungen ihrer \u00c4nderungen auf die Funktionsf\u00e4higkeit der Bindings ber\u00fccksichtigen. Jede \u00c4nderung der Datenstrukturen oder internen Funktionen in C kann die Notwendigkeit zur \u00c4nderung des Binding-Codes hervorrufen, daher m\u00fcssen \u00c4nderungen am C-Code, die die Bindings betreffen, verfolgt und mit dem Rust-Code synchronisiert werden. Viele Begleiter sind nicht bereit, die zus\u00e4tzliche Verantwortung f\u00fcr die Behebung von Problemen, die im Rust-Code auftreten, zu \u00fcbernehmen, und beabsichtigen nicht, ihre Zeit mit der Verfolgung des Status der Rust-Bindings zu verbringen. <\/p>\n
Die Situation mit der Komplexit\u00e4t der Begleitung ist nicht theoretisch. An der Diskussion beteiligte sich Jason Gunthorpe, Wartungsleiter von TPM, VFIO und Infiniband bei NVIDIA, der ein Beispiel f\u00fcr die Ablehnung eines Pull-Requests von Linus Torvalds anf\u00fchrte, der \u00c4nderungen im Subsystem zur Speicherverwaltung enthielt, da diese \u00c4nderung zu einem Fehler beim Versuch f\u00fchrte, den Kernel mit Rust-Unterst\u00fctzung zu kompilieren. Der Fehler trat auf, weil die Begleiter des Rust-Codes die notwendigen \u00c4nderungen nicht in den Binding-Generator (bindgen) eingef\u00fcgt hatten. Damit waren die Begleiter des Subsystems zur Speicherverwaltung bei der F\u00f6rderung einer \u00c4nderung, die aus Sicht des C-Codes und des Kernels insgesamt v\u00f6llig korrekt war, von optionalem externem Code im Kernel abh\u00e4ngig, f\u00fcr den andere Personen verantwortlich sind. <\/p>\n
Die Weigerung, den Wrapper-Code \u00fcber die DMA-Aufrufe anzunehmen, stellte die Entwickler des Projekts Rust for Linux vor ein Dilemma, da ohne solche Wrapper die Entwicklung vollst\u00e4ndiger Treiber in Rust erschwert werden w\u00fcrde. Hector Martin, Maintainer des Codes zur Unterst\u00fctzung der ARM-Chips von Apple und Leiter des Projekts Ashai Linux, schlug als L\u00f6sung des Konflikts vor, die Annahme des Wrappers direkt \u00fcber Linus Torvalds zu erreichen, um den Betreuer des DMA-Subsystems zu umgehen. Sollte Linus einer solchen Verletzung der Hierarchie und der bestehenden Praxis zustimmen, k\u00f6nnte dies zu einer Managementkrise in der Kernel-Entwicklung f\u00fchren; wenn er ablehnt, wird dies den Fortschritt von Rust im Kernel stoppen. <\/p>\n
Als Option erw\u00e4hnte Hektor, Christoph zur Verantwortung zu ziehen wegen eines Versto\u00dfes gegen den Verhaltenskodex aufgrund eines Kommentars, in dem Christoph Rust mit einem b\u00f6sartigen Tumor verglich. Dar\u00fcber hinaus schrieb Hektor, dass er von all den b\u00fcrokratischen H\u00fcrden m\u00fcde 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\u00e4ngig davon, ob der Diskussionsbeitrag recht oder unrecht hat. <\/p>\n
Linus Torvalds beteiligte sich an der Diskussion und wies darauf hin, dass das Problem m\u00f6glicherweise bei Hector selbst und seinem Selbstvertrauen liegt, dass er etwas besser wei\u00df als andere, 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 Druck auszu\u00fcben, sind das, was Linus den Wunsch nimmt, sich mit Hectors Ansatz gemein zu machen. Linus sch\u00e4tzt technische Diskussionen und Patches, nicht Druckaus\u00fcbung \u00fcber soziale Netzwerke. <\/p>\n