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.
Come motivo del rifiuto è stata citata la complessità della manutenzione del codice con la presenza di wrapper in altri linguaggi e la volontà 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.
I sviluppatori dei patch hanno affermato che si occuperanno di tutta la manutenzione del codice in 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 il veto («Nacked-by») sull'accettazione dei patch correlati a Rust e ha indicato che non ha bisogno di un ulteriore manutentore. Christoph ha dichiarato che, se gli sviluppatori dei wrapper desiderano rendere impossibile la manutenzione di Linux a causa della miscelazione di più linguaggi in un'unica base di codice, dovrebbero farlo nel proprio driver, piuttosto che diffondere questo tumore nelle sottosistemi principali del kernel.
Inoltre, Christoph ha precisato che non ha nulla contro il linguaggio Rust e lo considera uno dei migliori nuovi linguaggi, ma è contrario alla miscelazione di codice in diverse lingue. Secondo Christoph, è favorevole alla creazione di nuovi progetti in Rust, ma contrario all'inserimento di Rust in grandi basi di codice in C, poiché tale miscelazione riduce notevolmente la facilita di manutenzione del kernel come progetto integrato.
La questione principale dei problemi di mantenimento è 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 è così. Con la presenza di tali wrapper, gli sviluppatori dei sottosistemi scritti in C devono considerare come le loro modifiche possano influenzare la funzionalità 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à aggiuntiva per la risoluzione dei problemi presenti nel codice Rust, e non intendono dedicare il loro tempo a monitorare lo stato dei wrapper Rust.
La situazione complicata per il supporto non è teorica. Alla discussione si è 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é tale modifica causava un errore durante il tentativo di compilazione del kernel con il supporto per Rust. L'errore si è verificato perché 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.
Il rifiuto di accettare il codice di incapsulamento sulle chiamate DMA ha messo in difficoltà gli sviluppatori del progetto Rust for Linux, poiché senza tali incapsulamenti lo sviluppo di driver completi in Rust sarà complicato. Hector Martin, maintainers del codice per il supporto dei chip ARM di Apple e leader del progetto Ashai Linux, ha proposto come soluzione al conflitto di ottenere l'approvazione per l'incapsulamento direttamente da Linus Torvalds, bypassando il mantenitore del sottosistema DMA. Se Linus accettasse una tale violazione della subordinazione e delle pratiche consolidate, ciò potrebbe portare a una crisi di gestione dello sviluppo del kernel, mentre una sua opposizione fermerebbe l'avanzamento di Rust nel kernel.
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.
Alla discussione si è unito Linus Torvalds, il quale ha fatto notare che il problema potrebbe risiedere nello stesso Hector e nella sua sicurezza di sapere qualcosa meglio degli altri, piuttosto che nel processo attuale di sviluppo del kernel, che funziona. Il processo di sviluppo del kernel ha delle problematiche, ma questa è la realtà — nella vita nulla è perfetto. Tentativi di bullismo attraverso i social media sono ciò che allontana Linus dal voler avere qualunque rapporto con l'approccio di Hector. Per Linus, ciò che conta sono le discussioni tecniche e le patch, non la pressione esercitata attraverso i social media.
In risposta, Hector ha inviato una richiesta per essere rimosso dal numero di elementi di supporto della piattaforma ARM/APPLE, poiché ha perso fiducia nel processo di sviluppo e nell'approccio alla gestione della comunità. Ha anche dichiarato che lo sviluppo della piattaforma ARM/Apple continuerà al di fuori del kernel principale di Linux. Rimane ancora un maintainer per la piattaforma ARM/Apple nel kernel: Sven Peter, che intende continuare a mantenere la piattaforma nel kernel.
Fonte: opennet.ru
