Immagina che ci sia una società A che rilascia una nuova scheda grafica. Chi gestisce il processo che porterà in futuro a questa nuova scheda grafica supportata dal kernel Linux? Come procede? Sono curioso di sapere come viene gestito il supporto del kernel per ogni nuovo hardware; su aziende Windows sviluppano i driver da soli, ma in che modo Linux ottiene supporto hardware specifico?
Risposte:
Il supporto driver funziona allo stesso modo di tutto l'open source: qualcuno decide di grattarsi il prurito.
A volte il driver viene fornito dalla società che fornisce l'hardware, proprio come su Windows. Intel lo fa per i suoi chip di rete, 3ware lo fa per i suoi controller RAID, ecc. Queste aziende hanno deciso che è nel loro interesse fornire il driver: il loro "prurito" è vendere prodotti agli utenti Linux, e ciò significa garantire che c'è un autista.
Nel migliore dei casi, la società lavora sodo per portare il proprio driver nella base di origine appropriata fornita con distribuzioni Linux. Per la maggior parte dei driver, ciò significa che il kernel Linux. Per i driver di grafica, significa X.org . Ci sono anche CUPS per driver di stampa, NUT per driver di UPS, SANE per driver di scanner, ecc. Il vantaggio evidente di questo è che le distro Linux fatte dopo l'accettazione del driver avranno il supporto per l'hardware pronto all'uso. Il più grande svantaggio è che è più lavoro per l'azienda coordinarsi con il progetto open source per ottenere il proprio driver, per gli stessi motivi di base è difficile per due gruppi separati coordinare qualsiasi cosa.
Quindi ci sono quelle aziende che scelgono di offrire direttamente il loro codice sorgente del driver. In genere è necessario scaricare il codice sorgente del driver dal proprio sito Web, crearlo sul proprio sistema e installarlo manualmente. Tali aziende sono di solito produttori più piccoli o specializzati senza un numero sufficiente di dipendenti che possono risparmiare gli sforzi per coordinarsi con il progetto open source appropriato per ottenere il loro driver nella base di origine del progetto.
Alcune rare aziende forniscono driver solo binari anziché codice sorgente. Un esempio sono i driver 3D più avanzati di aziende come NVIDIA. In genere la ragione di ciò è che la società non vuole fornire informazioni di cui si sente proprietaria. Spesso questi driver non funzionano con tante distro Linux come nei casi precedenti, perché la società che fornisce l'hardware non si preoccupa di ricostruire il proprio driver per tenere traccia delle modifiche API e ABI. È possibile che l'utente finale o il fornitore di distro Linux modifichino un driver fornito come codice sorgente per tenere traccia di tali modifiche, quindi nei due casi precedenti è possibile far funzionare il driver con più sistemi di quanto non faccia un driver binario.
Quando la società non fornisce driver Linux, qualcuno nella comunità decide semplicemente di farlo. Ci sono alcune grandi classi di hardware dove questo è comune, come con UPS e stampanti. Ci vuole un utente raro che a) abbia l'hardware; b) ha il tempo; c) ha l'abilità; e d) ha la tendenza a dedicare del tempo allo sviluppo del conducente. Per l'hardware popolare, questo di solito non è un problema perché con milioni di utenti Linux, queste poche persone esistono. Ti trovi nei guai con hardware non comune.
Per capirlo in dettaglio, recentemente Raspberry Pi 3 è uscito e ha aggiunto il chip bluetooth. Questo è un chip Broadcom BLE e il kernel Raspberry Pi non ha il supporto per esso, quindi la bluezlibreria per Linux non funziona. Ora idealmente, si dovrebbe avere la patch del firmware per quel chip BLE e sarà necessario compilare nuovamente il kernel per renderlo disponibile per l'utente. È giusto?