Jockey

Jockey é uma ferramenta para a instalação de drivers de hardware de terceiros.
Jockey fornece a infra-estrutura ea interface do usuário para encontrar e instalar drivers de terceiros que são aplicáveis ​​para o computador. Isso inclui drivers que são adicionados ou atualizados após o lançamento de uma distribuição, ou motoristas que não pode ser incluído na distribuição por várias razões (espaço de limitação de CD, problemas de licenciamento, etc.).
Um caso de uso comum está fornecendo uma maneira amigável e semi-automática para instalar drivers para o novo hardware que a versão de distribuição atual não suporta ainda, ou instalar nVidia e ATI fglrx X.org motoristas.
Jockey foi projetado para ser agnóstico de distribuição e atender a necessidade de diferentes distribuições, fornecedores de drivers e integradores de sistemas. Ele é projetado e desenvolvido no âmbito do LinuxFoundation backports motorista grupo de trabalho.
Operação
Na inicialização, o backend Jockey investiga o sistema de hardware disponível. Isso pode acontecer de várias maneiras, implementado atualmente é & nbsp; digitalização / sys para modaliases. No futuro está previsto para adicionar mais métodos, tais como a consulta copos para impressoras detectadas que não têm um driver. & Nbsp; Os métodos de detecção será adicionado como necessário por fornecedores e distribuições de componentes. O conjunto de hardware disponível é representado como objetos "HardwareID" (que pode representar qualquer coisa que identifica unicamente uma peça de hardware, como um ID do fornecedor / produto, uma MODALIAS, ou uma seqüência de identificação da impressora).
Para cada ID de hardware, um conjunto de bancos de dados do controlador (instâncias de DriverDB) são consultados para os drivers disponíveis. No momento, a única implementação existente é LocalKernelModulesDriverDB, que usa o padrão de mapas modules.alias kernel do Linux para mapear modaliases a módulos do kernel. Num futuro próximo, pretendemos acrescentar uma outra aplicação que consulta um banco de dados on-line motorista também. Os DriverDBs transformar o conjunto de HardwareIDs a um conjunto de DriverIDs.
A DriverID representa todos os metadados necessário cerca de um motorista, tais como:
* Classe driver (módulo do kernel, driver de impressão, embalagem, X.org driver de gráficos, firmware, etc.)
* Nome da classe manipulador (veja abaixo)
* Localização do controlador (repositório, nome do pacote, possivelmente sha1 e outras somas de verificação, assinaturas)
* Os parâmetros específicos de driver (pares tipo arbitrário / valor que o manipulador entende)
Todos os motoristas manipulados por Jockey precisa de ser isolada por uma subclasse de "Handler". A instância de manipulador fornece um gancho para um código arbitrário que precisa ser executado para instalar um driver totalmente. Jockey já fornece implementações de manipulador para casos comuns, tais como módulos do kernel, firmware módulo do kernel, X.org motorista, grupos de motoristas, etc. A grande maioria dos motoristas vai usar instâncias parametrizadas desses manipuladores padrão, mas os motoristas que precisam um pouco mais sofisticado locais configuração pode enviar sua própria subclasse manipulador e adicionar o código necessário.
Estrutura
A maior parte do trabalho do Jockey (detecção de hardware, banco de dados consultas motorista, a instalação do pacote, etc.) é feito por um backend independente UI que prevê a sua funcionalidade sobre o sistema D-BUS. O acesso é controlado por privilégios PolicyKit (veja backend / com.ubuntu.devicedriver.policy.in para mais detalhes); por padrão, todos os usuários podem fazer consultas de status driver de dispositivo locais, todos os usuários locais podem desencadear uma consulta de banco de dados controlador remoto, e, na verdade, a instalação / remoção de drivers é restrito a administradores de sistema.
As diferentes interfaces de usuário (GTK, e KDE, e ambos fornecem uma CLI), bem executado com privilégios de usuário normal e apenas fornecer um ser humano amigável e internacionalizada apresentação / UI dos serviços de back-end. Eles não contêm qualquer lógica motorista.
Adaptação Jockey para uma distribuição Linux
Jockey é cuidadosamente escrito para não ser específico para qualquer distribuição Linux. Todas as operações específicas do OS / distro são encapsulados na classe "OSLib", que precisa ser uma subclasse e executado pelas distribuições Linux. A maioria dos métodos já tem uma implementação padrão razoável a montante, mas alguns são apenas inerentemente específica distro (procure por "NotImplementedError" para encontrar aqueles).
Isso minimiza os esforços de portabilidade dos distribuidores, mantendo a possibilidade de fazer ajustes em um lugar central.
A classe OSLib abstrato é completamente documentado, e já existe um ramo para o Ubuntu [3], ea suíte de teste tem uma implementação fictícia (ver testes / sandbox.py). Estes devem ser suficientes para implementar Jockey para outras distribuições, bem

O que é novo nesta versão:.

• Esta versão corrige um ton de bugs, incluindo todos aqueles que estão atualmente selecionados como bloqueadores para a versão final 0.5.
• Não tem novos recursos.

O que é novo na versão 0.5 Alpha 1:

• Esta é a primeira prévia do próximo lançamento 0.5 que se concentra em uma grande revisão de design para melhorar a portabilidade, suporte para detecção de impressora, drivers de impressora de openprinting.org, uma interface D-BUS para pesquisa de driver para aplicativos de desktop, e uma interface de usuário remodelada GTK.