La estupidez de l4linux

La controversia de los micro vs monolithic kernels está teniendo sus lados graciosos. Uno de ellos es el de portar tal kernel monolítico a ejecutarse sobre tal microkernel. Como ejemplo está l4linux: Pretenden portar Linux 2.6.16 a correr sobre L4. Y lo conseguirán. Y funcionará.

Ahora bien, la estupidez de la idea es inmensa. Me explico: Imaginen ustedes por un momento ese sistema. Que puede que funcione, o que incluso sea usable. El sistema arranca L4, L4 busca la imagen de Linux, la carga, y empieza a ejecutar el kernel. Linux termina de cargar, carga init, empieza a ejecutar el inicio de (pongamos) Ubuntu. Todo perfecto. Ahora imaginense ustedes un fallo en el sistema de gestión de memoria de Linux. Pum, el sistema se cuelga. Ah, pero tenemos L4. Albricias, que maravilla, que alegría. Solo ha cascado el proceso del kernel Linux y el sistema sigue en pie. Podemos volver a iniciar Linux o (ya puestos) Solaris o BSD, que seguro que no cascan tanto como Linux.

¿Sigue en pie? Permitanme ponerlo en duda. Ese nucleo Linux estaba ejecutándose bajo L4, de acuerdo. Pero tambien se da la circunstancia de que todo el sistema de ubuntu, todos los drivers de linux, TODO, absolutamente todo estaba ejecutándose bajo ese proceso de Linux. Si ese proceso Linux muere, el sistema que dependía de él muere tambien. Asi que el sistema no se ha colgado, no. Pero el efecto que ha tenido es exactamente el mismo, el mismito mismito que si si que hubiera tenido un cuelgue. Que L4 reinicie ese proceso es equivalente a un reinicio del sistema. Es totalmente equivalente, para entendernos, a ejecutar Linux bajo Vmware: Si ejecuto Linux bajo vmware y Linux casca, el sistema no casca, no. Pero el sistema que estaba ejecutando bajo linux en ese vmware si que casca, si.

Y ahora que venga a explicarme alguien, si es que puede, que supuestas ventajas le encuentra la gente a portar Linux, Solaris o cualquier otro sistema operativo a L4. La mezcla de un sistema monolíticos y un microkernel resulta en un sistema monolítico, no en un microkernel. Es como multiplicar X * 0: sea lo que sea X, el resultado siempre será cero (se me ha olvidado el número de la puñetera ley, y ni ganas que tengo de recordarla). En Mac OS X se dieron cuenta y no se rompieron la cabeza: Since Mac OS X was not intended to work as a multi-server, and a crash of a BSD server was equivalent to a system crash from a user perspective the advantages of protecting Mach from BSD were negligible.

La ventaja de un microkernel se encuentra en ejecutar las cosas en diferentes procesos y si haces un microkernel tu objetivo debe ser conseguir eso y no otra cosa. La cuestión básica como muy bien decía Torvalds el otro día - luego dirán que es él quien ignora la investigación y la teoría cuando es el único que parece tenerla en cuenta - es si todo lo que ejecutas está en el mismo espacio de direcciones, o en otro separado. En l4linux por muy protegido que esté el sistema de cuelgues, el núcleo se ejecuta en un solo y único espacio de direcciones, con lo cual un cuelgue del proceso Linux supone un cuelgue del sistema.

Si lo que pretende L4Linux es proporcionar un sistema para reiniciar kernels monolíticos, que no se rompan la cabeza: Ya tenemos kexec. Los kernels monolíticos, por mucho vómito que suelten algunos, no se "cuelgan irreversiblemente": Detectan un error y paran el funcionamiento del sistema. Cuando ves un oops del kernel en la pantalla lo que ha ocurrido es que se ha detectado un error - un puntero nulo, sin ir más lejos - el kernel lo ha detectado y ha decidido parar la ejecución del sistema porque a partir de ese punto no puede garantizar la integridad del sistema. El código que imprime el oops en la pantalla es código del propio kernel que es ejecutado al llegar a ese tipo de fallos. Podría continuar ejecutando el kernel (algo que no hace porque sería una locura dado que el estado del kernel ya es inestable) o podría ejecutar otro código. Kexec, por ejemplo, que ejecuta unas cuantas lineas de código para arrancar - la magia no existe. O kgdb, el debugger del kernel, un shell interactivo.

La realidad, para variar, es muy diferente de lo que algunos la pintan. La única ventaja de un microkernel es su separación en diferentes espacios de direcciones. Y su principal desventaja es al mismo tiempo esa ventaja: La perdida de rendimiento en un microkernel viene dada por la necesidad de cambiar de contexto entre montones de procesos para tener que hacer una petición al disco, si lo implementas todo en un proceso las desventajas de rendimiento disminuyen. Es tan asquerosamente obvio, que la idea de L4Linux me da asco. Que nadie se confunda conmigo: Creo que los kernels monolíticos son la manera más eficiente de crear sistemas operativos de propósito general hoy en día de la misma manera que los sistemas políticos de hoy en día le dan mil vueltas a lo que se conseguiría con la anarquía, pero desarrollar un microkernel REAL (no l4Linux) basado en L4 sería algo que apoyaría si no hubiera tanta sinrazón por estos lares. La falta de rigor en la comunidad científica - Tanembaum utiliza L4Linux como ejemplo de microkernel a pesar de los problemillas que acabo de contar, como si esos problemas no fueran con él y uno pudiera olvidarse de ellos para justificar los microkernels - con respecto a los kernels monolíticos y a los microkernels es tan grande que si los microkernels tuvieran sentido no lograrían nunca llegar a nada por la estupidez e incapacidad de aquellos que los desarrollan