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.
Tra le motivazioni del rifiuto è stata citata la complessità nella manutenzione del codice in presenza di wrapper in altri linguaggi e la volontà 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.
Gli sviluppatori delle patch hanno dichiarato che si sarebbero assunti tutto il lavoro di manutenzione del codice in Rust, sono pronti a mantenere queste patch autonomamente e hanno spostato i wrapper in una sotto-cartella separata (rust/kernel/dma.rs). In risposta, Christoph ha posto il veto ('Nacked-by') all'accettazione delle patch relative a Rust, sostenendo di non aver 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ù linguaggi in un'unica base di codice, dovrebbero farlo nei loro driver e non diffondere questo cancro ai sottomoduli principali del kernel.
Inoltre, Christoph ha specificato di non avere nulla contro il linguaggio Rust e lo considera uno dei migliori linguaggi nuovi, ma è contrario alla mescolanza di codice in linguaggi diversi. Secondo Christoph, supporta la creazione di nuovi progetti in Rust, ma è contrario a mescolare Rust con ampie basi di codice in C, poiché tale mescolanza riduce significativamente la facilità di manutenzione del kernel, considerato un progetto integrato.
La questione dei problemi con il supporto è 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 è così. 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ò portare alla necessità 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à aggiuntiva di risolvere i problemi che sorgono nel codice in Rust e non intendono dedicare tempo al monitoraggio dello stato dei wrapper Rust.
La situazione riguardo alla complessità del supporto non è teorica. Alla discussione si è 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é tale modifica portava a un crash durante il tentativo di compilare il kernel con il supporto per Rust. Il crash è avvenuto perché i manutentori del codice in Rust non hanno aggiunto le modifiche necessarie al generatore di wrapper (bindgen). Così, 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.
Il rifiuto di accettare il codice wrapper per le chiamate DMA ha messo in difficoltà gli sviluppatori del progetto Rust for Linux, poiché senza tali wrapper lo sviluppo di driver completi in linguaggio Rust sarà complicato. Hector Martin, manutentore del codice per il supporto dei chip ARM Apple e leader del progetto Ashai Linux, ha suggerito come soluzione al conflitto di cercare di ottenere l'accettazione del wrapper direttamente tramite Linus Torvalds, bypassando il manutentore del sottosistema DMA. Se Linus accettasse una tale violazione della subordinazione e della prassi consolidata, ciò potrebbe portare a una crisi di gestione dello sviluppo del kernel, e se rifiutasse, fermerebbe l'avanzamento di Rust nel kernel.
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 è inaccettabile da entrambe le parti, indipendentemente da chi abbia ragione o torto nella discussione.
Alla discussione si è unito Linus Torvalds, che ha indicato che il problema potrebbe risiedere in Hector e nella sua eccessiva fiducia nel sapere qualcosa meglio degli altri, e non nel processo attuale di sviluppo del kernel, che funziona. Il processo di sviluppo del kernel ha le sue problematiche, ma questa è la realtà della vita: non esiste nulla di perfetto. I tentativi di mobbing attraverso i social media sono ciò che scoraggia Linus dall'avere qualsiasi cosa a che fare con l'approccio di Hector. Ciò che conta per Linus 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 gruppo di maintainer della piattaforma ARM/APPLE, poiché ha perso fiducia nel processo di sviluppo applicato nel kernel 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 un altro maintainer per la piattaforma ARM/Apple nel kernel: Sven Peter, che ha intenzione di continuare a mantenere la piattaforma nel kernel.
Fonte: opennet.ru
