Christoph Hellwig, maintainer dei sottomoduli DMA, KVM, Slab Allocator e dell'architettura PowerPC nel kernel Linux, che in passato ha fatto parte del comitato tecnico direttivo della Linux Foundation e ha agito come attore in una causa legale relativa alla GPL contro VMware, ha rifiutato di confermare le patch riguardanti il supporto dello sviluppo di driver in linguaggio Rust. Le patch proposte aggiungevano dei wrapper su diverse funzioni del sottomodulo DMA, permettendo di utilizzare DMA nei driver scritti in Rust. <\/p>\n
Tra le motivazioni del rifiuto \u00e8 stata citata la complessit\u00e0 nella manutenzione del codice in presenza di wrapper in altri linguaggi e la volont\u00e0 di mantenere le interfacce di programmazione per DMA in un formato leggibile in linguaggio C, senza sfumature in wrapper poco chiari. Christoph ha proposto di accedere direttamente all'API C originale di DMA in ogni driver in Rust, per evitare di creare ulteriori astrazioni dalle quali i manutentori del kernel sarebbero costretti a dipendere. <\/p>\n
Gli sviluppatori dei driver hanno dichiarato che si occuperanno di tutto il lavoro di supporto per il codice Rust, pronti a gestire questi pacchetti autonomamente e hanno spostato i wrapper in una sottocartella separata (rust\/kernel\/dma.rs). In risposta, Christoph ha posto il veto (\"Nacked-by\") all'accettazione dei pacchetti relativi a Rust e ha indicato che non desidera un ulteriore manutentore. Christoph ha affermato che se gli sviluppatori dei wrapper vogliono rendere impossibile il supporto di Linux a causa della mescolanza di pi\u00f9 linguaggi in un unico codice, dovrebbero farlo nel loro driver, piuttosto che diffondere questo cancro nei sottosistemi principali del kernel. <\/p>\n
Inoltre, Christoph ha specificato di non avere nulla contro il linguaggio Rust e lo considera uno dei migliori linguaggi nuovi, ma \u00e8 contrario alla mescolanza di codice in linguaggi diversi. Secondo Christoph, supporta la creazione di nuovi progetti in Rust, ma \u00e8 contrario a mescolare Rust con ampie basi di codice in C, poich\u00e9 tale mescolanza riduce significativamente la facilit\u00e0 di manutenzione del kernel, considerato un progetto integrato. <\/p>\n
La questione dei problemi con il supporto \u00e8 che i wrapper Rust pongono i manutentori in dipendenza dal codice in linguaggio Rust. A prima vista, sembra che i wrapper siano solo sovrastrutture su strutture e funzioni in C, che non influenzano in alcun modo lo sviluppo e il supporto del codice in C. Ma non \u00e8 cos\u00ec. In presenza di tali wrapper, gli sviluppatori dei sottosistemi scritti in C devono tenere conto dell'impatto delle loro modifiche sul mantenimento del funzionamento dei wrapper. Qualsiasi modifica alle strutture dati o alle funzioni interne in C pu\u00f2 portare alla necessit\u00e0 di modificare il codice dei wrapper, quindi le modifiche che influenzano i wrapper nel codice C devono essere monitorate e sincronizzate con il codice in Rust. Molti manutentori non sono pronti a prendersi la responsabilit\u00e0 aggiuntiva di risolvere i problemi che sorgono nel codice in Rust e non intendono dedicare tempo al monitoraggio dello stato dei wrapper Rust. <\/p>\n
La situazione riguardo alla complessit\u00e0 del supporto non \u00e8 teorica. Alla discussione si \u00e8 unito Jason Gunthorpe, manutentore di TPM, VFIO e Infiniband per NVIDIA, che ha portato l'esempio del rifiuto da parte di Linus Torvalds di una pull request con modifiche al sottosistema di gestione della memoria, poich\u00e9 tale modifica portava a un crash durante il tentativo di compilare il kernel con il supporto per Rust. Il crash \u00e8 avvenuto perch\u00e9 i manutentori del codice in Rust non hanno aggiunto le modifiche necessarie al generatore di wrapper (bindgen). Cos\u00ec, i manutentori del sottosistema di gestione della memoria, nel promuovere una modifica completamente corretta dal punto di vista del codice in C e del kernel in generale, si sono trovati a dipendere da codice di terze parti opzionale nel kernel, per il quale sono responsabili altre persone. <\/p>\n
Il rifiuto di accettare il codice del wrapper attorno alle chiamate DMA ha messo gli sviluppatori del progetto Rust for Linux in una situazione difficile, poich\u00e9 senza tali wrapper lo sviluppo di driver completi in Rust sar\u00e0 complicato. Hector Martin, il maintainer del codice per il supporto dei chip ARM di Apple e leader del progetto Ashai Linux, ha proposto come possibile soluzione al conflitto di ottenere l'accettazione del wrapper direttamente tramite Linus Torvalds, bypassando il manutentore del sottosistema DMA. Se Linus accettasse tale violazione della gerarchia e della prassi stabilita, potrebbe portare a una crisi di gestione dello sviluppo del kernel; ma se rifiutasse, interromperebbe i progressi di Rust nel kernel. <\/p>\n
Come opzione, Hector ha menzionato il coinvolgimento di Christophe per violazione del codice di condotta a causa di un commento in cui Christophe ha paragonato Rust a un tumore canceroso. Inoltre, Hector ha scritto di essere stanco di tutte le complicazioni burocratiche, non pronto a fidarsi semplicemente dei processi esistenti e ha accennato al coinvolgimento dei social media. Dave Airlie, il maintainer del sottosistema DRM, ha consigliato di non gonfiare il conflitto e di capire che il comportamento tossico \u00e8 inaccettabile da entrambe le parti, indipendentemente da chi abbia ragione o torto nella discussione. <\/p>\n
Linus Torvalds \u00e8 intervenuto nella discussione, indicando che il problema potrebbe risiedere nel nativo Hector e nella sua autoassicurazione di sapere qualcosa di meglio degli altri, piuttosto che nel corrente processo di sviluppo del kernel, che in effetti funziona. Il processo di sviluppo del kernel ha dei problemi, ma \u00e8 una realt\u00e0 della vita: nulla \u00e8 perfetto. I tentativi di bullismo sui social media sono ci\u00f2 che scoraggia Linus dal voler avere qualsiasi interazione con l'approccio di Hector. Per Linus, ci\u00f2 che conta sono le discussioni tecniche e i pacchetti, non la pressione esercitata attraverso i social media. <\/p>\n