¿Qué tendrá Linux 2.6.22?

Como parte del mantenimiento de kernelnewbies.org/LinuxChanges, aquí va un resumen de avance en españolcastellano:

• El SLUB allocator, que reemplazará al "slab allocator", y no lo traduzco por lo pedante que suena. El "slab allocator" es un mecanismo de gestión de memoria a muy bajo nivel y muy crítico para el rendimiento. El mecanismo actual no es que sea malo, de hecho es bastante bueno, pero los de SGI, que trabajan con equipos de 1024 ó 4096 CPUs, encontraban su diseño ineficiente para esos casos (se gastaban GB solo para las "colas de objetos", sin contar los objetos), y la adición de nociones NUMA a lo largo de su vida no había sido todo lo limpia que debería. En vez de intentar parchearlo poco a poco ha preferido reescribir un sistema nuevo de cero con un diseño más simple y que incluso mejora algo el rendimiento. En 2.6.22 este "SLUB" está disponible de forma opcional


• Nueva pila wifi: El soporte de drivers wireless en linux ha sido francamente un caos debido a la ausencia de una pila wifi que soportara todo tipo de características, lo que ha hecho que hayan surgido más de una pila wifi, drivers implementando caracteristicas ausentes en la pila....en 2.6.22 se incluye una pila wifi liberada por Devicescape, con completo soporte para 802.11g, capa MAC por software, wpa, wpe, módulo de "bridging" a nivel de enlace, capacidades QoS para VOIP y video...además tiene una nueva interfaz de configuración, basada en netlink, y compatibilidad con las antiguas extensiones wireless basadas en ioctls. La pega es que los drivers del kernel no han sido portados aun a esta pila y aunque hay parches en algunos casos, aun no han sido incluidos. Hay algunos drivers que han sido desarrollados de cero sobre esta pila que tambien se incluiran en el futuro.


• Nueva pila firewire. Más pequeña (8k LoC frente a los actuales 30k), mejor diseñada, compatible con la antigua a nivel de libreria. La antigua permanece ahí para quien la quiera usar. Como puede verse, Linux no ha perdido su afan por reescribir partes del código para conseguir un mejor kernel.


• Nueva arquitectura: Blackfin


• UBI, un LVM para dispositivos de almacenamiento basados en memoria flash. ¿Por qué se necesita un nuevo subsistema y no se extiende LVM? Porque los dispositivos flash son fundamentalmente diferentes.


• Gestión de eventos de señales y temporizadores a través de descriptores de archivos. Linux carece de parte de la funcionalidad equivalente a kevent/kqueue (FreeBSD, OSX y otros equivalentes en Solaris y NT). Linux implementó epoll(), una "epoll() escalable" (el poll() tradicional de Unix está seriamente limitado en cuanto a su rendimiento por cuestiones de diseño), pero epoll no cubre las señales ni los temporizadores, porque no son descriptores de archivo. Frente a la solución considerada sobrediseñada de kevent/kqueue y despues de rechazar una implementación de Linux que implementaba algo similar, se ha optado por una idea de Linus de hace 4 años más "unixy": las llamadas de sistema signalfd()/timerfd(), que asocian a un descriptor de archivo a una señal o eventos de temporizador. A esos descriptores se les puede aplicar read(), poll(), epoll(), etc; de manera que se pueden gestionar señales y temporizadores como "archivos".


• Sockets RxRPC seguros. Este es un tipo de protocolo que se utiliza con el "Andrew File System" (AFS), pero francamente no tengo ni pajolera idea de lo que hace.


• utimensat(), una extensión a futimensat(). No se que hará, pero seguro quer sirve para algo. Dicen que soporta resolución de nanosegundos, y algo que tiene la palabra "nano" no puede ser del todo malo.


• Varios algoritmos de control de congestión nuevos, varios drivers nuevos, IPV6 para CIFS, soporte de escritura en AFS, etc etc....más de lo mismo bajo el cielo azul. Con lo de arriba ya hay suficiente.