Drivers en espacio de usuario en Linux

Se ha corrido la voz de que Linus Torvalds ha incluido en su repositorio de Linux parches que permiten la creación de drivers en espacio de usuario. Las reacciones, abundantes, no se han hecho esperar, lo cual no es sorprendente si tenemos en cuenta de que estamos hablando de uno de los friki-temas informáticos preferidos: ¿Que es mejor, un kernel monolítico o un microkernel? Esto ocurre porque a mucha gente le da la impresión de que este cambio significa que Linus se ha dado por vencido y quiere que se escriban driver solo en el espacio de usuario. La realidad sin embargo es más compleja.

En primer lugar, en los sistemas Linux ya se utilizan ciertos drivers en espacio de usuario desde hace tiempo. X.org, sin ir más lejos, implementa drivers (para 2D, es decir, todo lo que no es DRI/DRM) en espacio de usuario, y además lo hace soportando multiples plataformas. CUPS, el sistema de impresión más utilizado en el mundo libre, implementa sus drivers en espacio de usuario accediendo al puerto paralelo o USB. Y libusb es una libreria que se ideo para acceder a los dispositivos USB e implementar sus drivers desde espacio de usuario. Y en el campo de otros sistemas operativos, tenemos el UDMF de Windows Vista, que es una infraestructura para implementar drivers en espacio de usuario muy parecida a esta que se incluye ahora en Linux.

En otras palabras, resulta que los drivers en espacio de usuario no son algo totalmente nuevo. En cuanto a Linus, ha confesado no estar muy de acuerdo con la idea de tener drivers en espacio de usuario, y da la impresión de que ha permitido incluir esto simplemente porque lo han pedido un par de personas y “para ver que pasa” - ¿quien sabe como va a evolucionar algo así si no le das la oportunidad? Podría resultar que esta infraestructura se acabara modificando para dar cabida a la infraestructura actual de libusb y de los drivers de impresora, y otros, y esa unificación sería buena.

Por lo que se refiere a la épica y eterna flamewar entre kernels monolíticos y microkernels, de ningún modo esto supone un “cambio de rumbo hacia los microkernels”. Este parche no incluye ningún “sistema de paso de mensajes”; decir que esto es una orientación hacia los microkernels estan absurdo como decirlo de la capacidad de cargar y descargar drivers dinámicamente. Además, resulta que este sistema incluido en Linux no permite implementar un driver totalmente en espacio de usuario: Se requiere en primer lugar un mini-driver que se encargue de hacer las funciones de inicialización del bus PCI y de gestión de interrupciones: tareas de bajo nivel que no se va a permitir hacer en espacio de usuario.

En otras palabras, tenemos un mini-driver que se encarga de gestionar las funciones de bajo nivel, y que expone un dispositivo que se puede leer y que al mmap()earlo permite acceder al dispositivo y a la memoria determinada por el mini-driver. Está muy limitado: no se puede ni hacer cosas básicas como DMA, solo se pueden crear dispositivos de caracteres, nada de dispositivos de bloques ni de dispositivos de red. No se trata por tanto de una infraestructura que se haya creado para mover todos los drivers de Linux a espacio de usuario, sino de un sistema muy limitado y orientado, según sus propios autores, a sistemas embebidos, porque hace más sencillo el desarrollo (se puede utilizar en cualquier lenguaje y cualquier librería), depuración, etc.

Su propósito no es mover los drivers SATA/SCI/gráficos a espacio de usuario, sino el de hacer más sencillo el desarrollo de drivers para ciertos dispositivos. Comparte en este campo el mismo objetivo que libusb, solo que esto es más genérico (aunque si esta infraestructura tiene éxito sin ningún tipo de duda se extenderá con más funcionalidad). ¿Ahora que está incluido, será utilizado de forma masiva por los desarrolladores de drivers? Quizás, pero como mucho en casos como libusb: Dispositivos que se conectan en buses externos, como webcams y derivados. Dispositivos que es mejor implementar en espacio de usuario debido a la frecuente ausencia de especificaciones contra la que es más fácil luchar si puedes experimentar con el dispositivo sencillamente, que es una característica de este parche. Además, a pesar de que no es apropiado para dispositivos donde el rendimiento es crítico, este tipo de infraestructuras pueden saturar sin problemas el bus USB o Firewire. Los hackers del kernel simplemente intentan evitar trabajo inútil intentando descargar trabajo en una infraestructura que puede beneficiar el desarrollo de cierto tipos de drivers. Demasiado ruido para algo tan simple.