Funcionamiento de Jockey en Canaima

En este apartado explicaremos el funcionamiento de la aplicación Jockey de Canaima, por algunos conocida como el detector automático de Hardware. Este proceso de detección se refiere a poder determinar de forma automatizada cuales dispositivos existen en el sistema, determinar los controladores necesarios para que estos dispositivos funcionen en Canaima e instalarlos si el usuario lo solicita.

Kernel de Linux y Soporte a Hardware

Jockey actúa sobre los dispositivos no soportados de forma automática por el Kernel de Linux

Por lo general el kernel de Linux brinda soporte a la mayoría del Hardware que encontramos en un computador, y cuando hablamos de hardware hablamos de todo el hardware en general, no solo nos referimos a dispositivos especiales. Por ejemplo, cosas tan simples como el teclado y el ratón son dispositivos de hardware que los sistemas operativos deben reconocer y que normalmente no tomamos en cuenta que hay toda una cantidad de código fuente desarrollado para hacer funcionar estos dispositivos tan básicos que a veces ni los notamos.

Existe también otra cantidad de dispositivos soportados que para otros sistemas operativos es difícil darles soporte y es necesario que el usuario instale software de controladores para ellos, pero en cambio el Kernel de Linux los soporta sin ningún tipo de acción adicional del usuario más que conectarlo al computador. Un caso ejemplar de esto son las Tarjetas de Sonido, que en otros sistemas operativos es necesario activarlas instalando “Drivers”, en cambio en Linux ya vienen activadas sin hacer cambios al sistema.

De igual manera hay otro tipo de dispositivos los cuales vienen marcados por grandes restricciones legales de Copyright (Derechos de Autor) y el poco interés de los fabricantes de brindar soporte a Linux, por esta razón no tienen un soporte automático en Linux, sino que deben ser instalados controladores de software privativos adicionales, o simplemente no tienen soporte alguno.

Este último grupo de dispositivos de Hardware son los que Jockey detecta y determina automáticamente si requieren la instalación de software adicional.

Módulos y Firmware

Existen dos tipos de Software necesarios para que un dispositivo de hardware sea soportado por el Kernel de Linux, se trata de los Módulos del Kernel y el Firmware para el dispositivo. Para que el hardware funcione correctamente es necesario uno de ellos, en algunos casos y la combinación de ambos en otros.

Módulos

Se lee en la Wikipedia:

“En computación, un módulo cargable del núcleo es un archivo que contiene código objeto que puede extender el núcleo en ejecución (también llamado núcleo base) de un Sistema Operativo. La mayoría de los sistemas estilo Unix soportan módulos cargables en el núcleo (Kernel).

Los módulos cargables en el núcleo son generalmente utilizados para brindar soporte a nuevos dispositivos de Hardware y Sistema de archivos, así como para agregar llamadas al sistema. Cuando la funcionalidad provista por un módulo del núcleo deja de ser requerida, normalmente éste puede ser descargado, liberando su memoria.”

Firmware

Nuevamente consultando a la Wikipedia:

“El firmware es un bloque de instrucciones de máquina para propósitos específicos, grabado en una memoria, normalmente de lectura / escritura (ROM, EEPROM, flash, etc), que establece la lógica de más bajo nivel que controla los circuitos electrónicos de un dispositivo de cualquier tipo. Está fuertemente integrado con la electrónica del dispositivo siendo el software que tiene directa interacción con el hardware: es el encargado de controlarlo para ejecutar correctamente las instrucciones externas.

En resumen, un firmware es el software que maneja al hardware.

Funcionamiento de Jockey

En Canaima, el detector de hardware está compuesto por tres elementos principales:

  • El Backend
  • El Device Monitor
  • La interfaz de Usuario

Estos tres elementos actúan en dos capas, una capa de sistema (root) y otra capa de usuario.

Diagrama del comportamiento de Jockey. El kernel notifica al Device monitor a través de UDEV la presencia de un dispositivo. El Device Monitor dispara Backend para hacer el chequeo de controladores a través de DBus. Si faltan controladores se disparan las notificaciones y a través de estas se llama a la Interfaz gráfica de usuario quien interactuará luego con el Backend a través de DBus para hacer la instalación

Backend

El Backend de Jockey es la pieza central de todo el proceso de detección del hardware. Este interactúa a directamente con el kernel y los módulos del mismo, haciendo las consultas y procedimientos necesarios para determinar los dispositivos de hardware presentes en el sistema.

Igualmente es el Backend el que se encarga a través de los “Handlers” de activar o desactivar los controladores para dichos dispositivos detectados. Cabe destacar que cuando hablamos de dispositivos detectados en esta sección, hablamos únicamente de aquellos en que pudo determinarse la ausencia de controladores, todos los demás dispositivos a los cuales el Kernel da soporte automático son obviados.

Device Monitor

La función del Device monitor es, como su nombre lo indica, es monitorear en tiempo real la inserción de nuevos dispositivos de hardware en el sistema. Esto lo logra interactuando con UDEV quien le reporta cuando un dispositivo ha sido conectado o desconectado del sistema.

Interactúa en conjunto con el Backend a través de un canal de comunicación DBus, por medio del cual el Device Monitor informa al Backend que un nuevo dispositivo ha sido conectado, y por el cual el mismo Backend informa al Device Monitor si el dispositivo requiere controladores o no.

Si un dispositivo es detectado como “Sin controladores” entonces el Device Monitor se encarga de liberar las notificaciones al usuario a través de la librería libnotify y a por medio de estas notificaciones el usuario puede levantar la interfaz gráfica para decidir qué hacer con el dispositivo detectado.

Interfaz de Usuario

Interfaz Gráfica GTK de Jockey

La interfaz de usuario es la encargada de presentar al usuario la lista de dispositivos que Jockey a detectado, ya sea para activarlos o desactivarlos. Igualmente ofrece detalles del dispositivo y del controlador que será instalado y además ofrece la opción de ignorar las notificaciones referentes a un dispositivo en particular.

La activación y desactivación de los dispositivos la logra esta interfaz gráfica interactuando directamente con el Backend a través de un canal DBus por el cual se envían y se reciben las señales desde y hacia el Backend.

Activación de los Controladores

La activación de los controladores a través de Jockey se producen a través de dos herramientas provistas por esta aplicación, estas son los Handlers y las sobreescritura de Modaliases

Handlers (Manejadores)

Son piezas de código Python en forma de Clases, que vienen en varios tipos dependiendo de la forma de instalación de los controladores. Los Handlers contienen en su código los métodos necesarios para hacer la activación o desactivación del dispositivo en el sistema.

Ejemplo de un Handler

import logging
import os
import subprocess

from jockey.oslib import OSLib
from jockey.handlers import FirmwareHandler, KernelModuleHandler

class IntelCentrinoN1000FirmwareHandler(FirmwareHandler):
    def __init__(self, ui):
        self._free = False
        FirmwareHandler.__init__(
            self,
            ui,
            'iwlwifi',
            '/lib/firmware/iwlwifi-1000-5.ucode',
            name='Firmware for Intel Centrino-N 1000 wireless'
        )
        self.package = 'firmware-iwlwifi'
        self._auto_install = False
        self.needs_kernel_headers = False
        # The iwlwifi module needs to be unloaded then reloaded
        # to activate the device. Rebinding doesn't work
        self._do_rebind = False

    def enable(self):
        logging.debug('Going to reload module %s' % (self.module, ))
        subprocess.call([OSLib.inst.modprobe_path, '-r', self.module])
        r = KernelModuleHandler.enable(self)
        subprocess.call([OSLib.inst.modprobe_path, self.module])
        return r

    def disable(self):
        logging.debug('Removing module %s' % (self.module, ))
        subprocess.call([OSLib.inst.modprobe_path, '-r', self.module])
        return KernelModuleHandler.disable(self)

Sobreescritura de Modaliases

Son pequeños archivos de texto que asocian los identificadores de un dispositivos (IdVendor, IdProduct) con un módulo específico y con un paquete de software presente en el repositorio. Estos Modaliases sobreescritos, son procesados por Jockey y convertidos automáticamente en Handler, es decir, son convertidos a código Python entendible por el Backend quien luego se encargará de hacer los llamados a los métodos correspondientes.

Si un dispositivo es declarado en alguno de estos archivos de sobreescritura de Modaliases, entonces el Backend se encarga de determinar si el módulo indicado está presente en el sistema, y si no es así, entonces instala el paquete de software señalado por este archivo.

Ejemplo de un archivo Modaliases para Jockey

# Realtek
alias pci:v10ecd8192* rtl8192se firmware-realtek
alias pci:v10ecd8171* rtl8192se firmware-realtek
alias pci:v10ecd8172* rtl8192se firmware-realtek
alias pci:v10ecd8173* rtl8192se firmware-realtek
alias pci:v10ecd8174* rtl8192se firmware-realtek

Otro ejemplo de archivo Modaliases:

# Information from http://wireless.kernel.org/en/users/Drivers/ath9k_htc/devices
reset ath9k_htc
# Atheros
alias usb:v0CF3p7010d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
alias usb:v0CF3p7015d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
alias usb:v0CF3p9271d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# Azureware
alias usb:v13D3p3327d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
alias usb:v13D3p3328d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# D-Link
alias usb:v07D1p3A10d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# LiteOn
alias usb:v04CAp4605d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# Netgear
alias usb:v0846p9030d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
alias usb:v0846p9018d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# Panasonic
alias usb:v04DAp3904d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# SMC
alias usb:v083ApA704d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# Sony
alias usb:v0411p017Fd*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros
# TP-LINK
alias usb:v0CF3p1006d*dc*dsc*dp*ic*isc*ip* ath9k_htc firmware-atheros

Referencias

Funcionamiento de Jockey en Canaima

2 comentarios en “Funcionamiento de Jockey en Canaima

  1. degasjr dijo:

    Jockey es muy útil, el problema es que el hardware que ensambla el gobierno es propietario cuando no debería ser así, tengo entendido que las VIT tienen procesadores intel y demás, entonces deberían fabricar y ensamblar hardware libre que se sabe que tiene soporte nativo en GNU/Linux. La inalámbrica de las Canaimitas es Broadcom que si bien tiene driver descargable con Jockey, éste no es libre, entonces siempre será un problema. Hay webs donde se listan hardware 100% compatible con GNU/Linux incluso con proveedores para quien quiera comprarlo.

    1. pequeño inocente!!! el gobierno no está en la capacidad de fabricar hardware con el nivel de calidad de intel, ni de realtek, ni de boadcom, etc,etc,etc. En todo caso sería más sencillo mediar a nivel de gubernamental con empresas como intel, realtek, etc, etc para que desarrollen controladores para el proyecto Canaima, (de todas maneras ninguna empresa vende los drivers de sus producto, ni hp, ni acer, ni ninguna otra… tu compras una impresora y te vas a la pagina del fabricante y los descargas gratis cuantas veces quieras)

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s