Jockey

Jockey ist ein Werkzeug für die Installation von Drittanbieter-Hardware-Treiber.
Jockey stellt die Infrastruktur und die Benutzerschnittstelle für die Suche und Installation von Treiber von Drittanbietern, die für den Computer sind. Dies umfasst Treiber, die hinzugefügt oder nach der Veröffentlichung von einer Ausschüttung oder Treiber, die nicht in die Verteilung aus verschiedenen Gründen (CD Raumbegrenzung, Lizenzprobleme, etc.) enthalten sein können aktualisiert werden.
Eine gemeinsame Nutzung Fall ist mit einer benutzerfreundlichen und halbautomatischen Weg, um Treiber für neue Hardware, die die Stromverteilung Release noch nicht unterstützt, oder installieren Nvidia und ATI fglrx X.org-Treiber zu installieren.
Jockey wurde entworfen, um Verteilung agnostisch sein und erfüllen die Notwendigkeit der verschiedenen Distributionen, Treiber-Anbieter und Systemintegratoren. Es wurde entwickelt und im Rahmen der Linuxfoundation Fahrer backports Arbeitsgruppe entwickelt.
Betrieb
Beim Start versucht der Jockey-Backend des Systems zur Verfügung stehenden Hardware. Dies kann auf verschiedene Weise geschehen, ist & nbsp derzeit implementiert ist; Scannen / sys für modaliases. In Zukunft ist geplant, weitere Methoden, wie die Abfrage Tassen für erkannten Drucker, die nicht einen Treiber & nbsp haben hinzuzufügen. Nachweismethoden wird als Komponente von Anbieter und Distributionen Bedarf hinzugefügt werden. Die Menge der zur Verfügung stehenden Hardware wird als "HardwareID" Objekten (was alles, was ein Stück Hardware, wie beispielsweise ein Verkäufer / Produkt-ID, einem modalias oder einem Drucker Identifikationsstring identifiziert eindeutig darstellen kann) vertreten.
Für jede Hardware-ID, ein Satz von Fahrer-Datenbanken (Instanzen DriverDB) zum verfügbaren Treiber abgefragt. Im Moment ist die einzige vorhandene Implementierung LocalKernelModulesDriverDB, die die Standard-Linux-Kernel modules.alias Karten nutzt, um modaliases für Kernel-Module zuordnen. In naher Zukunft planen wir eine weitere Implementierung, die einen Online-Treiberdatenbank sowie Abfragen hinzufügen. Die DriverDBs verwandeln den Satz HardwareIDs auf einen Satz von DriverIDs.
A DriverID stellt alle notwendigen Metadaten über einen Fahrer, wie zB:
* Treiber-Klasse (Kernel-Modul, Druckertreiber, Paket, X.org-Grafiktreiber, Firmware, etc.)
* Handler Klassennamen (siehe unten)
* Position des Treibers (Repository, Paketname, möglicherweise SHA1 und andere Prüfsummen, Signaturen)
* Fahrer spezifische Parameter (beliebige Typ / Wert-Paare, die der Handler versteht)
Alle Fahrer von Jockey gehandhabt müssen durch eine Unterklasse von "Handler" verkapselt werden. Ein Handler-Instanz stellt einen Hook für beliebigen Code, der um einen Treiber vollständig zu installieren muss. Jockey bietet bereits Handler-Implementierungen für gemeinsamen Fällen wie Kernel-Module, Kernel-Modul-Firmware, X.org-Treiber, Gruppen von Treibern usw. Die überwiegende Mehrheit der Fahrer parametriert Instanzen dieser Standard-Handler verwenden, aber Treiber, die einige anspruchsvollere lokalen benötigen Konfiguration kann eigene Handler-Unterklasse zu versenden, und fügen Sie den erforderlichen Code.
Struktur
Der Großteil der Jockey Arbeit (Hardware-Erkennung, Treiber-Datenbankabfragen, Paketinstallation, etc.) wird von einem unabhängigen UI-Backend, die über das System D-BUS seine Funktionalität bietet getan. Der Zugang wird durch PolicyKit Privilegien gesteuert (siehe backend / com.ubuntu.devicedriver.policy.in für Details); Standardmäßig können alle Benutzer lokale Gerätetreiber Statusabfragen zu tun, können alle lokalen Benutzer eine Remote-Treiberdatenbankabfrage auslösen, und tatsächlich Ein- / Ausbau-Treiber ist für Systemadministratoren beschränkt.
Die verschiedenen Benutzerschnittstellen (GTK und KDE, und beide bieten eine CLI auch) mit normalen Benutzerrechten laufen und nur eine menschliche freundlich und internationalisiert Präsentation / UI der Backend-Services. Sie enthalten keine Treiberlogik.
Die Anpassung Jockey auf eine Linux-Distribution,
Jockey wird sorgfältig geschrieben, um nicht spezifisch für jede Linux-Distribution sein. Alle OS / Distribution spezifische Operationen werden in der "OSLib" Klasse, die Unterklasse und durch die Linux-Distributionen umgesetzt werden muss gekapselt. Die meisten Methoden haben bereits eine vernünftige Default-Implementierung vorgeschalteten, aber einige sind einfach von Natur aus bestimmte Distribution (Suchen nach "NotImplementedError" für diejenigen zu finden).
Dies minimiert die Portierungsbemühungen der Händler unter Beibehaltung der Möglichkeit, Anpassungen an einem zentralen Ort zu machen.
Die abstrakte OSLib Klasse wird sorgfältig dokumentiert, und es existiert bereits ein Zweig für Ubuntu [3], und der Test-Suite verfügt über eine Dummy-Implementierung (siehe Tests / sandbox.py). Dies sollte ausreichen, um Jockey für andere Distributionen als auch umzusetzen

Was ist neu in dieser Pressemitteilung:.

• Diese Version behebt ein Tonnen von Bugs, darunter alle diejenigen, die derzeit als Blocker für die endgültige Release 0.5 ausgewählt werden.
• Es muss nicht neue Features.

Was ist neu in Version 0.5 Alpha 1:

• Das ist die erste Vorschau auf die kommende Release 0.5 die in großem Design Überholung konzentriert sich um die Übertragbarkeit, die Unterstützung von Druckererkennung, Druckertreiber von openprinting.org, eine D-Bus-Schnittstelle für Treibersuche für Desktop-Anwendungen und ein renoviertes GTK Benutzeroberfläche zu verbessern.