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 ).