A veces veo eventos...

A pesar de los fallos relativos al git-svn y tener que trabajar unicamente con el repositorio de GitHub... no he podido resistirme ni tener las manos quietas y he picado mas codigo :-P ¿Y en que he estado liado estos ultimos dias en lugar de estudiar los examenes? Pues ni mas ni menos que con el task manager :-D

El primer paso fue hacer que se imprieran los ticks fuera del driver del temporizador, ya que ahi no hacian nada util. Ahora se estan enviando por el motor de eventos en distintos periodos de tiempo: milisegundos (para lo que he tenido que aumentar la precision del timer, suerte que solo es una variable :-) ), centesimas, decimas y segundos. Asi aunque quizas lo sobrecargue un poco simplemente tengo que acoplarme a la frecuencia adecuada, en este caso centesimas (lo estandar), aunque podria hacer que el cambio de contexto fuese incluso mas rapido si quisiera.

Despues, empece con la definicion basica de lo que seria un proceso internamente para poder delegarles eventos (registrarse directamente en el gestor de eventos del sistema queda un poco feo y complicado, y mas si de todas formas habra que buscar los callbacks dentro de los procesos). Al principio pense en reutilizar la libreria de threads que he hecho para la asignatura de Fundamentos de Sistemas Distribuidos... hasta que me di cuenta que setjmp() y longjmp() son dependientes de cada sistema o no tengo manera posible de implementarlos por el momento :-/ asi que descarte esa idea y me centre por el momento en como hacer para delegar los eventos a sub-diccionarios, y aqui me encontre con otro problema: ¡un diccionario no es una funcion! Asi que como solucion rapida estoy usando un segundo diccionario a la espera de desarrollar mas como seria el tipo Event.

Por ultimo y no menos importante, en un acto de inspiracion divina (en concreto de Morfeo ;-) ) se me ocurrio que aunque actualmente este todo funcionando en el mismo espacio de usuario, podria trabajar con los eventos de los procesos de forma independiente a traves de funciones estaticas... incluso aunque esten en un mismo archivo, siempre que sea este el que se importe. Esto redunda en codigo repetido, si, pero quizas se pueda arreglar pasando las estructuras por parametros. Lo que si que es interesante es el hecho de que el preprocesador se ejecuta de forma lineal, con lo que abusando de el un poco, he conseguido renombrar las funciones relaccionadas con los eventos en el lado de las aplicaciones igual que en el lado del kernel, con lo que solo hace falta cambiar el include para poder pasar el codigo de un lado a otro :-D Esto ultimo es mas util de lo que parece, ya que aparte de hacer el codigo mas limpio, quizas pueda aplicarlo tambien a las llamadas al sistema, y por tanto, que se puedan mover los drivers del espacio de usuario al espacio de kernel de forma totalmente transparente :-D

Como veis, esta todo bastante "en el aire" a la espera de poder dividir el codigo cuando termine el concurso y poder analizar y hacer pruebas independientes de cada parte, pero lo cierto es que al final me esta quedando un API bastante curiosa y flexible y, sobretodo, puramente orientada a eventos (que es lo que queria... :-D )

Update 23:39:

He intentado demostrar mi teoria respecto a usar la misma firma en los syscalls y ha funcionado, pero no como esperaba... sino mejor: puesto que ahora tengo el codigo mas aislado entre sus partes (y sobretodo a nivel de makefile), a la hora de compilarlo cada parte se compila con sus correspondientes syscall.h y syscall.c sin interferirse, luego no hacen falta hacer trucos de ningun tipo: las firmas de los syscalls son iguales que las de las funciones que representan dentro del kernel de forma nativa :-D Chulo, ¿eh? :-)

(Problemas de) ultima hora

Etapa final del concurso de este año y en plena epoca de examenes (al menos para mi, que todavia estoy en el plan antiguo), la tension se vive en el aire... :-D Y me encuentro con problemas :-(

Anoche le estuve dando un repaso a Gaia haciendo que pueda delegar los eventos a "sub-managers" propios de cada aplicacion (el primer paso para poder aislar las aplicaciones del core y que pueda ser realmente multitarea mientras sigue funcionando por eventos) y lo cierto es que consegui que funcionara... hasta cierto punto. El caso es que el motivo por el cual se estaban imprimiendo por pantalla los caracteres dos veces (un bug realmente feo) es porque de hecho estaba procesando el evento dos veces, una al producirse y otra al bombear la cola. "Bien, un bug menos" direis... pues no: resulta que aunque la arquitectura es correcta y de hecho los eventos generados por las interrupciones se estan procesando correctamente, los eventos "software" (en concreto 'VGA/text/putchar', el encargado de escribir en pantalla) se estan llenando de 'V' al principio y por lo tanto no coinciden con ninguno de los registrados (obvio...). ¿Resultado? No se imprime nada en pantalla. Estupendo... Asi que como no consigo encontrar el error (puede deberse a una condicion de carrera o a una mala implementacion del diccionario, aunque visto que siempre ocurre igual supongo que es esto ultimo) y tampoco hay demasiado tiempo, he preferido que los eventos se lancen directamente sin pasar por la cola a espera de poder aislar libGaia cuando termine el concurso y hacer pruebas en condiciones. Esta es una de las razones por las que me gusta tanto Python, que todas las estructuras basicas vienen de serie y ademas estan muy probadas. La parte buena es que el origen del bug de imprimir dos veces ahora esta completamente identificado... :-D

Sin embargo hay otro problema no menos importante: era muy reticente a usar la forja del concurso para este proyecto (a diferencia del año pasado) puesto que por la complejidad del proyecto podia haber problemas... y los ha habido: puesto que al usar git-svn se me creo una nueva rama 'master', Masterbranch no me estaba recogiendo los cambios, asi que intente unir las dos ramas para que estuvieran sincronizadas... y ahora git-svn no funciona. Por suerte el codigo esta a salvo: en la forja del concurso esta una version con el bug anterior corregido y funcionando de forma estable, y puedo seguir subiendo cosas al repositorio de GitHub, luego no hay problemas en este aspecto. Sin embargo, si durante esta semana hago cambios grandes, o bien arreglo git-svn o bien sera mejor acceder directamente al repositorio principal en GitHub.

Un empujoncito...

Bueno, como ya sabreis, nos encontramos en la recta final del concurso de este año, y aunque ya habia pensado en abandonarlo debido a la de lio que he tenido ultimamente y a que literalmente habia perdido la inspiracion... lo cierto es que soy un testarudo :-P

Asi que ya me veis, puesto que habia que entregar un pequeño informe detallado en el Readme del proyecto y tambien subirlo a la forja del concurso, me puse a revisar el codigo por si encontraba donde estaba el fallo por el cual no leia desde el teclado ni se procesaban correctamente los eventos lanzados por las interrupciones, y de pura casualidad los encontre, o al menos encontre una posible solucion añadiendole un pequeño retraso y cambiando los eventos a minusculas (creo que tiene que ver con la busqueda de entradas dentro del diccionario). Segun un amigo mio lo del retraso es debido a una condicion de carrera, pero lo cierto es que no tengo demasiadas ganas de investigarlo por ahora ya que tengo pensado hacer un rediseño completo del proyecto, principalmente convirtiendo el core en un proyecto independiente (libGaia) gracias al hecho de que en PyMite4Multiboot el codigo es practicamente el mismo, con lo que ademas me sera tambien mucho mas facil testearlo (como ya me paso cuando converti AntiORM en un proyecto independiente de PirannaFS).

En resumen: que ya leo desde el teclado correctamente, y acabo de darme cuenta que tenia muy cerquita y al alcance de la mano el poder tener "algo" que se pareciese minimamente a un sistema operativo multitarea y ademas con un esbozo muy claro de cual seria la API de las aplicaciones, en lugar de ser todo una macedonia de frutas callbacks lanzados por eventos. Vale, de acuerdo: un unico espacio de direcciones, todo hardcodeado, sin memoria dinamica... me referia mas al hecho de que aislando los eventos de las aplicaciones en su propia cola (en lugar de usar la del sistema) y el poder cambiar de "aplicaciones" a partir de las interrupciones del reloj del sistema quedaria mas claro cuales son los conceptos a partir de los que queria basar el proyecto. ¿Deberia haberme centrado mas en el proyecto en lugar de dedicar el tiempo a AntiORM? Probablemente. ¿Y respecto a PyMite4Multiboot? No lo creo, ya que justamente al ser mas facil desarrollar sobre el y permitirme ver las cosas desde otro punto de vista no solo he podido definir mejor como orientar el desarrollo futuro del proyecto (o sea: crear libGaia y modularizarlo) y ademas me ha sido mas facil resolver los fallos que tenia con el teclado. En cualquier caso, como dijo Linus Tordvalds y muy especialmente aplicado al software libre, si no es divertido no merece la pena hacerlo... :-D

Ahora, ¿que me depara el futuro? Bueno, a corto plazo centrarme en los examenes (me esperan dos semanas de aupa...), y despues quizas intente a definir la API de las aplicaciones si me da tiempo a hacerlo antes de que termine el plazo de evaluacion del concurso. Despues sin lugar a dudas aislar libGaia y todos los sub-proyectos que han aparecido a lo largo de este año y englobarlos dentro de ChaOS Project, el sistema operativo que llevo queriendo hacer desde que tenia 10 años y lo que realmente hizo que me motivara a desarrollar PirannaFS y Gaia (y que no subiera el codigo a la forja hasta el ultimo momento... :-P En Git los branchs y forks son cosas de cada dia, pero en SVN son casi como invocar a
Cthulhu...), y por ultimo continuar con el desarrollo de libGaia, Uranus y PyMite4Multiboot ya durante el verano o bien durante el año que viene, esta vez ya centrandome en darles una consistencia y una calidad al codigo, principalmente haciendo que funcione correctamente la memoria dinamica y el funcionamiento en espacio de usuario (aunque la tentacion de aprovechar PyMite para hacerme un sistema operativo y un kernel en Python me esta rondando mucho la cabeza... :-P ).

It works!

PyMite corriendo sobre QEmu (x86) usando por debajo el codigo de Gaia mostrando un timer basado en interrupciones :-D

PyMite

Originariamente no iba a desarrollar Gaia, todo fue fruto de las circunstancias. Desde siempre tuve claro que mi sistema operativo tendria una arquitectura microkernel, sin embargo tambien queria que fuera seguro y facil de entender, de ahi que la arquitectura exokernel fuera ganando fuerza: el menor codigo posible corriendo como supervisor, y todo lo demas corriendo como espacio de usuario. Esto se podria potenciar mas si no solo se usan dos ejecutables distintos (Gaia y Uranus) sino que directamente estaban escritos en dos lenguajes distintos, y que dos mejores opciones que mis grandes amores C++ y Python :-D

Proyectos para hacer un sistema operativo en Python ha habido algunos, pero no han llegado a buen termino, en parte por la mala fama que tiene Python de ser lento (lo cual no es "tan" cierto...). Sin embargo poco antes de comenzar la edicion del concurso de este año descubri la existencia de PyMite, y en ese momento vi claro que es lo que debia hacer :-D

PyMite aka Python-on-a-chip es una maquina virtual Python diseñada para correr sobre microcontroladores de 8 bits... y sin sistema operativo por debajo, directamente sobre el metal :-) Ironicamente, aunque existe la posibilidad de compilarlo para escritorio para pruebas no habia ninguna plataforma echa para que corriera sobre PCs estandar directamente, luego ¿que mejor manera de colaborar con el software libre? Y ademas, me conseguia una base solida sobre la que programar mi sistema operativo comodamente sin tener que diseñarme mis propias estructuras de datos: dos por el precio de uno :-)

Asi que me puse a ello, mirando documentacion y haciendo pruebas. Lo tenia todo listo, y a la hora de ejecutar... fallo. Un bug tan raro que ni el programador original pudo decirme que podria pasar :-( Habia perdido un tiempo precioso y ademas ya estaba mentalizado en desarrollar de una vez por todas mi propio sistema operativo, por lo que decidi cambiar mi proyecto de portar PyMite a la arquitectura x86 a desarrollar mi propio exokernel que sustituyera la labor que realizaria PyMite de abstraer a bajo nivel el hardware, y asi surgio Gaia, la madre tierra.

Sin embargo, la semana pasada recibi un e-mail sobre no-se-que indicandome que podria ser mi version de Python ya que al ser muy reciente generaba bytecodes que eran interpretados como basura. Al principio no sabia a que se referia hasta que vi de donde procedia: ¡era el bug que notifique hacia 5 meses! La verdad que no confiaba mucho en una idea feliz tan absurda, aunque tenia sentido asi que decidi probarla: me baje mi viejo codigo, compile el entorno usando Python 2.6 en lugar del 2.7.2 que viene por defecto, ejecuto... y no me lo podia creer, la excepcion habia desaparecido. ¡El ultimo paso que me faltaba, al final lo tenia! :-D Tarde, pero al menos ya no me quedaba con el regusto de no haberlo conseguido: PyMite estaba corriendo sobre una nueva plataforma y todo gracias a mi... y al mensaje de un desconocido :-D

Asi que estos dias le he estado dando un pequeño empujon canibalizando el codigo de Gaia (al igual que hace 5 meses hice en sentido inverso) y lo cierto es que me estoy llevando una grata noticia: no solo me esta siendo mucho mas facil entender como hacer las cosas al haberme peleado antese-mail con Gaia (y ademas ya funciona el timer con PyMite :-P ) sino que ademas, ¡casi no estoy picando codigo! ¡¡Todo es copy & paste!! :-D Luego en cierto sentido creo que "parte" de mi proposito al desarrollar Gaia se esta cumpliendo: un framework para hacer facil el desarrollo de sistemas operativos sin tener que preocuparse de las menudeces porque ya estan hechas :-) Por el momento el copy&paste es descarado porque al pillarme la noticia un poco por sorpresa actualmente Gaia de framework tiene poco... pero si que el codigo esta bastante claro con lo que no me esta costando nada adaptarlo :-)

Lo bueno de esto es que me va a servir para tener otro entorno de pruebas aparte de ChaOS para aumentar la portabilidad y abstraccion de Gaia, lo cual es bueno, y ademas tambien me permite colaborar con un proyecto de software libre bastante grande, lo cual esta genial :-D De momento estoy pensando en separar la libreria del sistema a un proyecto aparte (GaiaLib), con vistas a en el futuro sustituirla por NewLib (aunque lo cierto es que no me esta quedando nada mal... :-D ), y quien sabe si no podre sacar mas codigo reutilizable. Al final con la tonteria, lo que iba a ser un simple proyecto para el concurso ya van colaboraciones en cuatro distintos... :-P

Gaia is back

Bien es cierto que no escribo mucho por aca, pero lo cierto es que no soy muy dado a escribir... :-P Pero bueno, como considero que debo manteneros informados de mis avances, alla voy :-D

Lo cierto es que muchos avances no ha habido con Gaia a pesar de el tiempo dedicado, la paginacion me ha estado dando muchos problemas y a ser sinceros, me ha deprimido. He intentado solucionarlo usando el codigo original de James Mallory (de cuyos tutoriales sobre sistemas operativos he estado usando como referencia) para ir adaptandolo a mi arquitectura y ver en donde estaba fallando, pero lo cierto es que ya me aburri (que es lo peor que le puede pasar a alguien que desarrolla software libre, que deje de divertirse con lo que hace) y deje el proyecto aparcado/abandonado hasta que viera un poco de luz. Es por eso por lo que si veis mi perfil en Github vereis que le he estado dando un buen empujon a PirannaFS en las ultimas semanas: por alguna razon, me sigue motivando e inspirando :-)

Sin embargo... esa luz llego, aunque fuese solo con forma de cerilla: a traves de la wikipedia llegue por casualidad al sistema operativo Gavin, y justo en uno de los commits indicaba que estaba usando -O2 al compilar para optimizar el codigo porque añadia una variable y dejaba de arrancar (uno de los problemas que me sucedian a mi) ya que al parecer, al arrancar se dispone de muy poco espacio en memoria para el kernel. Añadir el flag, compilar... y adios problema :-D Asi que aprovechando la buena nueva decidi darle un empujon al gestor de interrupciones y limpiar un poco la arquitectura antes de continuar con la paginacion. Gracias a esto puedo decir: si, mi arquitectura funciona, y es correcta, se puede hacer un sistema operativo puramente orientado a eventos :-D Ahora el problema esta en que por alguna razon los syscalls ya no funcionan correctamente, con lo que no puedo leer del teclado :-( Bien es cierto que una de las razones por las que empece Gaia era precisamente para evitar a la gente en el futuro que se rompiera la cabeza como me la estoy rompiendo yo ahora, pero tampoco me imagine que x86 fuese una plataforma tan mala para trabajar a bajo nivel... :-(

En fin, permanezcan en antena, a ver si hacemos algo de provecho en las proximas semanas...

Ho-Ho-Ho

Esto de estar de vacaciones es una maravilla, menuda semanita me estoy pegando... :-D Para empezar, estoy viendo a un monton de gente que hacia tiempo que no veia (ayer mismo a una antigua compañera de clase que resulta que tambien le gusta ir a las conferencias de Software Libre :-D ), los examenes no me han ido del todo mal (especialmente Sistemas Operativos, que por un error a la hora de corregir las practicas he pasado de un 3 a un 9.1 :-D ), y encima no solo le he estado dando caña al proyecto sino que cuando les pase a mis colegas de AlcorconWireless el enlace a mi anterior entrada al blog contando en que iba a consistir el proyecto el comentario que ha soltado uno es mitico:

Piraña se nos ha hecho mayor. Yo ya no me meto con él que me da sopas con honda XD
Respect!

Epic Win!!! :-D Y ademas, otro dice que se apunta, asi que podre acelerarlo un poco mas :-D Tambien me han dicho que se ve mal el texto con el fondo tan oscuro, a ver si cuando tenga tiempo lo arreglo...

Pero bueno, al turron (y no a las 4 tabletas que me he comprado esta tarde de oferta en el Dia :-P ): los cambios que le he metido a Gaia realmente han sido numerosos, y la verdad que esta quedando una base muy buena para continuar con el desarrollo mas adelante. Para empezar, he estado estandarizando muchas funciones y poniendolas en comun entre Gaia y Uranus, lo cual teniendo en cuenta que ahora se contruyen como dos librerias estaticas por separado (en prevision a que mas adelante Uranus sea un ejecutable independiente) me esta sirviendo para hacerme una stdlib bastante cuca y quizas tambien para en el futuro poder usar newlib, que siempre sera mejor que desarrollar mi propia libreria estandar (aunque no es tan dificil como parece...), y ademas todo apunta a que va a ser la unica manera que voy a tener para poder usar memoria dinamica, porque el tema de la paginacion se me resiente y parece que el tutorial que estaba siguiendo ya solo existe en la cache de Google... :-/ Lo cual no es malo, porque buscando alternativas he descubierto que aunque con no excesivo exito, si ha habido intentos (algunos incluso formales) de hacer una API estandar para drivers, lo cual me viene bastante interesante... :-) Tambien es cierto que lo estoy procrastinando bastante por el respeto que me impone, pero al menos me sirve para avanzar en otros aspectos :-)

Pero lo mas importante sin lugar a dudas, ¡los eventos ya funcionan! :-D Por el momento de forma muy rustica y simple por no tener memoria dinamica y estar corriendo todo en espacio de kernel, pero al menos demuestran que el concepto y la arquitectura funcionan. Ademas, el diccionario de tamaño estatico que me he hecho me ha quedado chulisimo, para que luego vayan y me suspendan Estructura de Datos por no saber Pascal... :-P Por el momento solo tengo un evento registrado, "putchar", que es llamado desde prinf(), pero lo registra y lo recoge el driver de la VGA sin problemas, pero teniendo en cuenta que printf() esta dentro de la stdlib por el momento vamos bien :-) Tambien he implementado un pequeño driver para el teclado, pero es mas bien simbolico ya que lo unico que hace es enviar lo que escribe a la pantalla enviando el evento de "putchar" igualmente, luego no se registra ni nada. Por el momento se estan registrando los IRQs directamente, asi que cuando ya haga que pasen por el gestor de eventos ya me pondre a hacer algo serio, ya que tambien tendre que definir el formato de los eventos y eso puede variar mucho, asi que prefiero no hacer demasiado que luego tenga que tirar a la basura.

Y luego por ultimo en el dia de hoy despues de la paliza que me pegue ayer a patear calles pues me he tirado todo el dia en casita limpiando y organizando el proyecto como dije antes, separando cada parte, unificando librerias... dejandolo preciosista :-D Tambien he estado experimentando ahora que se compilan Gaia y Uranus por separado en que la interfaz de las syscalls sea la misma que en nativo, pero el linker se ha quejado diciendo que los simbolos estan duplicados (lo cual es obvio, idiota de mi). Mañana vere si consigo hacer algo al respecto con algun flag al compilar o algo, que seguro que hay alguna solucion... ;-)

Übersecret

¿Y cual es ese nuevo proyecto en el que ando enfrascado tan secreto que a pesar de ser uno de mis proyectos "gordos" solo hay tres personas que conocen de su existencia y entre las tres apenas la entienden media? :-P Pues mi mayor sueño desde los 10 años, el cual ya intente anteriormente dos veces de forma infructuosa y como bien supuse, el desarrollo de PirannaFS me iba a dar la autoconfianza que necesitaba para desarrollarlo de forma definitiva: mi propio sistema operativo... o cuanto menos, mi propio kernel :-D

ChaOS (originariamente CaOS... cosas del marketing y la proyeccion internacional :-P ), el estado desorden primigenio que dio lugar a "el origen de todo", es un sistema operativo puramente orientado a objetos (al igual que el extinto BeOS o su sucesor Haiku) y a eventos (como los sistemas operativos en tiempo real), y diseñado por completo orientado a que sea facil de entender y de mantener. Bajo esta filosofia prescinde por completo de los IOCTLs y compañia: todo son objetos. En este aspecto es diametralmente opuesto a Plan 9, que aunque la idea de llevar Unix al extremo haciendo que "todo sean archivos" esta muy bien... realmente solo es practica para su uso desde la shell. No obstante, si se integrara con Python y potente introspeccion y sus tan extendidos "file-like objects" (acceder a cualquier objeto de forma estandar usando los metodos definidos para los archivos) se podria crear un sistema de programacion bastante versatil y poderoso (y de hecho incluso intente hacer recientemente que ChaOS estuviera escrito en Python para poder explotar esta idea), aunque claro, aqui hay un detalle importante... son objetos ;-)

Sin embargo, vamos a empezar por lo importante: el kernel. El kernel de ChaOS para aumentar su claridad, seguridad y versatilidad se divide (dividira, en realidad) en dos partes: un microkernel (Gaia, "la madre tierra") realmente minimo que corre en el anillo 0 que solo actua como envoltura del hardware para permitir un acceso mas homogeneo y controlado por parte del resto del software al estilo de los exokernels o los hipervisores (calculo que no deberia necesitar mas de 7 syscalls en total), y luego el kernel propiamente dicho (Uranus, "el padre del cielo"... e hijo y amante de Gaia :-P ) que corre puramente en espacio de usuario. Si, como un programa mas, ahi esta la gracia del asunto: al estar el kernel en espacio de usuario y no ejecutar codigo privilegiado se obtienen varias ventajas, como que el codigo privilegiado es mucho menor, es mas facil de programar y de depurar... e incluso estoy observando que no me costaria demasiado hacer que "cualquier" programa (notense las comillas, no obstante) se podria hacer que funcionara directamente sobre Gaia sin demasiado esfuerzo... o incluso hacer que Uranus corra como una aplicacion mas el cualquier otro sistema operativo o incluso propiamente dentro de ChaOS (el colmo de la recursion: un sistema operativo corriendo sobre si mismo sin maquinas virtuales. ¿Donde deja eso a jail? :-D ).

Por el momento, he conseguido que Gaia sea capaz de arrancar desde GRUB dentro de QEmu (ya es mas de lo que habia conseguido hasta ahora...) y tambien registra un pequeño driver en espacio para usuario para el PIT y estoy en proceso del driver de la tarjeta de video en lugar de acceder a ella directamente desde el modo kernel. Vale, lo reconozco, es mentira: todavia estoy ejecutandolo todo en espacio kernel, pero la paginacion me estaba dando problemas por lo que decidi adelantarme con la API, y actualmente ya estan funcionando correctamente a traves de las syscalls (de momento solo 3: in, out y register_interrupt_handler). Aparte el codigo es muy homogeneo y claro entre si, y aunque lo este haciendo en C ya que las otras veces que intente hacerlo en C++ fueron callejones sin salida, los namespaces son muy claros de seguir y no costaria demasiado hacer la conversion en el futuro. Vamos, una joyita de las que me gustan, codigo limpio y claro... :-D

Ahora que he terminado los examenes me pondre con el motor de eventos para asi poder aislar mas aun cada una de las dos partes (Gaia y Uranus) y que el driver de la VGA este completamente en el "pseudo" espacio de usuario. Despues ya continuare intentando la paginacion de memoria y la ejecucion en espacio de usuario de verdad, y luego ya creo me planteare si continuar con el desarrollo de Gaia como un cargador de kernels en espacio de usuario como habia pensado hasta ahora, o bien como libreria que añadir a aplicaciones estandar para que se ejecuten sin sistema operativo... o bien como las dos cosas :-D

P.D.: tengo que irme, el sistema de megafonia de la universidad avisa que tenemos que desalojar el edificio, dicen noseque de unos "egometros" que se han salido de su escala...

:-P