Christoph Hellwig, maintainer dei sottosistemi DMA, KVM, Slab Allocator e dell'architettura PowerPC nel kernel Linux, che in passato ha fatto parte del comitato tecnico dell'organizzazione Linux Foundation e ha agito come querelante in una causa legale legata alla GPL contro VMware, ha rifiutato di approvare le patch relative al supporto dello sviluppo di driver in Rust. Le patch proposte aggiungevano dei wrapper su diverse funzioni del sottosistema DMA, consentendo l'uso del DMA nei driver scritti in Rust. <\/p>\n
Come motivo del rifiuto \u00e8 stata citata la complessit\u00e0 della manutenzione del codice con la presenza di wrapper in altri linguaggi e la volont\u00e0 di mantenere le interfacce software per il DMA leggibili in C, senza confusione dovuta a wrapper poco chiari. Christoph ha suggerito di accedere direttamente all'API DMA in C in ogni driver scritto in Rust, per evitare di creare ulteriori astrazioni da cui i manutentori del kernel dovrebbero dipendere. <\/p>\n
I sviluppatori dei patch hanno dichiarato che si occuperanno di tutta la manutenzione del codice Rust, pronti a gestire questi patch autonomamente e hanno spostato i wrapper in una sottocartella separata (rust\/kernel\/dma.rs). In risposta, Christoph ha posto un veto («Nacked-by») all'accettazione dei patch relativi a Rust e ha indicato che non ha bisogno di un ulteriore manutentore. Christoph ha affermato che se gli sviluppatori dei wrapper vogliono rendere impossibile la manutenzione di Linux a causa della mescolanza di pi\u00f9 lingue in un unico codice, dovrebbero farlo nel proprio driver e non diffondere questa piaga alle principali sottosistemi del kernel. <\/p>\n
Inoltre, Christoph ha precisato che non ha nulla contro il linguaggio Rust e lo considera uno dei migliori nuovi linguaggi, ma \u00e8 contrario alla miscelazione di codice in diverse lingue. Secondo Christoph, \u00e8 favorevole alla creazione di nuovi progetti in Rust, ma contrario all'inserimento di Rust in grandi basi di codice in C, poich\u00e9 tale miscelazione riduce notevolmente la facilita di manutenzione del kernel come progetto integrato. <\/p>\n
La questione principale dei problemi di mantenimento \u00e8 che i wrapper Rust creano una dipendenza dai codici scritti in Rust. A prima vista, sembra che i wrapper siano solo sovrastrutture su strutture e funzioni C, le quali non influenzano lo sviluppo e il mantenimento del codice C. Ma non \u00e8 cos\u00ec. Con la presenza di tali wrapper, gli sviluppatori dei sottosistemi scritti in C devono considerare come le loro modifiche possano influenzare la funzionalit\u00e0 dei wrapper. Qualsiasi cambiamento nelle strutture dati o nelle funzioni interne di C potrebbe richiedere modifiche nel codice dei wrapper, quindi i cambiamenti pertinenti nel codice C devono essere monitorati e sincronizzati con il codice Rust. Molti manutentori non sono pronti ad assumersi la responsabilit\u00e0 aggiuntiva per la risoluzione dei problemi presenti nel codice Rust, e non intendono dedicare il loro tempo a monitorare lo stato dei wrapper Rust. <\/p>\n
La situazione complicata per il supporto non \u00e8 teorica. Alla discussione si \u00e8 unito Jason Gunthorpe, maintainer di TPM, VFIO e Infiniband presso NVIDIA, il quale ha citato l'esempio del rifiuto da parte di Linus Torvalds di una pull request contenente modifiche al sottogruppo di gestione della memoria, poich\u00e9 tale modifica causava un errore durante il tentativo di compilazione del kernel con il supporto per Rust. L'errore si \u00e8 verificato perch\u00e9 i manutentori del codice in Rust non hanno apportato le modifiche necessarie al generatore di binding (bindgen). Pertanto, i manutentori del sottosistema di gestione della memoria, mentre promuovevano una modifica completamente corretta dal punto di vista del codice C e del kernel nel suo insieme, si sono trovati a dipendere da codice opzionale di terze parti nel kernel, di cui si occupano altre persone. <\/p>\n
Il rifiuto di accettare il codice dei wrapper sulle chiamate DMA ha messo in stallo gli sviluppatori del progetto Rust for Linux, poich\u00e9 senza tali wrapper sar\u00e0 difficile sviluppare driver completi in Rust. Hector Martin, manutentore del codice per il supporto dei chip ARM di Apple e leader del progetto Ashai Linux, come opzione per risolvere il conflitto ha suggerito di cercare di ottenere l'accettazione del wrapper direttamente da Linus Torvalds, bypassando il manutentore della sottosistema DMA. Se Linus accettasse una tale violazione della subordinazione e delle pratiche consolidate, ci\u00f2 potrebbe portare a una crisi di gestione dello sviluppo del kernel, e se rifiutasse, fermerebbe i progressi di Rust nel kernel. <\/p>\n
Come alternativa, Hector ha menzionato di voler responsabilizzare Christophe per la violazione del codice di comportamento a causa di un commento in cui Christophe ha paragonato Rust a un tumore maligno. Inoltre, Hector ha scritto di essere stanco di tutte le burocrazie e di non essere pronto a fidarsi dei processi consolidati, suggerendo un coinvolgimento dei social media. Dave Airlie, mantenitore del sottosistema DRM, ha consigliato di non esagerare il conflitto e di comprendere che comportamenti tossici non sono accettabili da entrambe le parti, indipendentemente dal fatto che il partecipante alla discussione abbia ragione o meno. <\/p>\n
Linus Torvalds si \u00e8 unito alla discussione, indicando che il problema potrebbe risiedere nello stesso Hector e nella sua sicurezza di sapere qualcosa di meglio rispetto agli altri, piuttosto che nel processo attuale di sviluppo del kernel, che funziona. Il processo di sviluppo del kernel presenta delle problematiche, ma questa \u00e8 la realt\u00e0 della vita \u2014 non c'\u00e8 nulla di perfetto. I tentativi di attacco attraverso i social media sono ci\u00f2 che scoraggia Linus dal voler avere rapporti con l'approccio di Hector. Per Linus, \u00e8 importante il dibattito tecnico e i patch, non la pressione esercitata attraverso i social media. <\/p>\n