Jockey

Jockey es una herramienta para la instalación de controladores de hardware de terceros.
Jockey proporciona la infraestructura y la interfaz de usuario para encontrar e instalar controladores de terceros que son aplicables a la computadora. Esto incluye controladores que se agregan o se actualizan después de la liberación de una distribución, o los conductores que no puede ser incluido en la distribución por diversas razones (de limitación de espacio de CD, problemas de licencias, etc.).
Un caso de uso común está proporcionando una manera amable y semiautomática para instalar controladores para el hardware nuevo que el comunicado de distribución actual no soporta todavía, o instalar controladores de Nvidia y ATI fglrx X.org.
Jockey fue diseñado para ser agnóstico distribución y satisfacer las necesidades de diferentes distribuciones, vendedores conductor, e integradores de sistemas. Está diseñado y desarrollado dentro del LinuxFoundation backports conductor de grupo de trabajo.
Operación
En el inicio, el backend Jockey sondea el sistema de hardware disponible. Esto puede suceder de varias maneras, implementado actualmente es & nbsp; escaneo / sys para modaliases. En el futuro se planea agregar más métodos, como la consulta de tazas para impresoras detectadas que no disponen de un conductor. & Nbsp; Se añadirán Los métodos de detección según sea necesario por los vendedores de componentes y distribuciones. El conjunto de hardware disponible se representa como objetos "HardwareID" (que pueden representar cualquier cosa que identifica una pieza de hardware, como un ID de proveedor / producto, un modalias, o una cadena de identificación de la impresora).
Para cada identificador de hardware, un conjunto de bases de datos de controladores (instancias de DriverDB) se preguntó a los controladores disponibles. Por el momento, la única aplicación existente es LocalKernelModulesDriverDB, que utiliza los mapas modules.alias kernel estándar de Linux para mapear modaliases a los módulos del núcleo. En un futuro próximo tenemos la intención de añadir otra aplicación que consulta una base de datos piloto en línea también. Los DriverDBs transforman el conjunto de HardwareIDs a un conjunto de DriverIDs.
Un DriverID representa todos los metadatos necesarios sobre un conductor, como por ejemplo:
* Clase de controlador (módulo del kernel, el controlador de impresora, paquete, X.org controlador de gráficos, firmware, etc.)
* Nombre de clase de controlador (ver más abajo)
* Ubicación del controlador (repositorio, nombre del paquete, posiblemente sha1 y otras sumas de comprobación, las firmas)
* Los parámetros específicos del controlador (pares de tipo arbitrario / valor que entiende el controlador)
Todos los conductores manejados por Jockey necesitan ser encapsulado por una subclase de "Handler". Una instancia de controlador ofrece un gancho para código arbitrario que debe ejecutar para instalar completamente un conductor. Jockey ya proporciona implementaciones del manejador de casos comunes, tales como módulos de kernel, módulo del kernel del firmware, controlador X.org, grupos de conductores, etc. La gran mayoría de los conductores utilizarán casos parametrizados de estos controladores por defecto, pero los conductores que necesitan un poco más sofisticado locales configuración puede enviar su propia subclase manejador y añadir el código necesario.
Estructura
El grueso de la obra de Jockey (detección de hardware, las consultas de base de datos del conductor, la instalación de paquetes, etc.) se realiza por un backend independiente IU que proporciona su funcionalidad sobre el sistema D-BUS. El acceso es controlado por privilegios PolicyKit (ver backend / com.ubuntu.devicedriver.policy.in para más detalles); de forma predeterminada, todos los usuarios pueden hacer consultas de estado de controlador de dispositivo local, todos los usuarios locales pueden desencadenar una consulta de base de datos controlador remoto, y en realidad la instalación / eliminación de controladores está restringida a los administradores de sistemas.
Las diferentes interfaces de usuario (GTK y KDE, y ambos proporcionan una CLI también) ejecutan con privilegios de usuario normales y simplemente proporcionan un agradable y internacionalizado presentación / UI humano de los servicios de back-end. No contienen ninguna lógica conductor.
La adaptación de Jockey para una distribución de Linux
Jockey está escrito con cuidado para no ser específicas para cualquier distribución de Linux. Todas las operaciones específicas de OS / distro están encapsulados en la clase "OSLib", que debe ser una subclase y ejecutado por las distribuciones de Linux. La mayoría de los métodos ya tienen una implementación por defecto razonable aguas arriba, pero algunos son inherentemente específica distro (busque "NotImplementedError" para encontrar aquellos).
Esto minimiza los esfuerzos de portabilidad de los distribuidores se mantiene la posibilidad de hacer ajustes en un lugar central.
La clase OSLib abstracto es bien documentada, y ya existe una rama de Ubuntu [3], y el conjunto de pruebas tiene una implementación ficticia (ver pruebas / sandbox.py). Estos deberían ser suficientes para implementar Jockey para otras distribuciones, así

¿Cuál es nuevo en esta versión:.

• Esta versión corrige un tonelada de insectos, incluyendo todos los que se seleccionan actualmente como bloqueadores para la versión final 0.5.
• No tiene nuevas características.

¿Cuál es nuevo en la versión 0.5 Alpha 1:

• Esta es la primera vista previa de la próxima versión 0.5 que se centra en una gran revisión de diseño para mejorar la portabilidad, el apoyo a la detección de la impresora, los controladores de impresora desde openprinting.org, una interfaz de D-BUS para la búsqueda controlador para aplicaciones de escritorio y una interfaz de usuario GTK reformado.