Lo que traerá Linux 2.6.29

Despues del formato en doble artículo de la versión anterior cabía esperar que esta, la 2.6.29, fuera algo más austera en cuanto a la importancia de sus novedades, pero no ha sido así. Solamente la cuestión apodada modesetting se merecería varios artículos para hablar (alguien que conozca bien el tema del tema) de las profundas implicaciones que conlleva, pero yo no pienso hacer ni uno solo separado. Directamente traduciré aquí todo lo que he puesto en la versión original inglesa de la lista de novedades para Linux 2.6.29, y que Dios reconozca a los suyos.

Modesetting: Cuando hablamos de "mode setting", queremos decir configurar cosas como la resolución y la profundidad de color de la pantalla. En otras palabras, configurar lo que haga falta de la tarjeta gráfica para que se puedan dibujar cosas en la pantalla. Puede parecer algo fácil de implementar pero la gente que se dedica a los gráficos asegura que diseñarlo e implementarlo bien es más dificil de lo que parece, razón por la que se ha tardado tanto tiempo. Para empezar, configurar la tarjeta gráfica implica asignar memoria de la tarjeta gráfica, lo que significa que antes de hacer toda esta historia de modesetting, era necesario tener el gestor de memoria GEM e incluirlo en el kernel, lo cual no ocurrió hasta la versión anterior, 2.6.28.

Implementarlo bien es mucho más dificil si uno considera como funciona la arquitectura gráfica de los sistemas Linux hoy en día. Tenemos varios drivers compartiendo el mismo hardware (la tarjeta gráfica): El driver VGA del kernel, los drivers framebuffer, los drivers DRM del kernel, los drivers en espacio de usuario de X.org, los drivers DRI de espacio de usuario, y otros drivers en espacio de usuario (ej: svgalib). Es una pésima idea. Por ejemplo, el driver en espacio de usuario de X.org es una implementación completa de todo lo que se necesita para hacer funcionar la tarjeta gŕafica en modo 2D, y cuando se inicia X.org todo va bien. Pero cuando se cambia de X.org a un terminal virtual (Control+Alt+F1), el driver X.org tiene que dejar de gestionar la tarjeta gráfica, porque se necesita pasar el control a otro driver: el driver de la consola fb. Asi que el driver X.org guarda el estado de la pantalla, se reinicia la tarjeta gráfica y se pasa su control al driver fb, que tiene que reinicializar completamente la tarjeta de nuevo (esa es la razón por la que hay esa pausa durante el cambio), incluso si la resolución en X.org y en la consola fb es la misma. Cuando vuelves a X.org, la tarjeta necesita ser reconfigurada de nuevo. Esta arquitectura es confusa, proclive a dar muchos fallos, y es dificil de hacer funcionar correctamente en algunos casos, por ejemplo, es más dificil despertar el sistema tras haberlo suspendido/hibernado con este diseño porque el driver X.org está en espacio de usuario y la suspensión/hibernado es (debe ser) transparente para él, asi que no tiene constancia de que debe reiniciar el hardware antes de continuar dibujando tras despertar el sistema por completo, necesitando por tanto un ayudante en forma de programa en espacio de usuario o en firmware que a veces puede no funcionar correctamente (pantalla negra, cuelgue).

Con modesetting, todos esos problemas desaparecen. El aspecto modesetting de las tarjetas gráficas se centraliza en los drivers del kernel. Puede que esto parezca mucho código para meterlo en el kernel, pero en realidad es lo contrario: Hay una sola base de código encargada del modesetting, lo cual significa que el tamaño de todo subsistema gráfico se reduce. Y como solo hay una implementación, y se comparte más el código, la calidad y robustez del código se incrementan. Además, esta es una tarea que verdaderamente corresponde a los drivers del kernel (es como lo han hecho sisempre todos los demás sistemas operativos, incluyendo algunos Unix propietarios). Pero todo esto es solo una pequeña parte de todos los beneficios: La suspensión e hibernación funcionan mejor, porque todo el trabajo lo hace el driver del kernel tal y como se hace con el resto de hardware. X.org ya no necesita privilegios de root (hasta ahora se habían necesitado tan solo porque los drivers necesitaban acceder al hardware para implementar los drivers en espacio de usuario), haciendo posible ejecutar X.org sin permisos de root, lo cual es una gran mejora y deja a X.org dedicarse a la tarea que se supone que le corresponde: dibujar cosas, no toquetear el hardware. Tambien se hace posible imprimir "oopses" del kernel (o incluso una BSOD al estilo de Windows ;) en la pantalla si el kernel falla mientras se trabaja en X.org. Y por si todo esto no fuera suficiente, tambien se consigue una consola FB que funciona sobre modesetting y GEM, haciendo que los viejos drivers FB se vuelvan innecesarios y conservando al mismo tiempo su funcionalidad. Y con modesetting ya no se necesita resetear el hardware cuando se cambia de X.org a un terminal virtual, y cuando se cambia, si la resolución es la misma, no hay necesidad de cambiar nada, haciendo posible la creación de una pantalla de arranque sin artificios gráficos inesperados.

Sin embargo, probar modesetting no es fácil. En el lado del kernel, solo el driver de Intel añade soporte de modesetting (el soporte para otros drivers está en proceso y será incluido en futuras versiones). En el lado de X.org es aun más dificil. Porque cuando el soporte de modesetting en el kernel está activado, se REQUIERE que el driver X.org driver tambien tenga soporte de modesetting. Si activas el soporte para modesetting y no tienes un driver de X.org con soporte modesetting, X.org NO podrá funcionar de ningún modo e incluso podría colgar tu máquina. No hay ningún modo de solucionar esto, excepto desactivar el soporte modesetting del kernel. Ahora mismo, solo los drivers de Intel parecen tener una versión estable con soporte de modesetting, el soporte para otros drivers está aun en desarrollo

Btrfs: Btrfs es un nuevo sistema de archivos desarrollado de cero siguiendo los principios de diseño de otros sistemas de archivo como ZFS o WAFL. Fue creado por Chris Mason, un programador de Oracle que trabajó varios años en Reiserfs v3. Se espera que se convierta en el reemplazo de los sistemas de archivos Ext como el sistemas de archivo más utilizado. Se puede encontrar más infomación en el wiki de btrfs. Btrfs se encuentra bajo desarrollo, lo cual significa que es INESTABLE, y aunque en los últimos meses se ha estabilizado bastante no debes asumir que usarlo es seguro. Se está incluyendo en el kernel del mismo modo que se incluyó ext4dev, para mejorar el desarrollo. Asi que se recomienda no utilizarlo para nada que no sea pruebas, benchmarks y desarrollo. El plan actual del equipo de btrfs es sacar una versión 1.0. No se espera que el formato de disco vaya a cambiar más (aunque lo hará si se encuentra algún fallo crítico).

Squashfs: Squashfs es un sistema de archivos de solo lectura y altamente comprimido que es muy conocido por ser utilizado como base de los Live-CDs de las distribuciones Linux más comunes y de algunas distribuciones para dispositivos embebidos como routers. Usa compresión zlib (en un futuro habrá soporte lzma) para comprimir archivos, inodos y directorios. Los inodos en el sistema son muy pequeños y todos los bloques son compactados para minimizar los datos extra. Soporta tamaños de bloque mayores que 4K (hasta 1M, tamaño de bloque por defecto 128K).

SquashFS 4.0 soporta sistema de archivos y archivos de 64 bits (mayores de 4 GB), información completa uid/gid, enlaces duros y marcas de tiempo. Su propósito es ser utilizado como sistema de archivos de solo lectura, para archivos (en los casos donde se podría utilizar un .tar.gz), y en dispositivos embebidos bajos en recursos. Se puede encontrar más información y las herramientas en espacio de usuario (necesarias para crear el sistema de archivos) en http://squashfs.sourceforge.net

Tree RCU: Esta característica soluciona un problema de rendimiento en la implementación clásica de RCU (un tipo de sistema de bloqueo que utiliza Linux para lograr gran escalabilidad) que desembocaba en contención interna del mecanismo en sistemas con más que unas pocas cientas de CPUs; el RCU clásico fue diseñado para máquinascon 16-32 CPUs. "Tree RCU" aplica una jerarquía, reduciendo en gran medida la contención en el bloqueo de primer nivel en grandes máquinas.

WiMAX: 2.6.29 incluye soporte de WiMAX, que proporciona transmisión inalámbrica de datos a grandes distancias: 75 Mbit/s. Está basada en el estándar IEEE 802.16. Esta pila ha sido proporcionada por Intel, e incluye un driver para los dispositivos Intel Wireless WiMAX/Wi-Fi Link 5x50 USB/SDIO.

Soporte Wireless del modo Access Point:La pila wifi mac80211 está ahora preparada para soportar el modo AP. Requiere hostapd. Este modo solamente se puede configurar a través de cfg80211 (no con iwconfig y/o WEXT).

Cifrado de nombres de archivo en eCryptfs: eCryptfs implementa cifrado transparente de los contenidos de un archivo. En esta versión tambien puede cifrar el nombre del archivo. Cada nombre cifrado tiene un prefijo que indica que eCryptfs debe intentar descifrar el archivo, razón por la que eCryptfs no podrá gestionar correctamente los nombres de archivo que estén cerca del límite máximo del nombre de archivo.

'Congelado' del sistema de archivos: Linux no tiene nada que congele temporalmente las escrituras en un sistema de archivos. Asi que no es posible tomar una copia de seguridad que mantenga consistencia con el sistema de archivos mientras está montado y siendo utilizado. Muchos sistemas de archivo comerciales (por ejemplo, VxFS) tiene una característica que pausa las escrituras temporalmente, en esta versión Linux añade una característica similar.

Soporte de swap en el controlador de memoria, y otras mejoras: Esta característica añade gestión de swap al controlador de recursos de memoria. Anteriormente, el controlador no podía controlar el swap utilizado por los procesos de un cgroup, permitiendo por tanto que un solo proceso acabara con todo el swap. Ahora, puedes limitar el uso de memoria+swap de cada cgroup. Sin embargo, añade cierta sobrecarga de recursos, asi que es configurable. Otra característica añadida al controlador de memoria es el soporte de jerarquías, configuración de swappiness por cada, estadísticas mejoradas y mejor gestión de oom.

Soporte de 4096 CPUs en X86: El núcleo de Linux soporta ese número de CPUs, pero había problemas en el código específico x86. Hay una estructura de datos, cpumask_t, que se utiliza para representar a todas las CPUs del sistema. Con 4096 CPUs esa estructura se volvió demasiado grande, causando desbordamientos de pila. El código ha sido modificado para utilizar punteros para esa estructura en lugar de utilizar la pila, haciendo posible tener máquinas x86 con 4096 CPUs (si, existen).

Modo sin journal para Ext4: Desde que nació Ext3, hubo gente que nunca quiso utilizar journaling por varias razones. En esta versión, Ext4 añade soporte para funcionar sin journaling. El resultado es una pequeña mejora de rendimiento comparado con el Ext4 normal, pero sobre todo, una gran mejora sobre Ext2.

Checksums de los metadatos en OCFS2: OCFS2 (un sistema de archivos para clusters) utiliza ahora checksums para los metadatos, para asegurar la integridad.

Pues eso es todo. La lista completa y detallada está aquí, como siempre.