Leyendo Be Book – cómo hacer un driver

Introducción

Escribir el driver de un dispositivo requiere conocimientos adicionales de cómo funciona BeOS/Haiku. Este artículo es parte traducción parte cosecha propia, es traducción de los capítulos de BeBook acerca de cómo programar un driver.

El Kernel y el Driver Author

El Kernel de BeOS/Haiku contiene las funcionalidades básicas del sistema operativo:

  • El proceso de inicio del sistema
  • La gestión de memoria y los hilos
  • Administrar el bus PCI e ISA
  • Gestionar el sistema de archivos (devfs, administra /dev), el sistema raíz (rootfs, administra /)
  • Otras cosas…

Eso no es suficiente para la mayoría de las aplicaciones, el Kernel es extensible utilizando add-ons. Durante el inicio del sistema se cargan addons para manejar cosas como:

  • Sistemas  de archivos reales, como FAT, NTFS…
  • Dispositivos, como la pantalla, el ratón, el teclado…
  • Los Buses del sistema, etc…

Tipos de Kernel Add-on

Hay 3 tipos de Kernel Add-on:

  1. Los drivers de dispositivos son add-ons que se comunican directamente con el dispositivo.
  2. Los módulos del espacio del kernel que exportan API para su uso con los drivers (o por otros módulos).
  3. Los sistemas de archivos son add-ons que soportan tipos específicos, como son BFS, DOSFS,HFS…

Drivers de dispositivos

Un driver de dispositivo es un add-on que reconoce un determinado dispositivo ( o una clase de éstos) y permite entender al resto del sistema para comunicarse con él. Normalmente esta comunicación implica el uso de protocolo específico de comunicación. Por ejemplo. si el sistema quiere usar una tarjeta de red Ethernet o una tarjeta gráfica, es necesario cargar addon que hace de driver del dispositivo que conoce como comunicarse con esa tarjeta. De manera similar, el código que conoce como hablar con una determinada clase de dispositivos (discos SCSI, dispositivos ATA, USB, etc.) debe implementarse como un addon que hace las veces de driver de dispositivo.

Los apartados de módulos y sistemas de archivos no han sido traducidos.

Interactuando con el Kernel

El kernel dispone de diversos servicios que pueden usarse con los drivers y los módulos. Esto incluye:

  • Habilitar y desabilitar interrupciones.
  • Configurar la para memoria para el acceso directo a memoria (DMA).
  • Acceder a otros dispositivos y módulos.

El Kernel además, a nivel de usuario, dispone de un API cuasi-Posix para el acceso a dispositivos. Una aplicación puede abrir un dispositivo con open(), y usarlo con read(), write() e ioctl() para acceder al mismo.

Las llamadas Posix son convertidas a llamadas del sistema por el propio kernel, el cual usa vía devfs, el driver apropiado. El apartado de devfs no ha sido traducido.

Principios de implementación de Drivers

Gran parte de la estabilidad de BeOS/Haiku se debe a que existe un muro entre el kernel y las aplicaciones de usuario. Los drivers son grietas en este muro. Si un driver se comporta mal o falla, hay una gran posibilidad de que esto acuse un comportamiento inesperado o tire por completo al sistema. Es absolutamente crítico que los drivers no sólo sean cuidadosamente testados antes de ser publicados, además ellos deben seguir los siguientes principios al pie de la letra.

  • Kernel Space vs. User Space (espacio del Kernel contra espacio de usuario)

Una forma que puede reducir el riesgo de que el driver cause un fallo en el sistema es poniendo la mayoría del código en el espacio de usuario. Crear un driver que… [aquí he parado de traducir].

  • Código de sincronización
  • Funciones disponibles durante el Spinlocks
  • Usando Spinlocks
  • Deshabilitando interrupciones
  • Funciones disponibles cuando las interrupciones están deshabilitadas
  • No bloquees
  • No te adelantes
Anuncios

Haciendo un driver para Haiku OS

Introducción

Este artículo es parte traducción, parte cosecha propia, de un artículo publicado en la página oficial de Haiku. Ni que decir tiene que no pretendo con esto tener nada funcional, sino tener simplemente un artículo informativo de cuales son los primeros pason  para realizar un driver para esta plataforma. Lo que quiero con este artículo es colmar mi curiosidad.

Interfaz con el sistema operativo

El kernel driver se carga durante el inicio del sistema operativo, es iniciado por el sistema operativo y publicado en el área de usuario, pudiendo acceder al driver utilizando “user hooks”.

Para programar un kernel driver necesitamos codificar las siguientes rutinas:

  • init_hardware()
  • init_driver()
  • uninit_driver()
  • find_device()
  • publish_devices()

Los kernel drivers están dentro de dos carpetas en Haiku:

  • /boot/beos/system/add-ons/kernel/drivers/bin/: para drivers del sistema.
  • /boot/home/config/add-ons/kernel/drivers/bin/ : para los drivers add-on de usuario.

Los kernel drivers están apuntados por un enlace simbólico, localizado en:

  • /boot/beos/system/add-ons/kernel/drivers/dev/graphics

Y los driver de addons por parte del usuario están apuntados por un enlace simbólico, que está en:

  • /boot/home/config/add-ons/kernel/dev/graphics

Si surge algún problema con un determinado addon durante el inicio del sistema, puede accederse a una ventana de configuración presionando la barra espaciadora. Eligiendo “Safe Mode Options” | Disable User Addons” podremos continuar con la carga, esto no funciona en Haiku según he probado, pero si debe funcionar en BeOS.

Descripción en detalle de las rutinas del kernel driver

  1. init_hardware()– el sistema inicializa el kernel driver llamando a esta rutina durantre el inicio del sistema (startup). Esta rutina comprueba si bus del sistema está disponible, y si el dispositivo está presente.
  2. init_driver() – se ejecuta después de init_hardware(). init_driver() inicializa variables, como pueden ser, el nombre del dispositivo y abre el bus del sistema para su uso.
  3. publish_devices() – el sistema llama a todo el hardware del sistema que está disponible utilizando esta rutina. Los nombres son publicados como enlaces simbólicos en la carpeta /dev/. Este enlace simbólico apunta a la localización del driver.
  4. uninit_driver() – cuando el driver ya no es necesario, el sistema llama a uninit_driver() que liberará todos los recursos usados y cerrará todas las entradas al bus usadas por el driver.
  5. find_device() – devuelve todos los nombres de las rutinas asociados al “unique name”, y los deja preparados para su por parte del “drivers hooks”. Este “driver hooks” es el interfaz con el usuario, usado para acceder al driver en el kernel.

Interfaz para el Usuario

Una vez que el sistema operativo a inicializado el kernel driver, este está disponible para ser accesible utilizando las rutinas “hook”:

  • open_hook()
  • close_hook()
  • free_hook()
  • control_hook()
  • read_hook()
  • write_hook()

La instrucción open_hook()

La rutina open_hook() construye una información compartida con una estructura (struct) que puede ser accedida por todos los aceleradores (accelerants), contiene los ID de las tarjetas, el fabricante, las especificaciones y los valores de visibilidad si estos son necesarios.

La rutina close_hook()

Esta rutina cierra el  driver.

La rutina free_hook()

Cierra el kernel driver. El número de veces que el driver es abierto o cerrado queda almacenado en el log del sistema operativo, cuando el kernel driver se cierra por última vez se llama a free_hook(), destruyéndose además la información compartida en la estructura mencionada anteriormente.

La rutina control_hook()

Esta rutina se llama siempre que se quiera acceder al kernel_driver, otra función es activar o desactivar las rutinas de interrupción o ejecutar los comandos de los buses del sistema (PCI).

La rutina read_hook()

Esta rutina no se usa, devuelve el estado B_NOT_ALLOWEB.

La rutina write_hook()

Igual que read_hook, write_hook() devuelve el estado B_NOT_ALLOWEB.

 

@iescolar responde a unas de mis preguntas …

¿Realmente cree que su post es objetivo? Ya que utiliza deducciones y es más un artículo de opinión que uno periodístico (@huelvafriki, a través de Twitter)

El polémico post utiliza deducciones (creo que legítimas, porque se presentan como tal) pero también datos: documentos (una serie de correos con tarifas), entrevistas (con el propio fundador de Series Yonkis) e incluso información del registro mercantil. Y sí, también tiene opinión. Dos críticas: una, la principal, a la industria cultural por ser tan torpe como para no ofrecer una alternativa legal a estas páginas, otra a estas páginas. Lo he dicho varias veces: creo que las webs de enlaces a descargas no son justas, aunque sean legales, porque se lucran a costa del trabajo de otro (a costa, no con; el matiz es importante). Puede que sea un artículo molesto para mucha gente, pero no creo que no sea un artículo periodístico. (sigo respondiendo)
En general, me sorprende la candidez de algunos (no me refiero a ti, @huelvafriki) que parece ser que se pensaban que este tipo de páginas las crean y las actualizaban unos duendecillos y un señor con barba blanca que vive en el Polo Norte con sus renos. O una ONG por la cultura libre. Es obvio que una página plagada de anuncios y con un canal dedicado al póker online y otro al porno genera ingresos por lo que hace.

La entrevista completa en http://noticias.lainformacion.com/arte-cultura-y-espectaculos/internet/ignacio-escolar-responde-a-los-lectores-de-lainformacion-com_qurNY86y5UsNN4QHWoWLc5

 

Los problemas de Planeta Huelva basado en Planetaki

Introducción

Planeta Huelva es una de las muchas ideas surgidas de las Beers & Blogs Onubenses, actualmente fallecidas por falta de convocatorias. Otro de los hijos putativos de las Beers en Huelva fueron Huelva 2.0 o las quedadas de Twitteros de Huelva. Después de 3 años toca revisar que ha pasado y como seguir creciendo, aunque yo ya desde el exilio en Coria del Rio poco puedo hacer por convocar cuando ni yo voy a ir, o hacer de eje constante, cuando eso es lo único que se puede hacer en estos eventos, convocar, escuchar el feedback e implementarlo en acciones. Y cómo no dejar hacer a los demás lo que crean conveniente para el buen funcionamiento del evento.

Y aquí me encuentro que la versión de Planetaki de Planeta Huelva parece que es estática, mandada por un único lider, no aporta información de la interacción de los usuarios y lo peor de todo que no crea comunidad.

Problema 1 – No detecta las teclas repág y avpág

No las detecta no es el problema mayor, es que no permite navegar de manera adecuada por la página. Y cómo no tengo el código fuente pues no puedo implementar el parche que modifique esta acción.

Problema 2 – sólo puede publica enlaces un dios

en este caso mi usuario en planetaki, que es además mi correo electrónico y por tanto no puedo delegar adecuadamente la función de publicar por ser un dato que no me gusta aportar.

Problema 3 – si no gusta un enlace a los lectores aún así se ve

No feedback de los usuarios, así el planeta a pasado a ser un gran espaguetti de noticias sin ton ni son, que dificulta la lectura haciendo especial incapié en los blogs que más publican.

Problema 4 – privatización del servicio así como uso para elitismo

Es algo muy hablado en el mundo 2.0, que ya está muriendo para dejar paso al mundo móvil. Cuando un grupo coge poder y decide los designios de los demás a golpe de presión, ya sea por presión de karma o por presión del propio grupo o presión de liderazgo. En este caso, soy yo el que elige que se ve o que se lee y aunque mi figura no quiera ser autoritaria, si pongo mi sesgo y mi visión personal por los enlaces que componen el planeta. Algo que me parece poco enriquecedor y aburrido.

 

31 días con Robotics Studio 2008 R3: día uno haciendo un proyecto inicial con Robotics y Visual Studio 2.010

Introducción

Cómo sigue la filosofía de todos estos post que estoy escribiendo, supondré que tienes instalado Visual Studio en cualquiera de sus versiones así como Microsoft Robotics Studio 2008 R3.

Me resultó sorprendente después de la visita de El Bruno ha Sevilla que es más que cierto que no existe una gran literatura al respecto de Microsoft Robotics Studio en lengua castellana, cuando al contrario existe un gran interés por esta herramienta.

Muchas son las preguntas que me he encontrado cuando he dado alguna conferencia de robotics, normalmente en la Universidad de Sevilla, y eran claras y concisas. Dos ejemplo pueden ilustrar claramente lo que quiero expresar:

¿Cómo se hace un contrato?

Yo no sabía responder a esta pregunta hasta que me enfrenté al reto de montar mi R2D2 en robotics de manera virtual, es algo realmente sencillo y que sólo hay que tener en cuenta una serie de atributos para los métodos y para las clases.

¿Y esto es gratis?

No sólo es gratis sino que es código abierto, no libre software.

Así, tras esta introducción que justifica esta serie de post empiezo con el primero.

Creando un proyecto de robotics en Visual Studio 2.010.

Es una tarea realmente sencilla, hay que crear un proyecto DSS (2.2) y modificar la plantilla que se te presenta.

Ahora vamos hacer un pequeño resúmen de todo lo que contiene esta solución, para ello nos fijamos en la ventana de solución vemos que tenemos 3 archivos:

  1. el archivo de manifiesto: es un archivo XML que contiene la información necesaria para el despliegue del servicio web.
  2. el archivo nombredelasolucionTypes.cs: contiene el contrato que define como debe actual el servio, aquí es donde se define el contrato (con lo que la pregunta que hicimos en la introducción ya está resuelta).
  3. el archivo nombredelasolucion.cs: contiene el resto de clases que son necesarias para definir el servicio.

Por otro lado, si lo que deseamos es crear un proyecto desde cero, que es mi caso, partiendo de la realidad lo mejor es partir de un ejemplo de tantos que contiene robotics. Nos centraremos en el que viene en la carpeta de Virtualización, pero eso en el siguiente post.

 

Este sábado día 4 #XDP-Agile: Scrum

Este sábado los amigos de #XDP van a celebrar una desconferencia acerca de metodologías ágiles para el trabajo en grupo en equipos de programación.

Así para ir abriendo el apetito he estado leyendo alguna documentación vía web, sobre todo sobre el título de scrum master, que queda realmente bien el el currículum tenerlo.

Entre otros enlaces he encontrado los siguientes:

  1. Curso Gratis: Scrum día a día – http://santimacnet.wordpress.com/2010/11/04/curso-gratis-scrum-dia-a-dia/
  2. De la web de Agile-Andalucía (los mismos de XDP) podemos bajarnos un archivo con gran información a cerca de Scrum: http://www.megaupload.com/?d=UVR0RZIN
  3. La traducción de Scrum y XP desde las trincheras: http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf

Además de las conversaciones con Angel, y un amigo y compañero en la carrera he extraido bastante información acerca de patrones de diseño para plataformas móviles. Uno de los patrones de diseño que me habló fue el IoC, en el siguiente enlace podemos descargar un video bastante instructivo de Hadi Hariri:

http://santimacnet.wordpress.com/2010/11/30/desacoplamiento-n-capas-ioc-di/

 

A %d blogueros les gusta esto: