Jockey

Jockey est un outil pour l'installation des pilotes matériels tiers.
Jockey fournit l'infrastructure et de l'interface utilisateur pour trouver et installer les pilotes tiers qui sont applicables à l'ordinateur. Cela inclut les pilotes qui sont ajoutés ou mis à jour après la publication d'une distribution, ou pilote qui ne peuvent être inclus dans la distribution pour diverses raisons (limitation de l'espace de CD, des problèmes de licences, etc.).
Un cas d'utilisation commune fournit une manière amicale et semi-automatique pour installer les pilotes pour le nouveau matériel dont la libération de distribution de courant ne supporte pas encore, ou installer des pilotes Nvidia et ATI fglrx X.org.
Jockey a été conçu pour être agnostique et la distribution de satisfaire le besoin de différentes distributions, les vendeurs de conduire et les intégrateurs de systèmes. Il est conçu et développé au sein de l'LinuxFoundation backports pilote groupe de travail.
Opération
Au démarrage, le backend de Jockey sonde le système le matériel disponible. Cela peut se produire de diverses façons, actuellement mis en œuvre est & nbsp; numérisation / sys pour modaliases. Dans l'avenir, il est prévu d'ajouter d'autres méthodes, telles que l'interrogation tasses pour imprimantes détectées qui ne disposent pas d'un pilote. & Nbsp; Les méthodes de détection seront ajoutés au besoin par les fournisseurs de composants et les distributions. L'ensemble du matériel disponible est représenté comme des objets "HardwareID" (qui peuvent représenter tout ce qui identifie de manière unique un morceau de matériel, comme un ID fournisseur / produit, un modalias, ou une chaîne d'identification de l'imprimante).
Pour chaque ID de matériel, un ensemble de bases de données de pilotes (instances de DriverDB) sont interrogés pour les pilotes disponibles. À l'heure actuelle, la seule implémentation existante est LocalKernelModulesDriverDB, qui utilise les cartes de modules.alias noyau Linux standard pour cartographier modaliases aux modules du noyau. Dans un proche avenir, nous prévoyons d'ajouter une autre mise en œuvre qui interroge une base de données en ligne du pilote ainsi. Les DriverDBs transforment l'ensemble de HardwareIDs à ​​un ensemble de DriverIDs.
Un DriverID représente toutes les métadonnées nécessaires sur un pilote, tels que:
* Classe de pilote (module de noyau, pilote d'imprimante, forfait, pilote graphique X.org, firmware, etc.)
* Nom de classe de gestionnaire (voir ci-dessous)
* Emplacement du pilote (référentiel, le nom de paquet, éventuellement sha1 et d'autres sommes de contrôle, les signatures)
* Les paramètres spécifiques du pilote (type arbitraire / valeur paires qui comprend le gestionnaire)
Tous les pilotes gérés par Jockey doivent être encapsulé par une sous-classe de "gestionnaire". Une instance de gestionnaire fournit un crochet pour un code arbitraire qui doit fonctionner afin d'installer un pilote entièrement. Jockey fournit déjà des implémentations de gestionnaire pour les cas les plus courants, tels que les modules du noyau Kernel module firmware, pilote X.org, des groupes de pilotes, etc. La grande majorité des conducteurs utiliseront cas paramétrées de ces gestionnaires par défaut, mais les pilotes qui ont besoin de certains plus sophistiqués locale configuration peut expédier leur propre sous-classe de gestionnaire et d'ajouter le code nécessaire.
Structure
La majeure partie du travail de Jockey (de détection de matériel, les requêtes de base de données du pilote, l'installation de paquets, etc.) est effectué par un backend indépendante de l'interface utilisateur qui fournit sa fonctionnalité sur le système D-BUS. L'accès est contrôlé par les privilèges PolicyKit (voir backend / com.ubuntu.devicedriver.policy.in pour plus de détails); Par défaut, tous les utilisateurs peuvent faire des requêtes de statut de pilote de périphérique locales, tous les utilisateurs locaux peuvent déclencher une requête de base de pilote à distance, et en fait l'installation / suppression de pilotes est limité aux administrateurs système.
Les différentes interfaces utilisateur (GTK, et KDE, et toutes deux fournissent une CLI) ainsi exécuté avec les privilèges de l'utilisateur normales et juste offrent une ambiance conviviale et internationalisé présentation / interface humaine des services de back-end. Ils ne contiennent pas de logique d'attaque.
Adapter Jockey à une distribution Linux
Jockey est soigneusement écrit pour ne pas être spécifique à une distribution Linux. Toutes les opérations spécifiques OS / distro sont encapsulés dans la classe "OSLib", qui doit être sous-classé et mis en œuvre par les distributions Linux. La plupart des méthodes ont déjà une implémentation par défaut raisonnable amont, mais certains sont tout simplement intrinsèquement spécifique distro (recherchez «NotImplementedError" pour trouver ceux).
Cela minimise les efforts de portage de distributeurs, tout en conservant la possibilité de faire des ajustements dans un endroit central.
La classe OSLib abstraite est bien documenté, et il existe déjà une branche pour Ubuntu [3], et la suite de test a une mise en œuvre fictive (voir tests / sandbox.py). Ceux-ci devraient suffire à mettre en œuvre Jockey pour d'autres distributions ainsi

Quoi de neuf dans cette version:.

• Cette version corrige un tonne de bogues, y compris tous ceux qui sont actuellement sélectionnés comme bloqueurs pour la version finale 0.5.
• Il n'a pas de nouvelles fonctionnalités.

Quoi de neuf dans la version 0.5 Alpha 1:

• Ceci est le premier aperçu de la prochaine version 0.5 qui se concentre sur une grande refonte de conception pour améliorer la portabilité, le soutien pour la détection de l'imprimante, les pilotes d'imprimante à partir openprinting.org, une interface D-BUS pour recherche de pilote pour les applications de bureau, et une interface utilisateur GTK rénové.