Jockey

Jockey è uno strumento per l'installazione di driver hardware di terze parti.
Jockey fornisce l'infrastruttura e l'interfaccia utente per la ricerca e l'installazione di driver di terze parti che sono applicabili al computer. Questo include i driver che vengono aggiunti o aggiornati dopo il rilascio di una distribuzione, o driver, che non può essere incluso nella distribuzione per vari motivi (limitazione spazio CD, problemi di licenza, ecc).
Un caso d'uso comune sta fornendo un modo amichevole e semiautomatica per installare i driver per il nuovo hardware che il rilascio di una distribuzione di corrente non supporta ancora, o installare driver Nvidia e ATI fglrx X.org.
Jockey è stato progettato per essere la distribuzione agnostico e soddisfare le necessità di diverse distribuzioni, fornitori di driver, e system integrator. È stato progettato e sviluppato all'interno del LinuxFoundation backport del driver del gruppo di lavoro.
Operazione
All'avvio, il backend Jockey esplora il sistema per l'hardware a disposizione. Questo può avvenire in diversi modi, attualmente implementato è & nbsp; scansione / sys per modaliases. In futuro si prevede di aggiungere altri metodi, come l'interrogazione di tazze per stampanti rilevate che non hanno un driver. & Nbsp; Saranno aggiunti i metodi di rilevamento, se necessario dai fornitori di componenti e distribuzioni. L'insieme di hardware disponibile è rappresentato come oggetti "HardwareID" (che può rappresentare tutto ciò che identifica in modo univoco un pezzo di hardware, come ad esempio un ID fornitore / prodotto, un modalias, o una stringa di identificazione stampante).
Per ogni ID hardware, un insieme di database di driver (istanze di DriverDB) vengono interrogati per i driver disponibili. Al momento, l'unica implementazione esistente è LocalKernelModulesDriverDB, che utilizza le mappe del kernel modules.alias standard di Linux per mappare modaliases ai moduli del kernel. Nel prossimo futuro abbiamo in programma di aggiungere un'altra implementazione che interroga un database dei driver online. I DriverDBs trasformano il set di HardwareIDs ad un insieme di DriverIDs.
Un DriverID rappresenta tutti i metadati necessarie su un driver, come ad esempio:
* Classe del driver (modulo del kernel, driver di stampa, confezione, X.org driver grafico, firmware, ecc)
* Nome della classe del gestore (vedi sotto)
* Posizione del driver (repository, il nome del pacchetto, forse sha1 e altri checksum, firme)
* parametri specifici driver (coppie di tipo arbitrario / valore che il gestore capisce)
Tutti i driver gestite dal Jockey devono essere incapsulato per una sottoclasse di "gestore". Un'istanza gestore prevede un gancio per codice arbitrario che deve essere eseguito per installare completamente un driver. Jockey fornisce già le implementazioni del gestore per i casi più comuni, quali moduli del kernel, il modulo del kernel del firmware, driver di X.org, gruppi di autisti, ecc La maggior parte dei piloti utilizzeranno esempi con parametri di questi gestori predefiniti, ma i driver che hanno bisogno di un po 'più sofisticati locali configurazione può spedire la propria sottoclasse conduttore e aggiungere il codice necessario.
Struttura
La maggior parte del lavoro di Jockey (rilevamento dell'hardware, le query di database autista, l'installazione dei pacchetti, ecc) è fatto da un backend indipendente, interfaccia utente che fornisce la funzionalità sul sistema D-BUS. L'accesso è controllato da privilegi PolicyKit (vedi backend / com.ubuntu.devicedriver.policy.in per i dettagli); Per impostazione predefinita, tutti gli utenti possono fare domande sullo stato di driver di periferica locali, tutti gli utenti locali possono attivare una query di database dei driver a distanza, e realmente installare / rimuovere i driver è limitato agli amministratori di sistema.
Le diverse interfacce utente (GTK, KDE, ed entrambi forniscono una CLI) eseguiti con normali privilegi utente e solo fornire un amichevole e internazionalizzato presentazione / UI umano dei servizi di back-end. Essi non contengono alcuna logica driver.
Adattarsi Jockey di una distribuzione Linux
Jockey è scritto con cura per non essere specifico per qualsiasi distribuzione Linux. Tutte le operazioni specifiche di OS / distro sono incapsulati nella classe "OSLib", che deve essere sottoclasse e attuato dalle distribuzioni Linux. La maggior parte dei metodi già hanno una implementazione di default ragionevole a monte, ma alcuni sono solo intrinsecamente specifici distro (cercare "NotImplementedError" per trovare quelli).
Questo riduce al minimo gli sforzi porting dei distributori, pur mantenendo la possibilità di apportare modifiche in un unico posto centrale.
La classe OSLib astratta è accuratamente documentato, ed esiste già una filiale per Ubuntu [3], e la suite di test dispone di una implementazione fittizia (vedi test / sandbox.py). Questi dovrebbero essere sufficienti per attuare Jockey per altre distribuzioni, così

Cosa c'è di nuovo in questa versione:.

• Questa versione corregge un tonnellata di bug, tra cui tutti quelli che sono attualmente selezionati come bloccanti per la 0.5 versione finale.
• Non ha nuove funzionalità.

Cosa c'è di nuovo in versione 0.5 Alpha 1:

• Questa è la prima preview del prossimo rilascio 0.5 che si concentra su una grande revisione di design per migliorare la portabilità, il supporto per il rilevamento della stampante, driver di stampa da openprinting.org, un'interfaccia D-BUS per la ricerca del driver per le applicazioni desktop, e una interfaccia utente GTK rinnovato.