Dada la buena respuesta que han tenido los últimos artículos conceptuales queremos continuar cubriendo algunos temas que son bastante conocidos a nivel de desarrolladores, pero poco manejados por el público general.

En esta ocasión hablaremos de un cambio realizado en Linux que a primera vista se ve poco relevante, pero que al examinar más a fondo abre nuevas oportunidades.  Se trata de Kernel Mode Setting o Configuración de Modo de Video en el Kernel.

Configurar un modo de video es una tarea que puede ser más compleja de lo que parece, sobre todo ahora que existen distintos tipos de salidas de video y hay que preocuparse de muchos más aspectos que de sólo un monitor.

En Linux el código que se encarga de configurar el modo de video se encuentra en varias partes, e incluso se puede apoyar en la BIOS para hacer este trabajo.  Pero esto provoca algunos inconvenientes:

• Algunas BIOS vienen con modos predefinidos que no se ajustan al hardware.  Sucede o sucedía con los primeros laptops que usaron modos widescreen pero cuyas BIOS sólo conocían los modos tradicionales.
• Qué tan correcto sea el manejo del modo de video y las salidas de video dependen exclusivamente de la implementación particular de la aplicación que necesita usar el video, por ejemplo X.org o el terminal en modo de texto.
• Cuando una aplicación configura el modo de video para trabajar en él, debe almacenar su estado y de alguna forma cederlo cuando otra aplicación necesita reconfigurar el modo de video.  Por ejemplo si estamos en una sesión gráfica en X.org y queremos pasar a una sesión de texto (Ctrl-Alt-F1), entonces X.org debe guardar el estado del video antes de que el terminal cambie a modo de texto.  Por otra parte el terminal de texto debe configurar el modo de video que necesita desde cero.  Cuando se vuelve a modo gráfico, se realiza el mismo proceso a la inversa: El terminal de texto guarda el estado, X.org reinicializa el video desde cero y luego restaura el estado que guardó previamente.

Todos al kernel

Con Kernel Mode Setting, la lógica de cambiar de modos de video se elimina de X.org y otras aplicaciones para implementarse únicamente en el kernel.  De esta forma hay sólo una implementación para esta funcionalidad común y todas las aplicaciones que necesiten cambiar de modo de video pueden pedir el servicio al kernel.  Por lo tanto desde el punto de vista de la calidad, ahora todas las aplicaciones compartirán la mejor implementación.

Antes, las aplicaciones no tenían cómo saber a qué modo de video se iba a cambiar, por lo tanto siempre el modo de video se reinicializaba.  Pero como ahora es el kernel quien se encarga de esta tarea, puede detectar que el modo de video que se está pidiendo es el mismo que ya se está usando, por lo que sólo bastará con limpiar la pantalla, sin necesidad de cambiar el modo de video.  Esto reduce al mínimo todos los pestañeos que un usuario de Linux está acostumbrado ver cuando se inicia el sistema.  Al mismo tiempo se asegura el correcto uso de las salidas de video adicionales como es el caso de un proyector o un monitor externo.

Otro cambio importante es que ahora el kernel puede configurar el mejor modo de video lo antes posible.  Por ejemplo, apenas se inicia el kernel, algo que toma un par de segundos, se puede iniciar el modo de video definitivo y desde ese momento en adelante nunca más cambiar, ni tampoco reinicializar.  Por lo tanto el splash de inicio, el gestor de login y el entorno de escritorio usarían todos la misma configuración de video y a ojos del usuario se verían sólo como imágenes de fondo que cambian.

El proceso de suspender el sistema y luego despertarlo se simplifica, ya que es el mismo kernel que está coordinando la suspensión y restauración quien tiene toda la información respecto al estado del video, lo que hace que el proceso entero sea más confiable y rápido como se muestra en el video que acompaña este artículo.

Nuevos horizontes

Ahora se podrán escribir nuevas aplicaciones que usen el video directamente, por ejemplo aplicaciones que funcionen en modo fullscreen y que necesiten su propia configuración.  A ojos del usuario, la aplicación se mantiene en el mismo ambiente, sin embargo se encuentra con una disponibilidad del 100% del hardware de video, sin ni siquiera un sistema de ventanas o un gestor de composición.  Estas nuevas aplicaciones podrían ser un salvapantallas, un juego, reproductor de videos, entornos gráficos livianos como Wayland, escritorios remotos, etc.

Aventurando un poco más la imaginación, se podrían tener transiciones al cambiar de una aplicación a otra, imaginen un cubo que gira como el de Compiz pero que actúa cuando se cambia a modo de texto, cuando se lanza una aplicación en modo fullscreen o cuando se cambia la sesión de usuario.

Distribuciones como Fedora ya incluyen Kernel Mode Setting pero su uso depende de la implementación de los drivers de video que se estén utilizando.  Otras distribuciones como Ubuntu lo integrarán en la siguiente versión.

Link : Artículos de Phoronix respecto a Kernel Mode Setting

Andrew Morton y Keith Packard (cc) by Linux Foundation

Y seguimos con noticias desde Linux Collaboration Summit en San Francisco.  En esta ocasión los muchachos de Ars Technica nos cuentan que hubo un interesante panel acerca del desarrollo del kernel de Linux en donde participaron destacados hackers.  Entre los temas que se tocaron estuvieron los sistemas de archivo, la arquitectura gráfica, y el rol de “la porquería” en el desarrollo del kernel.  Así es, hablaremos de “la porquería” (the crap(tm))

El panel del kernel fue una de las discusiones más técnicas que se llevaron a cabo en el evento.  Este panel fue moderado por Jonathan Corbet, editor del prestigioso medio LWN.net .  Los convocados fueron :

• Andrew Morton : uno de los principales desarrolladores del kernel de Linux. Tiene su propia rama en donde se prueban cambios que posteriomente entran a la rama de Linus Torvalds.  Andrew fue contratado por Google en el año 2006 para dedicarse por completo al desarrollo del kernel.
• Greg Kroah-Hartman : encargado del soporte de USB y creador de udev entre otros.  Trabaja a tiempo completo para Novell en el Linux Driver Project, una iniciativa para implementar drivers de código abierto con la cooperación de los fabricantes de hardware.  Greg es el fundador de este proyecto que hoy tiene más de 200 desarrolladores.
• Theodore Ts’o (Ted) : Es el desarrollador conocido por colaborar en el área de sistemas de archivo en Linux. Es el principal culpable del veloz ext4. Trabaja bajo el alero de Linux Foundation y tiene planes de volver a IBM a fines de año.
• Keith Packard : es el hombre responsable de las impresionantes mejoras que se han realizado en el sistema gráfico de Linux en la última década.  Aceleración por hardware, escritorios 3D, alpha blending, etc.  Trabaja en X Window desde la década de los 80.  Inició revolución gráfica mientras trabajaba para HP Labs y actualmente se encuentra en las filas de Intel.

La porquería

Kroah-Hartman discutió acerca de un área especial del kernel que se incluyó en la versión 2.6.28 para mantener en forma separada un conjunto de componentes y drivers del kernel que estuvieran incompletos o inestables.  La comunidad del kernel le llamó “la porquería”.

Esta área ayuda a que estos componentes sin terminar sean mas visibles y así atraigan el interés de otros desarrolladores para completarlos y llevarlos a un nivel de madurez suficiente para su uso normal.  La gran cantidad de mejoras que se hicieron a la porquería en la versión 2.6.30 demuestra que esta definición efectivamente ha servido para su propósito original.

El kernel y su influencia en el área gráfica

Keith Packard describió algunos cambios que se han realizado a la arquitectura gráica de Linux.  Hay componentes que se han sacado desde lo que se conoce como userspace y se han incluido como parte del kernel.  Aqui encontramos la arquitectura de aceleración (UXA), la configuración de los modos de video (KMS) y la administración de memoria (GEM).

Estos cambios han reducido las barreras para crear nuevos tipos de sistemas gráficos para la plataforma Linux, incluso ya han surgido algunos experimentos interesantes como es Wayland.

Packard explicó que los drivers gráficos son extremadamente complejos y que construirlos requiere un gran compromiso de tiempo, recursos y dedicación de los fabricantes.  Intel ha hecho una inversión significativa en la arquitectura gráfica para mejorar la compatibilidad de Linux con el hardware de Intel.  Por otra parte dice que ATI ha comenzado a tomar un rol activo permitiendo que la comunidad de soporte a sus chips.  Nvidia aun no ha llegado a este nivel de compromiso.

Ext4 : un refrito de tecnología de los ’70

Ted Ts’o habló sobre ext4 y cómo ha sido bien recibido por las distribuciones como Ubuntu y Fedora que lo incluyen como opción de instalación.  Se espera que pronto ext3 deje de ser el sistema de archivos por omisión en las distribuciones más populares.

Aunque ext4 agrega interesantes características, Ts’o no lo ve como un gran avance.  Incluso le baja el perfil a ext4 calificándolo como un refrito de tecnología de los ’70 y lo describe como una solución de corto plazo mas bien conservadora.  Cree que el camino a seguir es Btrfs, el sistema de archivo que viene de las manos de Oracle en donde si hay mejoras significativas respecto a escalabilidad, confiabilidad y facilidad de administración.

Al concluir el panel, Linux Foundation entregó por primera vez el premio del héroe anónimo (Unsung Hero) a Andrew Morton por su rol como mantenedor de la rama mm del kernel.

Link : Panelists ponder the kernel at Linux Collaboration Summit (Ars Technica)

Uno de los aspectos que estaba en duda era si incluir el kernel 2.6.29 o quedarse con el actual 2.6.28.  Aunque en un proyecto abierto normal ese cambio de número significa que sólo hay bugfixes, en el caso del kernel significa que hay nuevas características y en 2.6.29 se agregaron algunos cambios radicales:

• Modo Access Point : permite usar Linux como si se tratara de un Access Point para compartir la conexión inalámbrica (nice!)
• Soporte para WiMAX
• Nuevo soporte para dispositivos WiFi : Atheros otus, Ralink rt2860/70 entre otros.
• Integración del nuevo sistema de archivos Btrfs : inicialmente creado por Oracle y posteriormente liberado como GPL y por supuesto integrado oficialmente al kernel 2.6.29.  Provee manejo de grandes volúmenes de almacenamiento, compresión, revisión y deframentación en linea, manejo eficiente de archivos pequeños, etc.
• Integración de Kernel Mode Setting KMS : cuando no existía KMS, las aplicaciones que necesitaban acceder al video debían preocuparse de manejar el modo de video de la pantalla y su estado interno.  Al pasar de un X server a otro o por ejemplo desde el splash de inicio al X server, se producen varios pestañeos cuando uno de ellos cierra el modo de video y el siguiente lo asigna.  Ahora esa funcionalidad la hace el kernel sólo si es necesario, reduciendo el esfuerzo necesario para pasar de una aplicación gráfica a otra y permitiendo que surgan proyectos como el ya comentado Wayland.

Los cambios introducidos son grandes, y en el caso de BtrFS es demasiado reciente.  Mientras que distribuciones como Fedora en algun momento incluyeron KMS para después tener que deshabilitarlo, y ahora incluirán se lanzan con 2.6.29, en aras de la estabilidad, Canonical ha declarado que la próxima versión de Ubuntu vendrá con el kernel 2.6.28:

Jaunty absoluta, positivamente y sin ninguna duda, se liberará con kernel 2.6.28.  ¿Es eso suficientemente claro como para desmentir todos los rumores?

A buen entendedor, pocas palabras.

Links:
- Jaunty kernel version? (Ubuntu Kernel team mailing list)
- Ubuntu will NOT ship with the Linux 2.6.29 kernel (phoronix.com)
- Kernel Log : What’s new in 2.6.29 (Heise Online)