16 de mayo de 2006

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

3 comentarios:

  1. Anónimo3:14 a. m.

    No se porque te parece tan estupida esta iniciativa, es como CoLinux (software para Windows). Te enfocas en que el sistema no esta mas protegido ante cuelges, pero no creo que ese sea el fin que se buscaba.

    Tienes un nucleo trabajando con el hardware y ancima subes un kernel de linux ejecutandose como un programa, tal como cualquier otro, pero al igual que con los demas programas puedes cargar otra copia del kernel u otro kernel diferente, y tendras dos sistemas linux funcionando en la misma maquina, sin virtualizacion, ya que no estas usando emuladores ni nada de eso, sino que son procesos como lo seria un "ls" o un "named", mirate esta pagina:
    http://demo.tudos.org/eng_about.html. tienen un live-cd y dicen que se puede ejecutar varias copias de linux usando este metodo que tu dices "estupdio". El rendimiento tiene que ser mejor que con VMWARE o QEMU y hasta mejor que XEN. A que ahora suena interesante!!!

    ResponderEliminar
  2. Anónimo11:12 p. m.

    Es mucho más que eso. Si solo vas a correr Linux (o Windows) monousuario la ventaja es limitada. Por eso estoy de acuerdo en que la idea de MS con Vista es estúpida si pretenden mantener el monopolio.

    La ventaja viene cuando quieres correr mas sistemas, p. ej. Linux (para ciertas cosas), Windows (p.ej. para Office), Solaris (p. ej. para desarollar en Java)... y además aplicaciones independientes (p. ej. un navegador o un encriptador fuera de esos sistemas). Entonces si se cuelga Office tu servidor LAMP no lo hará, no la sesión de desarrollo en Java/Solaris, etc...

    Y si hablas de servidores ni te cuento: puedes actualizar el sistema operativo sin downtimes, puedes tirar y levantar sistemas sin que se vea, etc...

    Y si hablamos de multiusuario.. pues no está mal si el usuario puede acceder a sus datos a través de varios sistemas, y más si estos pueden estar protegidos unos de otros y hacer fallback.

    La estulticia es creer que todo el mundo es como tú y tiene las mismas necesidades. O pensar que si no ves una utilidad de inmediato no existe.

    Cierto, con VMware o Qemu puedes hacer algo parecido... pero mucho peor. Con VMware o Qemu o Xen tienes que reservar estáticamente la memoria al arrancar el sistema (si arrancas Linux con 512M y Windows con 512M y luego dejas uno, el otro ya no puede aprovechar esa memoria que no ya no usas). Con un
    buen microkernel el gestor de memoria te la irá dando según disponibilidad y necesidades. O sea, si corro Office en Windows le da memoria a Windows, si salgo la libera y si ahora la necesita Linux se la pasa sobre la marcha. Con máquinas virtuales no puedes cambiar dinámicamente la memoria asignada a una máquina. Con microkenels cada proceso tiene su memoria virtual que se mapeará sobre la real según necesidades y disponibilidad.

    Etc...
    --
    Jose R. Valverde
    EMBnet/CNB

    ResponderEliminar
  3. Anónimo2:59 a. m.

    Joder, Diego, te han dado en la llaga, pero me gusta tu forma de escribir y de opinar, buen blog.

    ResponderEliminar