Christoph Hellwig, responsabile della manutenzione dei sottosistemi DMA, KVM, Slab Allocator e dell'architettura PowerPC nel kernel. Linux, che in passato è stato membro del comitato di gestione tecnica dell'organizzazione Linux La Foundation, parte ricorrente in una causa relativa alla licenza GPL contro VMware, si è rifiutata di approvare le patch relative al supporto dello sviluppo di driver Rust. Le patch proposte aggiungevano wrapper per diverse funzioni del sottosistema DMA, consentendo l'utilizzo del DMA nei driver Rust.
Le motivazioni addotte per il rifiuto sono state la maggiore complessità della manutenzione del codice in presenza di binding in altri linguaggi e la volontà di preservare le interfacce software verso DMA in una forma leggibile nel linguaggio C, senza che siano distribuite su binding incomprensibili. Christophe ha proposto di accedere direttamente all'API C DMA nativa in ogni driver Rust, in modo da non creare ulteriori astrazioni da cui i manutentori del kernel avrebbero dovuto dipendere.
I manutentori delle patch hanno indicato che si sarebbero occupati personalmente di tutta la manutenzione del codice Rust, erano disposti a mantenere queste patch da soli e hanno spostato i binding in una sottocartella separata (rust/kernel/dma.rs). In risposta, Christoph ha posto il veto ("Nacked-by") all'accettazione delle patch relative a Rust e ha indicato che non aveva bisogno di un altro manutentore. Christoph ha affermato che se gli sviluppatori dei binding volevano renderlo non manutenibile, Linux A causa della combinazione di più linguaggi in un'unica base di codice, dovrebbero risolvere questo problema nel driver anziché diffondere questa piaga nei sottosistemi del kernel.
Allo stesso tempo, Christoph ha chiarito che non ha nulla contro il linguaggio Rust e che lo considera uno dei migliori nuovi linguaggi, ma è contrario a mescolare codice proveniente da linguaggi diversi. Christoph è favorevole alla creazione di nuovi progetti in Rust, ma è contrario alla miscelazione di Rust in grandi basi di codice C, poiché tale miscelazione riduce notevolmente la manutenibilità del kernel come progetto integrato.
Il nocciolo del problema di manutenibilità è che i binding Rust rendono i manutentori dipendenti dal codice Rust. A prima vista, sembra che i binding siano solo componenti aggiuntivi per strutture e funzioni C che non influenzano in alcun modo lo sviluppo e la manutenzione del codice C. Ma non è così. In presenza di tali associazioni, gli sviluppatori di sottosistemi scritti in C devono tenere conto dell'impatto delle modifiche sulla continua funzionalità delle associazioni. Qualsiasi modifica alle strutture dati o alle funzioni interne in C potrebbe richiedere modifiche al codice di binding, pertanto le modifiche al codice C che incidono sul binding devono essere tracciate e sincronizzate con il codice Rust. Molti manutentori non sono disposti ad assumersi la responsabilità aggiuntiva di risolvere i problemi che si presentano nel codice Rust e non sono disposti a dedicare tempo al monitoraggio dello stato dei binding Rust.
La situazione relativa alla complicazione del supporto non è speculativa. Jason Gunthorpe, responsabile di TPM, VFIO e Infiniband di NVIDIA, si è unito alla discussione e ha fatto l'esempio di Linus Torvalds che ha rifiutato una richiesta pull con modifiche al sottosistema di gestione della memoria, poiché questa modifica ha causato un errore nel tentativo di compilare il kernel con il supporto Rust abilitato. L'arresto anomalo si è verificato perché i responsabili del codice Rust non sono riusciti ad apportare le modifiche necessarie al bindgen. Pertanto, i responsabili del sottosistema di gestione della memoria, nel promuovere una modifica del tutto corretta dal punto di vista del codice C e del kernel nel suo complesso, si sono trovati a dipendere da codice di terze parti opzionale nel kernel, la cui responsabilità spetta ad altre persone.
Il rifiuto di accettare il codice di binding tramite chiamate DMA ha messo gli sviluppatori del progetto Rust per Linux Questa è una strada senza uscita, poiché senza tali binding, sviluppare driver completi in Rust sarà difficile. Hector Martin, manutentore del codice a supporto dei chip ARM di Apple e leader del progetto Ashai LinuxCome soluzione al conflitto, ha proposto di cercare l'adozione diretta del binding tramite Linus Torvalds, bypassando il manutentore del sottosistema DMA. Se Linus accettasse tale violazione della catena di comando e delle prassi consolidate, ciò potrebbe portare a una crisi nella gestione dello sviluppo del kernel, mentre se rifiutasse, bloccherebbe l'integrazione di Rust nel kernel.
In alternativa, Hector ha affermato che Christophe sarebbe stato ritenuto responsabile per aver violato il codice di condotta a causa di un commento in cui paragonava Rust a un tumore canceroso. Hector ha inoltre scritto di essere stanco di tutta la burocrazia, di non essere pronto ad affidarsi semplicemente ai processi stabiliti e ha accennato al coinvolgimento dei social network. Dave Airlie, responsabile del sottosistema DRM, ha sconsigliato di inasprire il conflitto e di comprendere che un comportamento tossico è inaccettabile da entrambe le parti, indipendentemente dal fatto che il partecipante alla discussione abbia ragione o torto.
Linus Torvalds si è unito alla discussione e ha sottolineato che il problema potrebbe essere lo stesso Hector e la sua eccessiva sicurezza di sapere qualcosa meglio degli altri, e non l'attuale processo di sviluppo del kernel che sta funzionando. Il processo di sviluppo del kernel ha i suoi problemi, ma questa è la realtà della vita: niente nella vita è perfetto. I tentativi di bullismo sui social media sono ciò che scoraggia Linus dall'avere a che fare con l'approccio di Hector. Ciò che conta per Linus sono le discussioni tecniche e le patch, non la pressione dei social media.
In risposta, Hector ha presentato una richiesta di rimozione dal gruppo dei manutentori della piattaforma ARM/APPLE, poiché aveva perso fiducia nel processo di sviluppo del kernel e nell'approccio alla gestione della community. Ha inoltre affermato che lo sviluppo della piattaforma ARM/Apple sarebbe continuato al di fuori del kernel principale. LinuxLa piattaforma ARM/Apple ha ancora un responsabile del kernel, Sven Peter, che intende continuare a supportare la piattaforma all'interno del kernel.
Fonte: opennet.ru
