Toro kernel

IOAPIC soportado!

2012-01-05T13:09:00.000-08:00

Acabo de subir al repositorio GIT las modificaciones necesarias para utilizar el controlador de interrupciones IOAPIC en vez del antiguo 8259 en entornos multicore.

El 8259 es el controlador estandar de interrupciones. Con el surgimiento de los procesadores con más de un core el 8259 fue reemplazado por el IOAPIC y el LAPIC, aunque se preservó por compatibilidad. En general, cada PC tiene un IOAPIC que recibe las IRQ y las dirige a los LAPIC, cada procesador posee uno propio.

El problema con el 8259 es que todas las IRQ son capturadas por el BSP, o procesador de booteo. Esto claramente va encontra de la política de dedicación de recursos seguida por TORO.

De esta forma, en sistemas multicore, cuando se dedica un hardware a un core dado, las IRQ serán capturadas por ese core, descongestionando el procesador de boot.

Matias E. Vara
www.torokernel.org

Importante bug solucionado en la migración de threads

2011-12-12T20:21:00.000-08:00

A continuación describiré brevemente acerca del problema descubierto en la migración de thread y como fue solucionado, no ahondaré en detalles.

En las versiones anteriores de Toro, cuando un thread intentaba crear otro thread remoto, la función ThreadCreate era ejecutada localmente y eran alocadas las estructuras: TThread, TLS y el Stack. Luego la estructura completa era migrada al core remoto.

El problema en este procedimiento era que los bloques de memoria TThread, TLS y Stack ya no eran locales lo cual significa una grave infracción en el modelo NUMA.

De este modo, se reemplazó la migración de la estrucutura TThread por la migración de un conjunto de parametros tales como: tamaño de pila, puntero al código de ejecución, etc. Así, ThreadCreate es ejecutado remotamente y le son pasados los parámetros guardados en esta estructura. Como antes, se retorna al thread padre el ThreadID del recien nacido.

Se puede observar que mientras la creación de un thread local es instantánea, la creación de un thread remoto involucra dos pasos: primero se migran los parámetros y luego se retorna el identificador de thread.

Parcheando GDB 7.3 para debug remoto

2011-08-25T19:43:00.001-07:00

Esta vez voy a mostrar como parchear GDB 7.3 con el fin de debuguear de forma remota un kernel corriendo sobre la maquina virtual QEMU. Cuando corremos GDB e intentamos debuguear de forma remota nos retorna el siguiente mensaje de error:

Remote packet too long: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ...

No estoy muy seguro del origen del problema pero parece que es por el tamaño de los registros. Cuando la máquina virtual salta de modo real a modo long o protegido, los registros cambian su tamaño pero GDB no detecta esta situación. Asi, cuando GDB recibe un paquete más grande que el esperado, tira este error. De esta manera, el parche implementado solo se encarga de incrementar el buffer de recepción cuándo suceden aquellos casos.

El primer paso es bajarse el source de GDB 7.3 desde http://www.gnu.org/s/gdb/download/, no estoy seguro si funciona en versiones más viejas pero supongo que si.

Una vez bajado y descomprimido, editar el archivo gdb-7.3/gdb/remote.c, línea 5693. Aqui nos encontramos con el procedimiento process_g_packet. Ahora será necesario buscar y reemplazar el código original por las siguientes líneas:

/* Further sanity checks, with knowledge of the architecture. */

//if (buf_len > 2 * rsa->sizeof_g_packet)

// error (_("Remote 'g' packet reply is too long: %s"), rs->buf);

if (buf_len > 2 * rsa->sizeof_g_packet)

{

rsa->sizeof_g_packet = buf_len;

for (i = 0; i < gdbarch_num_regs (gdbarch); i++)

{

if (rsa->regs[i].pnum == -1)

continue;

if (rsa->regs[i].offset >= rsa->sizeof_g_packet)

rsa->regs[i].in_g_packet = 0;

else

rsa->regs[i].in_g_packet = 1;

}

Finálmente, solo resta compilar:

$ ./configure

$ make

Esto debería ser suficiente para ejecutar GDB correctamente.

Matias E. Vara

www.torokernel.org

Toro en el Congreso de Micro-electronica (UNLP)

2011-08-23T14:33:00.000-07:00

Presentaré un artículo referido al nucleo dedicado TORO en el Congreso de Microelectrónica a desarrollarse en la Universidad Nacional de La Plata, Facultad de Ingeniería. La presentación será el dia Jueves 8 de Septiembre a las 16.20 hs en la Sala A. La web del evento es http://www.ing.unlp.edu.ar/uea2011/ para mayor información. Saludos!

Matias E. Vara

www.torokernel.org

Toro en Ubuntu 11.04!

2011-07-30T15:43:00.000-07:00

Finalmente es posible compilar TORO en Linux Ubuntu 11.04. Supongo que de aquí en más trabajaré solo sobre esta plataforma. También he dejado de utilizar SVN para comenzar con GIT.

En el wiki pueden encontrar el procedimiento para instalar y testear TORO en ubuntu. He realizado algunos cambios en la estructura del proyecto con el fin de facilitar la comprensión y permitir un mejor crecimiento del proyecto. Saludos.

Matias E. Vara

www.torokernel.org

Toro bootloader

2011-06-24T04:45:00.000-07:00

Como puedo empezar?. El bootloader es un proyecto en sí mismo. Si se quiere escribir un OS por Hobby, no hay que empezar por el bootloader claramente. Lleva tiempo, el debug es oscuro y te vas a decepcionar rápidamente. Terminás, no haciendo nada y dejando el proyecto de escritura de un OS. Creo que lo más importante e interesante ocurre dentro del kernel, es decir, una vez que el SO ya ha sido cargado en memoria. De todas formas, hay gente loca por ahi que aun quiere armarse su propio bootloader. Dirigido a ese tipo de personas he comenzado a escribir un poco de documentación sobre el Toro's bootloader en el wiki. Espero que lo encuentren interesante y aprecien el esfuerzo hecho (si, no me gusta escribir documentación, pero reconozco lo importante que es ;) ). El conocimiento es tal, si y solo si, es comunicado.

Matias E. Vara

www.torokernel.org

Mecanismos de comunicación entre procesos

2011-05-04T13:40:00.001-07:00

Como se observó en el post anterior, es necesario disponer de mecanismos que sincronicen el acceso a variables compartidas. Los algoritmos más comunes para proteger recursos son: semáforos, paso de mensajes y spin-lock.

Estos mecanismos permiten hacer cumplir la exclusión mutua, requerida para el acceso a variables compartidas, es decir, que se garantiza que en un instante dado sólo un proceso está leyendo o escribiendo sobre la variable.

Los semáforos son manejados por dos primitivas P y V, ambas utilizan operaciones atómicas para incrementar y decrementar el contador del semáforo. Éstos son fáciles de implementar y requieren poca memoria.

Otro mecanismo muy utilizado es el paso de mensajes. Este permite el paso de información entre procesos. Las primitivas utilizadas son Send y Receiv. La principal ventaja de este mecanismo es que las partes intervinientes pueden ser totalmente independientes unas de otras.

Los spin-lock

Los procedimientos más utilizados para proteger recursos en sistemas de Multiprocesamiento en el entorno del kernel son los denominados spin-lock. Los mecanismos de comunicación antes mencionados son construidos internamente con spin-lock.

Los recursos son protegidos con variables de cierre denominados Locks, estas son variables binarias; la variable tomará el valor “1” si un proceso se encuentra utilizando el recurso o “0” si ningún proceso está utilizando el recurso. Cuando hablamos de recurso nos referimos a una dada variable del sistema.

Para modificar una variable Lock se utilizan operaciones atómicas, por ejemplo la instrucción: Test and Set. Esto garantiza que el procesador que se quede con el recurso sea uno solo.

El proceso que quiere acceder a una zona crítica permanece en un bucle realizando Polling hasta que la variable Lock vuelva a “0”. Cuando esto ocurre la vuelve “1” (esta última operación se realiza en un solo paso). Mientras la variable está en estado “ocupado” el proceso se encuentra en un bucle. El proceso saldrá del bucle cuando logre cambiar el valor de la variable Lock.

En sistemas con pocos procesadores un proceso suele estar poco tiempo en el bucle intentando modificar a la variable Lock. Pero a medida que incrementamos el número de procesos, este tiempo se vuelve crítico, y la solución simple de implementar un spin-lock para proteger recursos compartidos, debe ser re-evaluada.

Impacto del uso de spin-lock

En el test[1] realizado sobre 5 aplicaciones Linux, se compara el número de procesos involucrados y el porcentaje de tiempo que los procesos permanecen en el bucle de Lock (denominado Lock Overhead).

Para cada tarea se fue incrementando el número de procesos involucrados, cada uno trabajando en paralelo.

Se observa que a medida que más procesos se utilizan, más tiempo pasa la aplicación realizando Locking debido a la utilización de variables compartidas por todos los procesos. De esta manera si utilizamos variables compartidas estamos limitando la paralelización de una aplicación porque a medida que incrementamos el número de procesos involucrados la aplicación destina más tiempo en obtener el permiso para usar una variable compartida que para realizar trabajo efectivo.

[1] Yoav Etison, Dan Tsafrir et. al.: Fine Grained Kernel Logging with KLogger:

Experience and Insights. Hebrew University, 2005.

Matias E. Vara

www.torokernel.org

Protección de memoria en sistemas multicore

2011-04-14T14:29:00.000-07:00

Este artículo forma parte del trabajo final “Paralelización de algoritmos numéricos con TORO kernel” por Matías Vara, para el título de Ingeniería en Electrónica, Universidad Nacional de La Plata. Estos apuntes teóricos sirven para poder entender el diseño del núcleo.

Introducción

Cuando se diseña un kernel para un sistema multicore la memoria compartida deberá ser protegida de accesos de escritura concurrentes. Las protecciones que utiliza el kernel incrementan la complejidad del código y decrementan el desempeño del SO.
Si uno o más procesadores acceden a los mismos datos al mismo tiempo, en el caso de sistemas multitarea debe cumplirse la exclusión mutua para proteger a los datos compartidos.
Para el caso de sistemas monoprocesadores multitarea apropiativos ocurre que cada cierto tiempo el planificador cambia de tarea, por lo tanto el único riesgo que se tiene es que mientras los datos están siendo modificados por un proceso, el planificador decida cambiar de tarea. La protección implementada en este caso es sencilla: simplemente se deshabilita el planificador mientras el proceso está en su zona crítica y luego se habilita nuevamente.
En sistemas con más de un procesador esta solución no puede ser implementada. Esto es debido a que los procesos se ejecutan en paralelo en los diferentes procesadores y puede existir otro proceso ejecutando la misma línea de código al mismo tiempo; por lo tanto de nada serviría inhabilitar el planificador del procesador local.

Metodos de proteccion de recursos

Para poder proteger recursos en sistemas con multiprocesamiento primero debemos definir operaciones atómicas. Estas son operaciones que si bien pueden estar constituidas por pasos más pequeños conforman un paquete indivisible de ejecución.

Operaciones atomicas

En los microprocesadores las operaciones tanto de escritura como de lectura tomadas de forma individual son siempre atómicas. Esto quiere decir que se garantiza que la operación terminará antes que cualquier otro procesador acceda a esa región de memoria.
Para ciertas operaciones el procesador utiliza el bloqueo del bus de memoria para controlar la lectura o escritura de una región. Para ello se proporciona la línea de control #Lock que es levantada cuando se realizan operaciones críticas de memoria. Mientras esta señal está en alto, las solicitudes provenientes de otros procesadores son bloqueadas.
El acceso al bus es no determinístico; esto quiere decir que el procesador que se quedará con el bus es el que llegue antes. Cada procesador compite con el resto, lo cual es un problema a medida que incrementamos el número de procesadores.
Pero ¿Por qué son necesarias las operaciones atómicas? Supongamos que queremos incrementar una variable contador, el código Pascal de esto sería:

contador = contador + 1 ;

Si esta línea se ejecuta simultáneamente en dos procesadores el resultado será incorrecto sino se utiliza protección.
El valor correcto de contador es 2 pero utilizando instrucciones que se realizan de forma atómica.
Al utilizar operaciones atómicas los procesadores se sincronizan para modificar de a uno la variable, y el resultado es correcto. El tiempo necesario para sincronizar la ejecución de la instrucción se incrementa con el número de procesadores que intentan acceder a la variable.

Las operaciones atómicas más comunes son TEST and SET y COMPARE and SWAP.

Impacto de las operaciones atomicas

La utilización de operaciones atómicas en sistemas con pocos procesadores no supone una gran carga para el sistema y es una solución rápida a problemas de memoria compartida; pero a medida que incrementamos el número de procesadores éstas se tornan en un cuello de botella.
Si suponemos una PC con 8 núcleos de 1.45 GHz cada uno [1], mientras que el tiempo consumido en promedio por instrucción es 0.24 ns, una instrucción de incremento atómico demora 42.09 ns.
Es claro que el tiempo consumido por las operaciones atómicas empieza a ser crítico.

[1] Paula McKenney: RCU vs. Locking Performance on Different Types of CPUs.
http://www.rdrop.com/users/paulmck/RCU/LCA2004.02.13a.pdf, 2005

Matias E. Vara
www.torokernel.org

Organizacion de memoria en arquitecturas multicore: Conclusion.

2011-04-05T14:59:00.000-07:00

Desde la perspectiva del programador, la memoria remota y la local se acceden de forma transparente. En teoría un sistema NUMA podría implementarse en un sistema SMP sin problemas. Sin embargo el SO debería realizar un manejo eficiente de la asignación de memoria para sacar provecho a estas tecnologías.

Una de las principales ventajas del acceso uniforme a memoria es que la administración de la memoria por parte del SO es fácil de implementar, mientras que en un sistema de NUMA, no. El SO deberá asignar memoria a los procesos dependiendo sobre qué CPU esta ejecutándose y exige que se tenga un banco de memoria para cada CPU. La performance se degrada rápidamente si prevalecen los accesos remotos sobre los locales.

El SO Windows soporta NUMA desde la versión Server 2003 e incluye un conjunto de llamadas al sistema que permiten al programador explotar este recurso. Por otro lado Linux también es compatible con NUMA a partir de la versión 2.6.X.

Este aspecto se tuvo en cuenta en el desarrollo del kernel dedicado con el fin aprovechar las nuevas tecnologías NUMA presentes en los procesadores modernos. La única manera posible por el momento de optimizar los accesos a memoria en sistemas multicore es a través de buses dedicados y con un modelo de memoria NUMA. En especial en entornos de alta performance estas optimizaciones no pueden ser no tenidas en cuenta.

Matias E. Vara

www.torokernel.org

e1000 driver para TORO

2011-03-13T04:37:00.000-07:00

He comenzado el desarrollo del driver para tarjetas de red del tipo e1000, Intel Gigabit o compatibles. Estoy usando de base el codigo de Minix3 el cuál es muy claro y como emulador el qemu. La version 0.12.0 permite emular la placa e1000.
Aquí les pongo un screen de la detección y lectura de la MAC, por ahora es lo que tengo en el SVN.
Saludos!.
Matias E. Vara
www.torokernel.org

Organizacion de memoria en arquitecturas multicore II

2011-03-05T14:58:00.000-08:00

Continuación del artículo "Organización de memoria en arquitecturas multicore".

Arquitecturas de memoria no uniforme.

Las arquitecturas de memoria no uniforme (NUMA por sus siglas en inglés) utilizan (como en SMP) un único espacio de direcciones, pero en este caso cada procesador es dueño de una parte de la memoria, a la cual puede acceder más rápido. Utiliza pasaje de mensajes escondido para el acceso a memoria remota.

En un entorno NUMA el programador puede acceder de forma transparente a cualquier posición de memoria y es el hardware quien crea esta abstracción.

Unas de las pioneras en tecnología NUMA fue la empresa Sequent Computer Systems, quien introdujo los sistemas de multiprocesamiento y diseño de memoria NUMA a comienzo de los ‘90. Luego fue adquirida por IBM y estos desarrollos fueron implementados en los procesadores Power.

La arquitectura análoga a la NUMA desarrollada por IBM fue denominada SE (Shared Everything por sus siglas en ingles). En la actualidad esta tecnología se encuentra integrada en los procesadores Power6, los cuales la heredaron de los Power4.

La tecnología desarrollada por Intel se denomina QuickPath Interconnect, incluye un controlador de memoria en el chipset y permite compartir toda la memoria física entre los procesadores de forma transparente para el Sistema Operativo. Cada procesador posee un enlace punto a punto de alta velocidad.

AMD implementó el sistema de acceso a memoria no uniforme (NUMA) que permite la conexión entre procesadores a través de enlaces de alta velocidad denominados Hypertransport Links. En este diseño cada procesador posee su propio controlador de memoria y su propia memoria local. Cuando el procesador accede a la memoria local, la latencia es baja; mientras que si intenta acceder a memoria remota (memoria alocada en otro procesador) la latencia es alta.

Cada uno de los procesadores está conectado entre sí a través de un enlace coherente de Hypertransport de alta velocidad. Cada procesador posee un enlace bidireccional no coherente para dispositivos de entrada-salida y dos enlaces bidireccionales coherentes, que permiten la conexión entre los procesadores.

Los accesos punto a punto permiten acceder a ciertas regiones de memoria de forma más rápida y penaliza el acceso a otras. Por ejemplo en una PC con 2 GB de memoria y dos procesadores, se podría privilegiar el acceso al primer GB para un procesador y el acceso al segundo GB para el otro procesador. Cada procesador tendría su propio controlador de acceso a memoria y ya no sería requerido un bus compartido por ambos procesadores.

Cada CPU en un sistema NUMA pueden acceder a dos tipos de memoria: memoria local y memoria remota. La memoria local es aquella que se encuentra en el mismo nodo que la CPU, que se accede con baja latencia, y la memoria remota se encuentra en otro nodo, en otra CPU. La CPU debería acceder a través del nodo de interconexión para la memoria remota, el cual presentaría una alta latencia.

Matias E. Vara
www.torokernel.org

Organizacion de memoria en arquitecturas multicore

2011-01-15T10:28:00.000-08:00

Este artículo forma parte del trabajo final “ Paralelización de algoritmos numéricos con TORO kernel ” por Matías Vara, para el título de Ingeniería en Electrónica, Universidad Nacional de La Plata. Continuaré agregando partes de mi trabajo final al blog.

Organizacion de memoria en arquitecturas multicore

El sistema más común de multiprocesamiento utilizado en la actualidad es el de acceso uniforme a memoria (SMP por sus siglas en inglés).
En esta arquitectura cada procesador puede acceder a cualquier región de memoria independiente uno del otro. El acceso se realiza por un único bus compartido, o sea que cada procesador compite con el resto para escribir o leer. Los accesos se realizan de a uno por vez –es decir- que solo un procesador en un instante dado, puede utilizar al bus. Todos los procesadores son similares y tienen capacidades equivalentes. Todos los procesadores tienen el mismo tiempo de acceso a cualquier posición de memoria. En ambientes SMP el acceso a memoria por el programador es totalmente transparente.

El primer microprocesador de Intel con soporte para multiprocesamiento, fue el Pentium PRO en 1992. El bus utilizado para la interconexión de la CPU con la memoria fue denominado Front Side Bus (FSB desde ahora).

Este es un bus bidireccional muy simple; el costo es bajo y en teoría no hay límite acerca del número de procesadores que se pueden interconectar.

El siguiente paso dado por Intel para incrementar el ancho de banda del FSB fue dividir el bus en dos buses independientes. Sin embargo el ancho de banda se vio reducido debido al tráfico que debía ser reenviado por todo los buses para mantener los caches coherentes.

En 2007 se implementó un bus dedicado por procesador.

En la actualidad esta arquitectura es utilizada por los procesadores Atom, Celeron, Pentium y Core 2 de Intel.

A medida que se incrementaron el número de procesadores en las computadoras modernas también se incrementó el tráfico por el bus, convirtiéndolo en un cuello de botella y degradando la performance de la configuración SMP, fijando un límite entre 16 a 64 procesadores.

El FSB fue fuertemente criticado debido a que éste representa una barrera para las nuevas tecnologías emergentes multicore.

Mientras que una CPU puede ejecutar instrucciones rápidamente, esta velocidad será desperdiciada si no puede hacer la captura y decodificación de las instrucciones tan rápido como las ejecuta. Cuando ocurre esto la CPU debe esperar por lo menos un ciclo más de reloj hasta retornar el valor desde la memoria.

El FSB se comenzó a sustituir a partir de 2001 por dispositivos de acceso punto a punto como Hypertransport de AMD o QuickPath Interconnect de Intel, remplazándose el modelo de acceso uniforme por el modelo de acceso no uniforme.

Matias E. Vara

www.torokernel.org

Utilización de los anillos de privilegio del x86 en TORO

2010-12-30T18:04:00.000-08:00

En la arquitectura x86 existen 4 niveles de privilegio, siendo el anillo 0 el más privilegiado y el anillo 3 el menos. En un sistema operativo tradicional el nivel de mayor privilegio es del kernel y el de menor nivel es el del usuario.

Al usar un SO de uso general, el código y datos del kernel utilizan descriptores de anillo 0, mientras que la aplicación de usuario utiliza el anillo 3. La capacidad de la GDT es de 8192 descriptores pero estos no se utilizan en general, usándose solo 4 descriptores, dos descriptores para datos y código de usuario, y dos más para datos y código del kernel. Estos descriptores se utilizan para el acceso a toda la memoria, es decir, que permiten acceder a los 4 GB (caso del direccionamiento de 32 bits).

El hecho de utilizar diferentes niveles de privilegio agrega latencias debido a que el procesador deberá corroborar que cada acceso de escritura/lectura/ejecución es válido. En un SO de uso general la utilización de diferentes niveles de privilegios es totalmente necesario, permite que se ejecuten varios procesos y que éstos no se solapen; y por otro lado que aplicaciones mal programadas no sobreescriban código del kernel.

Si suponemos que corremos una aplicación dedicada multihilo, que ésta se ejecuta sola en el sistema y que la aplicación fue escrita con suficiente cuidado como para no realizar escrituras sobre zonas prohibidas, será necesaria la protección?, suponiendo una situación así podemos simplificar bastante el SO.

Primero, tanto la aplicación de usuario como el código y datos del kernel estarían en el mismo nivel de privilegio , por lo tanto, cuando debemos realizar una llamada al sistema no habría ningún salto de nivel de privilegio y se podrían implementar simplemente con la instrucción “call”. Recordemos que actualmente para soportar las llamadas al sistema se utiliza una interrupción que permite realizar el salto de nivel de privilegio de anillo 3 a anillo 0 y es muy costosa.

Segundo, cuando los dispositivos de hardware producen interrupciones y nos encontramos ejecutando código de usuario se producirán saltos de niveles de privilegio. Ésto se debe a que dejamos de ejecutar código de anillo 3 para ejecutar una rutina de manejo de interrupción que se encuentra en anillo 0. Si la aplicación de usuario se ejecuta en el mismo nivel del kernel nos ahorramos la latencia que presenta saltar a un mayor nivel de privilegio.

En el caso de TORO, el kernel y la aplicación de usuario se ejecutan en anillo 0, por otro lado, como ambos se compilan juntos, las llamadas al sistema son implementadas como simples instrucciones “call” a funciones del kernel.

Matias E. Vara

Ese viejo TORO

2010-11-27T08:09:00.000-08:00

Desde el 2006, año en el cual se vieron modificados los objetivos de TORO, se discontinuó el proyecto TORO OS correspondiente a las versión 1.x.x. Estas versiones lograron un gran éxito en cuanto funcionalidad. La versión más estable fue la 1.1.3, de vez en cuando me pongo a ver el source de esas versiones y me da mucha lástima haberlo dejado, de todas formas me era imposible llevar a cabo ambos proyectos de forma simultanea. Por eso he decidido hacer un pequeño homenaje a esas versiones. Para eso muestro a continuación como testear toro 1.1.3 a través de BOCHS. He puesto un par de screenshots para que observen la belleza de una shell en PASCAL. Diviértanse!

Par estas simulaciones es necesario BOCHS para x86, recuerden que las versión 1.1.3 son solo para 32 bits. Aquí les incluyo el contenido del archivo torobch.bxrc

megs: 256

romimage: file=BIOS-bochs-latest, address=0xf0000

floppya: 1_44=toro-1.1.3.img, status=inserted

boot: floppy

Es necesario bajar la imagen de toro-1.1.3 desde el link: http://sourceforge.net/projects/toro/files/images/toro-1.1.3/toro-1.1.3.img/download

Si todo anda bien, la primer ventana que verán cuando ejecuten BOCHS será:

Corresponde el bootloader GRUB, allí se elige la opción TORO-1.1.3 y se le da enter.

Comenzará a cargar el SO y luego la Shell:

Estamos listo para ingresar comandos a TORO. El primer comando que veremos es el ls que como todos ya sabrán lista el directorio actual.

Ahora vamos a ir hasta el directorio donde se encuentra el source de TORO utilizando cd.

Y vamos a ejecutar echo printk.pas esto despliega el contenido del archivo en pantalla.

Todos los comandos de la Shell los pueden ver en el directorio /BIN como es de esperar, estos son:

Bueno ejecutando reboot el sistema es cerrado y podemos apagar tranquilos la maquina virtual.

Espero que les haya gustado, hagan sus propias experiencias ejecutando comandos. También pueden quemar la imagen en un disket de 3 ½ y probarlo en una maquina real.

ATENCION: Las versiones 1.x.x no tienen nada que ver con las versión 0.XX son cosas diferentes.

Matias E. Vara

www.torokernel.org

Toro Builder subido!

2010-11-20T15:27:00.000-08:00

Se encuentra disponible la interfaz de desarrollo de Toro, esta permite la compilacion y debug del núcleo muy fácilmente a través de ECLIPSE y QEMU, para bajarlo hacer click aqui pero antes visitar el nuevo WIKI de TORO para mayor información. Si hay alguien interesado en ser EDITOR del WIKI por favor contáctese conmigo a torokernel@gmail.com, saludos.

Matias E. Vara
www.torokernel.org

Cambio de Contexto

2010-11-10T15:24:00.000-08:00

En este artículo intentaré dar una breve descripción de qué es un cambio de contexto y en particular como lo implementa TORO en las versiones a partir de la 0.01. No hablaré acerca de cómo lo implementa TORO OS en las versiones 1.x.x, solo diré que utiliza cambio de contexto por hardware. En futuros artículos mostraré la implementación en pascal de todas estas ideas. Cualquier duda a las referencias! Diviértanse!.

Como sabemos el encargado de distribuir los hilos en un kernel es el planificador. A parte de implementar el algoritmo de planificación éste realiza el procedimiento de “cambio de contexto”. Al seleccionar un nuevo hilo, el planificador llena los registros del procesador con los valores que tenían justo antes de que el hilo invoque al núcleo (OJO este comentario está ligado al algoritmo de planificación de TORO que es el de hilo cooperativo).

Imagen 1. Procedimiento de carga de un Nuevo proceso.

En la arquitectura x86-64 algunos de los registros de uso general son RAX, RBX, RCX, etc. Además de éstos registros también deben ser actualizados algunos registros de sistema como son el CR3. Éstos guardan información acerca del directorio de páginas del hilo que va ser cargado. El procedimiento se denomina “Cambio de contexto” y es una operación crítica debido a que se ejecuta de forma continua por lo que debe ser muy rápida.

El procedimiento de cambio de contexto puede ser implementado tanto por software como por hardware.

Cuando se implementa por hardware, se hace uso de los mecanismos que brinda una arquitectura en particular para realizar el cambio de contexto. Por ejemplo, para la arquitectura x86, se utilizan las estructuras denominadas descriptores de tareas, estas se encuentran en la GDT (Global Descriptor Table) y cuando se debe cargar una nueva tarea simplemente se utiliza la instrucción “call” al descriptor de tarea (denominado en la literatura como TSS)[1].

Por otro lado, en la implementación por software, el cambio de contexto se realiza “a mano” y es una rutina escrita por el programador la encargada de salvar el valor de los registros.

A primera vista el cambio de contexto por hardware parece la opción más óptima debido a que no interviene el programador y se realiza de forma “automática”. Pero en general ocurre que en los cambios de contexto por hardware se guardan los valores de todos los registros, pero resulta que a veces no se están utilizando todos los registros. De esta forma la implementación por hardware puede no ser la más óptima.

Por este motivo el cambio de contexto implementado en TORO es por software, se utilizan técnicas de programación para no utilizar los mecanismos de cambio de contexto que brinda un hardware en particular. El planificador al seleccionar un nuevo hilo, carga en los registros del procesador los valores que corresponde al nuevo hilo, y luego comienza su ejecución; el hilo comienza su ejecución justo después del momento en que se llamó al procedimiento SysThreadSwitch.

Como el cambio de contexto se realiza siempre luego de haberse invocado a la función SysThreadSwitch, el planificador supone que en ese instante los registros del procesador no están siendo utilizados por la aplicación de usuario. De esta forma se limita únicamente a salvar el estado de la pila del hilo que debe ser removido. Para la implementación sobre la arquitectura x86-64, esto se logra salvando en la estructura TThread el valor del registro RSP, el cual guarda la posición dentro de la pila.

El cambio de contexto implementado en TORO es más rápido que el de hardware y que el implementado en un SO de uso general. La elección del método de cambio de contexto se encuentra directamente relacionado con el modelo de hilo cooperativo.

Así la utilización de cambio de contexto por software suma portabilidad y velocidad [2].

[1]. Intel. IA-32 Intel® Architecture Software Developer’s Manual. Vol3. 2004.

[2]. Osdev Wiki, Context Switching, http://wiki.osdev.org/Context_Switching.

Matias E. Vara

www.torokernel.org

Cambios en el SVN

2010-11-08T18:54:00.000-08:00

Estaré realizando algunos cambios en la estructura de directorios del SVN asi que tal vez esté fuera de servicio algunas horas. Recomiendo hacer un update de las carpetas.

Saludos
Matias E. Vara
www.torokernel.org

Presentacion de BugCON 2010

2010-10-28T14:29:00.001-07:00

Aquí les dejo el link a la presentacion que hice para BugCon 2010. Espero se diviertan, saludos.

Matias E. Vara
www.torokernel.org

Migracion de Hilos sobre TORO

2010-09-19T17:34:00.000-07:00

En ambientes multicore es preciso contar con la capacidad de crear hilos no sólo en el procesador local sino en procesadores remotos. TORO brinda la posibilidad de crear hilos en cualquier procesador, desde cualquier procesador, a través de la llamada al sistema BeginThread().
Podemos diferenciar dos procedimientos en el kernel:

- La emigración de hilos: cuando los hilos se dirigen hacia otro procesador diferente a donde se está ejecutando el hilo que los creo.
- La inmigración de hilos: cuando el procesador huésped encola en el planificador local a los hilos que provienen de otros procesadores.

Este es el único punto del núcleo en el cual se requiere de algún tipo de mecanismo de sincronización entre los procesadores para poder enviar y recibir los procesos que deben migrar. El mecanismo es denominado “Exchange Slot”, y permite la comunicación entre procesadores sin utilizar operaciones atómicas. En este caso particular, se utiliza para el envío de nuevos hilos, pero puede ser utilizada para el envío de cualquier tipo de datos.
Por cada procesador existe una estructura denominada TSchedulerExchangeSlot:

TSchedulerExchangeSlot = record
DispatcherArray: array[0..MAX_CPU-1] of PThread;
EmigrateArray: array[0..MAX_CPU-1] of PThread;
end;

Siendo MAX_CPU el número de procesadores y PThread un puntero a una estructura TThread. De la definición de la estructura, se observa que cada procesador posee dos arreglos (DispatcherArray y EmigrateArray), y cada uno puntea a un grupo de hilos.
El procedimiento de envío de hilos hacia otros procesadores puede ser descripto en tres niveles:
1 – El usuario invoca al procedimiento BeginThread()para crear un nuevo hilo, si el parámetro CPUID es diferente al identificador de la CPU local, el kernel sabe que este nuevo hilo deberá ser migrado, y entonces lo agrega a la lista ligada DispatcherArray[CPUID].
2 – Cuando se ejecuta el planificador del procesador local (se invoca la llamada al sistema SysThreadSwitch), el procedimiento Emigrating() chequea si alguna de las entradas del arreglo EmigrateArray[] es nula. De ser así, desplaza todos los hilos desde la entrada correspondiente a DispatcherArray[] hasta EmigrateArray[].
3 – Durante la planificación de un procesador remoto el procedimiento Inmigrating() chequea la entrada del arreglo EmigrateArray[] correspondiente a su CPUID de la estructura TSchedulerExchangeSlot de cada procesador. Si no es nula, esta contiene un puntero al primer elemento de una cola ligada de procesos que están intentando migrar hacia su procesador. El procedimiento toma la cola de hilos y los coloca en la lista de hilos listos para ser ejecutados, luego vuelve a la entrada en el arreglo EmigrateArray[] nula.
Es claro que el arreglo DispatcherArray[] es de lectura/escritura solo para el procesador local. Mientras el arreglo EmigrateArray[] es de escritura/lectura para el procesador local y remoto, pero que la escritura sobre éste es sincronizada a través de la utilización del puntero nulo.
El “Exchange Slot” no requiere de ningún procedimiento que involucre un “pooling” de una variable del tipo “Lock”, evitando la utilización de operaciones atómicas y todo lo que ellas conllevan.

La inmigración y emigración de hilos entre procesadores se realiza únicamente cuando se invoca al planificador -es decir- cuando el hilo cede el procesador al kernel. En ese momento el Sistema realiza tareas de mantenimiento. Como se observa en la figura, cuando se llama al planificador, éste primero realiza la inmigración de hilos, luego realiza la emigración de hilos, y finalmente realiza la planificación de un nuevo hilo para el procesador local.

Matias E. Vara
www.torokernel.org

Toro en BugCon 2010!

2010-07-22T18:05:00.000-07:00

Toro estará presente en BUGCON 2010, Mexico DF. Realizaré una presentacion mostrando las funcionalidades de TORO y que problemas viene a solucionar. Tambien hare una demostracion en vivo de la compilacion del nucleo y el testeo paso a paso utilizando Eclipse y QEMU. Espero verlos alli.
Aqui les dejo el link para ver a los otros expositores.

Saludos.
Matias E. Vara
www.torokernel.org

Debugueando TORO con ECLIPSE+QEMU en WIN64 , parte 2

2010-06-13T10:15:00.000-07:00

Bueno luego de mucho trabajo he logrado construir un entorno para compilar y testear TORO muy rápidamente utilizando ECLIPSE y emulando TORO sobre QEMU. Básicamente lo que hace ECLIPSE es ser la interfaz gráfica entre GDB y QEMU. Para esto estoy utilizando GDB en forma de debug remoto , caracterisca que esta presente en QEMU. Para entusiarmarlos aqui les pongo un pequeño video en Win64, esta medio desprolijo pero prometo hace un buen tutorial hacerca de eso.

Por otro lado estoy creando un paquete(como se en el video) con todas los ejecutables incluidos de forma de que simplemente sea bajar y ejecutar ECLIPSE, sin necesitar ninguna otra herramienta más.
El mismo procedimiento lo he hecho en Linux y funciona bien , como muestran los screenshot del post anterior.

Un saludo .
Matias E. Vara
www.torokernel.org

Debugueando TORO en Eclipse+QEMU sobre Win64

2010-04-12T06:42:00.001-07:00

Al intentar hacer lo mismo sobre Windows me encontré con un grave error en la aplicación GDB. Recordemos que para hacer el Debug , la IDE se conecta al gdbserver a traves del gdb cliente (gdb.exe).Al intenter introducir breakpoints , ocurria el siguiente error :

"Remote 'g' packet reply is too long:
> 0000000000000000000000000000000000000000000000002306000 "

Esto pasa cuando la maquina virtual llega al breakpoint y el gdbserver le enviaba información acerca del estado de la maquina al cliente . Luego de buscar este problema en otros foros , no encontré ninguna solución. Con cambiar la arquitectura, debería ser suficiente :

"SET ARCHITECTURE I386:X86-64:INTEL"

.En Linux esto funciono bien , pero no en Windows. Lo que ocurre es que cuando el cliente gdb se conecta a qemu , este le informa que los tamaños de registros corresponden al de una maquina en modo real de 16 bits. Pero cuando uno pone un breakpoint en el código de toro, la maquina virtual se encuentra en Modo Long con registros de 64bits , con lo cual el paquete enviado sobrepasa el tamaño fijado al comienzo de la conexion y gdb tira ese error.
Lo que hice fue recompilar gdb-7.0 en Win64 y aplicar un parche sencillo por el momento, pero que funciona muy bien. Subiré mi versión de GDB en el próximo paquete que estoy construyendo con todas las herramientas para compilar y testear TORO incluidas.

Saludos.
Matias E. Vara

Debugueando TORO en Eclipse+QEMU

2010-04-05T19:52:00.000-07:00

Hola, luego de mucho tiempo buscando la herramienta ideal para compilar y testear toro rapidamente creo haberla encontrado. Casi de casualidad me encontre con la IDE Eclipse y la posibilidad de debugear Linux desde la IDE , y por otro lado encontre un plug-in para dar soporte al lenguaje pascal desde Eclipse. Uniendo estas dos herramientas pude compilar y ejecutar toro paso a paso , linea por linea , colocar breakpoints , etc . Resulto ser una muy potente herramienta que permitira encontrar problemas facilmente. Estoy utilizando la ultima version de Eclipse en un Ubuntu de 64 bits.
Aqui subo un par de screen para motivarlos. Todavia no lo tengo funcionando al 100% .
Pantallas de la ejecucion paso a paso :

Esta es la ventana de qemu que estaba utilizando.

Saludos.

Lazarus + GDB + QEMU

2010-01-07T08:44:00.000-08:00

Estoy trabajando duro para obtener una plataforma para compilar y testear TORO de forma rapida y facil . Para esto estoy haciendo modificaciones sobre el codigo de Lazarus . Lazarus es una IDE para el compilador FREEPASCAL. Estas modificaciones haces posible que cuando se ejecuta "RUN" en la IDE , esta realiza :
- Genera toro.exe
- Genera la imagen booteable de toro .
- Corre QEMU
- Permite debuguear TORO directamente desde la IDE utilizando un cliente GDB.

Saludos.
Matias E. Vara.

Charlas sobre TORO en la UNLP

2009-12-27T17:39:00.000-08:00

Hola, he estado pensando organizar una charla sobre TORO en la Universidad Nacional de La Plata. calle 1 y 47 , La Plata , Buenos Aires , Argentina .
Las tematica seria :
- Origen y Objetivos.
- Compilacion.
- Testeo.

Se realizaria a fines de Febrero 2010 . La gente Interesada por favor comente, asi se que cantidad de gente esperar.

Saludos.
Matias Vara.

NOTA: Por el momento no he podido coordinar la charla , cuando tenga alguna novedad la postearé.

Manejador de Cache del procesador

2009-10-27T18:48:00.000-07:00

Estube trabajando en alguna manera de manejar de forma mas eficiente el Cache del procesador(L1,L2 Y L3) . Para esto he escrito dos procedimientos en la unidad Arch.pas para marcar como cacheable o no-cacheable una pagina. En un primer momento se cachea solo el codigo y datos del kernel y de la aplicacion de usuario, queda en el usuario definir otras posibles regiones de cacheo.
Si es posible saber cuales regiones de memoria son las mas accedidas , sera posible optimizar el uso del cache del micro.
Ya he subido el codigo al SVN , pero todavia me faltan las syscalls para el usuario que implementare en la unidad Memory.pas
Saludos .
Matias E. Vara

Compilando Toro sobre Linux II

2009-08-26T21:05:00.000-07:00

He subido al SVN las modificaciones al programa Build para dar soporte a ejecutables en el formato ELF y poder crear la imagen booteable desde Linux. Build toma el archivo ejecutable(ya sea PECOFF o ELF) y lo convierte al fichero ToroImage.img.
Los pasos para la compilacion sobre Linux es :
1 - Hacer un UPDATE sobre la carpeta SVN donde se encuentre el codigo de TORO.
2 - Ejecutar en la terminal "sh compile.sh"
3 - Si la compilacion fue correcta el resultado es el fichero ToroImage.img para testear el sistema en una maquina virtual como QEMU. Yo he realizado la compilacion usando fpc 2.2.4 for x86-64 y funciono .
Tal vez sea necesario editar el archivo compile.sh para colocar las rutas a los ejecutables como build y fpc de forma correcta .
Cualquier opinion estoy a la espera .

Saludos .
Matias Vara.

Compilando TORO sobre Linux .

2009-08-23T14:26:00.000-07:00

He subido al SVN las modificaciones necesarias para compilar TORO sobre Linux , usando FPC 2.2.4 for x86_64 . Al correr compile.sh se compila el nucleo y se genera un ELF , todavia me encuentro trabajando sobre el Build para que pase del formato ELF a la imagen, tal como lo hace para ficheros PECOFF64.
Saludos. Matias Vara

Primera implementacion del TCP-Stack con Multiplex IO al nivel del kernel

2009-08-10T18:43:00.000-07:00

Como dice en el titulo , he subido la primera version de Stack TCP con sus Apis reescritas de forma de implementacion acceso a los socketes no-bloqueant y reducir el numero de cambios de contextos de forma drastica . Prometo liberar los Manuales de compilacion y programacion pronto.
Saludos.
Matias E. Vara

Implementacion de Taskfreak!

2009-05-30T19:28:00.000-07:00

He implementado el administrador de Tareas Taskfreak! que provee SourceForge. Alli he puesto todas las tareas que estoy realizando para el proyecto y cuales se estaran realizando proximamente, tambien informan el plazo de finalizacion y el porcentaje de realizacion .
Saludos

PD: El link

Multicore hecho!

2009-05-19T19:22:00.000-07:00

He subido al SVN las ultima version de TORO. He agregado soporte para la deteccion de microprocesadores con mas un core.He testeado esta version sobre la arquitectura Intel x86-64 y ha funcionado muy bien.
Se han solucionado gran cantidad de problemas en la unidad de Memoria , y se ha reemplazado el mecanismo para el calculo de la memoria fisica disponible por la informacion obtenida a traves de la INT 15H.

Se buscan Comentarios!

2009-03-31T20:55:00.000-07:00

Estoy reescribiendo los Manuales de compilacion y desarrollo sobre TORO , cualquier aporte sera muy util.
Saludos .

Matias E. Vara

Codigo de Toro subido al SVN de sourceforge

2009-02-18T13:10:00.000-08:00

He subido la version con la que estoy trabajando al Repositorio SVN de Sourceforge.
La idea es manterner lo mas actulizado posible el repositorio para no tener que estar esperando un paquete durante un año , por ejempo .
Se puede acceder desde la pagina de sf o desde este link .
Saludos , Matias E. Vara.

Compilando TORO con FPC 2.2.3

2008-07-13T15:54:00.001-07:00

He modificado la unidad system.pas para poder se compilada con FPC 2.2.3 partiendo de la RTL para win64 . Esta implementacion se vera en la proxima version.
Saludos .

Toro 0.03 esta listo!

2008-03-25T13:49:00.000-07:00

Se ha implementado el Stack TCP-IP y se ha creado un driver para tarjetas de red ethernet ne2000 , tambien se han solucionado gran cantidad de bugs .
Saludos Matias Vara .

Toro Habla!

2007-12-30T09:21:00.000-08:00

Bueno luego de un gran periodo de inactividad debido a mis estudios he retomado el Stack TCP-IP , en el screenshot se puede ver a TORO respondiendo un telnet , ha sido una ardua tarea pero va encaminada , en muy poco tiempo tendre lista la nueva version .
Un saludo Matias E. Vara

Articulo sobre Sistemas Operativos

2007-10-01T19:18:00.000-07:00

Aqui les dejo el link a un articulo que he publicado en la Revista SL , espero sus comentarios ,
Un saludo Matias Vara .

Trabajando con Stack TCP-IP

2007-07-16T09:01:00.000-07:00

Hola, dejo este post para comentar por donde ando con TORO, ahora me encuentro desarrollando un driver para la placa de red ne2000 , tambien he desarrollado un Cache para la manipulacion de gran cantidad de paquetes , y me encuentro escribiendo los drivers para los protocolos del stack tcp-ip .
Espero poder liberar todo el Stack TCP-IP para la version 0.03
, un saludo Matias E. Vara .

Toro 0.02

2007-05-15T21:47:00.000-07:00

La version 0.02 de Toro ya esta lista , implementa un Sistema de Archivo Virtual y drivers para discos ATA y EXT2 Filesystem. Es recomendable bajar la documentacion actualizada para su compilacion de http://toro.sourceforge.net
Un saludo Matias Vara.

Trabajando en el Filesystem

2007-02-23T13:54:00.000-08:00

Hola, dejo este post para comentar en que estoy trabajando . Me encuentro escribiendo los drivers para discos ATA con soporte de 8 unidades . En un futuro proximo lo actualizare para disco SATA con la controladora AHCI de Intel , de la cual es la unica que se encuentra informacion en la red.
Por otro lado estoy escriiendo un Filesystem tipo el Virtual Filesystem y pienso crear un driver minimo para EXT2.
Espero todo esto poder entregarlo en la proxima version .
Un saludo Matias Vara.

Toro 0.01 !

2007-01-27T13:25:00.000-08:00

Bueno luego de 6 meses de trabajo renace TORO , en breve subire documentacion explicando paso a paso su compilacion , las caracteristicas las pueden encontrar aqui .
Un saludo Matias Vara.

Algun Screen.

2007-01-23T16:00:00.000-08:00

Aqui les dejo un ScreenShot de Toro 0.01 booteando sobre un AMD x86-64 con SMP en QEMU:
https://sourceforge.net/project/screenshots.php?group_id=109734&ssid=51547

Buenas Nuevas

2006-12-07T14:48:00.000-08:00

Toro sigue vivo , silencio significa mucho trabajo ,supongo que en dos meses liberare un nuevo paquete , ya he portado gran parte del codigo de la RTL para Win32 como el driver de memoria , driver the threads , soporte para Multiprocesamiento paralelo (ya lo he emulado con bochs con hasta 8 procesadores) .
La idea -repito- es poder dividir una aplicacion en miles de threads ejecutandose en paralelo , para eso se implemento un modelo de thread cooperativo , tambien se implementaron mejoras como cambios de contextos por software , no se utiliza la instruccion "lock" , etc .
Todo incluido en una RTL para FPC .
Un saludo Matias Vara .

Toro rtl

2006-08-04T17:05:00.000-07:00

Hola , bueno querria poder explicar un poco en que estoy trabajando en este momento , puesto que la direccion del proyecto se modifico bastante de la original .
Bueno como sabran freepascal posee la unidad rtl que crea una capa de abstraccion entre el s.o. y el compilador con lo que hace que portar fpc a culaquier sistema resulte una tarea dentro de todo facil . La unidad rtl de la version 2.0.2 de fpc posee versiones para linux , win32 , unix , beos , etc , yo mismo he hecho una rtl para toro utilizando la version 1.0.6 de fpc , pero que resulta no compatible con la version 2.0.2 . Luego de este preambulo , les pasare a comer el rumbo de toro , estoy trabajando en una rtl para fpc 2.0.2 la cual posee incluida en la misma rtl todo el codigo del sistema operativo , en este caso Toro . Por lo tanto cuando conmpilas un prog utilizando esta nueva rtl se genera una ejecutable booteable en grub que incluye todo el kernel y el programa de usuario .Ustedes diran que ventaja trae aparejado esto para el usuario final , bueno el kernel tendra soporte para multiprocesadores , soporte para procesadores de 64 bits , stack tcp ip , y un monton de otras caracteristicas en cuanto a cambios de contextos , proteccion de exclusion mutua , tecnologia multitransport , etc . El programa de usuario tiene acceso a todas estas caractericas a traves de la rtl , y todos los recursos de la maquina a su alcance (hablamos de grandes maquinas) , no hay s.o. intermediario .Para una simple aplicacion pascal no hay mejora pero para servidores , programas de tiempo real y procesos que necesitan rapidas respuesta , se buscara ir por esos usuarios . Bueno me gustaria mucho que comenten hacerca de las utilidades que se le puedan dar a esto y sus dudas , un saludo Matias Vara .

PD : Por supuesto que sera una ardua tarea , pero ya he comenzado .

Toro 1.1.3!

2006-05-19T15:27:00.000-07:00

Bueno aqui subo tal vez la ultima version de Toro para fpc 1.0.6 en la que estaba trabajando antes de virar rumbo a 64 bits . Esta cubre un gran cantidad de bugs referidos al fs y al tratamientos de los nombres de archivos .

Un saludo Matias Vara .

Aqui les dejo los links para bajar un version minimal de fpc 1.0.6 y el linkeador ld necesario , este corre con cygwin 2.427 o superior .

Rumbo de Toro

2006-05-10T16:00:00.000-07:00

En este momento han surgido cosas que me han hecho virar el rumbo del proyecto Toro , por lo tanto no se como seguire con la distruibucion del codigo , los mantendre lo mas actualizado posible.
Aqui citare a grandes rasgos los nuevas implementaciones a realizar en el futuro a largo plazo :
- Traduccion de Toro a fpc 2.x.x
- Portar toro 32 bits a 64 bits . Soporte Multicore y Multiprocesadores .
- Implementacion de un stack TCP/IP
- Creacion de drivers para discos SATA .

Bueno a groso modo este sera el nuevo camino .

Un saludo Matias E. Vara

Toro 1.1.2 !!

2006-02-18T17:30:00.000-08:00

Bueno luego de casi 6 meses de no publicar nada , libero todo de golpe! .

He subido 4 nuevos paquetes , los cuales pueden bajar de aqui.

Aquí pasare a explicar cada uno :

Toro-1.1.2-src.zip y toro-1.1.2.img :

Source de la nueva versión de Toro , esta implementa las siguientes mejoras :

- Timers del kernel .
- Reescritura del planificador .
- Son escritas algunas llamadas al sistema faltantes en el VFS , y son solucionados gran cantidad de bugs .

También subo la imagen de un disquete de 3 ½ para aquellos que no quieren tener que compilar todo el source .

fpc-1.0.6-rtl-toro-bin y fpc-1.0.6-rtl-toro-src :

Después de mucho trabajo porte la librería rtl de freepascal 1.0.6 para toro . Es bastante simple pero permite generar aplicaciones directamente desde FPC , por ahora solo para la versión 1.0.6 .

Incluyo los binarios compilados que deberan ser extraídos en fpc/units/target , donde target puede ser : win32 , go32v2 ,depende para el sistema que fue bajado .
Cuidado que los archivos son sobrescritos , por lo tanto ya no se podrá compilador sobre la plataforma anteriormente instalada .

Y también he subido los sources , que deberan ser extraídos dentro de la estructura de directorios del source de freepascal en el directorio source/rtl/

Gracias ha esto he reescrito las aplicaciones de /USR/TOOLS , la shell la he hecho un poco mas “completa” , pero es bastante sencilla , espero que ahora alguien se anime y haga un shell como la gente .

Espero que disfruten de todo esto , tanto como yo cuando lo escribí .

Un saludo Matías Vara .

Estado actual de TORO.

2006-01-24T14:32:00.000-08:00

En este momento se esta optimizando todo el codigo de TORO , se ha modificado la planificacion , las irq , se han implementado los timers del kernel , se han modificado el driver de fdc , entre otras cosas .

Tambien se esta comenzado a portar FPC para TORO , lo que representara un paso muy importante puesto que la escritura de soft sera mucho mas facil .

La nueva version estara , supongo , para los primeros dias de Marzo 06 .

Un saludo , Matias Vara .

Implementación de colas ligadas en Toro

2005-12-26T15:58:00.000-08:00

Implementación de colas ligadas en Toro :

Las colas ligadas son un método eficaz para mantener agrupados una cantidad ilimitada de elementos . En Toro son utilizadas para agrupar los procesos , los timers , los superbloques , los inodos , los buffers , etc. , se le ha dado gran cantida de uso .

Podemos clasificarlas en dos tipo : simplemente ligadas o doblemente ligadas .

Por lo general las estructuras que se encuentran en una cola simplemente ligada posee solo un campo que apunta a la siguiente estructura y la ultima de la cola posee este campo a un puntero nulo , es decir solo pueden ser recorridas en un solo sentido .
A diferencia de estas , las doblemente ligadas posee dos campos una punteando a la siguiente estructura y otra a la anterior , pudiéndose así recorrerla en ambos sentidos y de manera cíclica .

La principal diferencia es para què van a ser utilizada . Por un lado las simplemente ligadas posee un campo menos , es decir ocupan menos memoria , pero si en la cola se están agregando y quitando elementos continuamente se consume mucha cpu , porque por cada elemento que debo quitar debo recorrer toda la cola para encontrar el anterior! .
Este problema se soluciona creando un nuevo campo apuntando al elemento anterior , así surgen las doblemente ligadas .
Es por eso que las colas que mantiene a los procesos , inodos , timers ,etc. , son colas doblemente ligadas , mientras que las colas que mantiene a los buffers que deben ser escritos a disco se encuentran en colas simplemente ligadas , cada buffer es agregado al comienzo y cuando deben ser quitados por la llamada sync() , se recorre la lista desde el inicio sacando de a uno todos .

Todo muy lindo , pero el hecho de que sean tan utilizadas hace necesarios procedimiento muy rápidos y eficientes , y este es el motivo del articulo .
Lo que se trato de crear fue procedimientos generales para el tratamiento de colas ligadas , tal como lo hace linux , pero en freepascal .

Todo el código del manejo de colas ligadas se encuentra en el archivo Include/Head/list.h

Este como se ve no es una unidad sino solo un archivo que debe ser incluido en la unidad luego de IMPLEMENTATION

Para que funcione deben ser declarados en la unidad cuatro símbolos ,de la manera tradicional , {$DEFINE Use_Tail} , estos son :

Use_Tail : le indica al compilador que el código de manejo de las lista debe ser incluido

nodo_struct : Debe contener la estructura de los elementos dentro de la cola , por ejemplo para una cola ligada de procesos valdría :

{$DEFINE nodo_struct = p_tarea_struc}

Siempre se considera a nodo_struct como un puntero .

nodo_tail : Puntea al elemento cabecera de la lista , puede estar definido o no .

next_nodo y prev_nodo : Estas estructuras poseen los campo dentro de los elementos de la lista que puntean al siguiente elemento y al anterior , por ejemplo para el caso de cola de procesos , estos valdrían :

{$DEFINE next_nodo = next_tarea }
{$DEFINE prev_nodo = prev_tarea}

El procedimiento para encolar un elemento , si se ha definido nodo_tail :

procedure Push_Node(Nodo : nodo_struct) ; inline ;

o en el caso de que no se haya definido nodo_tail :

procedure Push_Node(Nodo : nodo_struct;var Nodo_Tail : nodo_struct);inline;

La diferencia de que se defina o no nodo_tail , es la capacidad de trabajar en una unidad con mas de una cola ligada , puesto que de lo contrario se definiría un único valor para el símbolo nodo_tail , con esto se especifica el nodo cabecera de la cola en cada llamada .

Siempre el elemento es agregado al comienzo de la cola .

Ojo! nodo_tail no es una estructura sino solo un puntero al primer elemento de la cola .

Para quitar un elemento sucede lo mismo :

El procedimiento para quitar un elemento , si se ha definido nodo_tail :

procedure Pop_Node(Nodo : nodo_struct );inline;

o en el caso de que no se haya definido nodo_tail :

procedure Pop_Node(Nodo : nodo_struct;var Nodo_tail : nodo_struct);inline;

Como se ve todos los procedimiento son declarados como inline para acelerar su ejecución

Para hacer un poco mas “entendible” el código suelo definir otro símbolo que oculte a estos procedimientos :

{$DEFINE push_buffer = push_node }
{$DEFINE pop_buffer = pop_node }

Lo bueno de esto que definiendo un par de símbolos ya tenes todo el código para la manipulación de listas ligadas sin importar las estructuras , campos , etc .

Para el caso de colas simplemente ligadas , se debe definir el símbolo Use_Simple_Tail
para comenzar a trabajar con ella .
Igual que en el caso de las doblemente ligadas se cuenta con los procedimientos :

para agregar un elemento :

procedure Push_Snode (Nodo , sNodo_Tail : snode_struct);inline;

y para quitar un elemento :

procedure Pop_Snode (Nodo,sNodo_Tail : snode_struct);inline;

Ahora los símbolos nodo_struct y nodo_tail pasan a llamarse snode_tail y snode_struct respectivamente

Espero que les haya servido este pequeño articulo .
Una saludo

Matias E. Vara
Toro.sourceforge.net
matiasvara@yahoo.com

Generando un kernel con FreePascal

2005-11-06T15:11:00.000-08:00

Bueno tal vez el titulo no sea muy descriptivo pero básicamente lo que tratare de explicar es como generar un ejecutable en freepascal sin que este utilice llamadas al sistema , llevando obviamente a la caída del sistema .

A la hora de comenzar a escribir un S.O. la principal duda q se me planteo fue que compilador iba a utilizar . Elegí Freepascal , porque además de gustarme el lenguaje me era fácil portarlo puesto que es independiente del S.O. sobre el cual corra , esto no significa que no utilice llamadas al sistema sino que posee un capa de abstracción de llamadas primitivas las cuales son adaptadas al S.O. sobre el cual corra , es por eso que al compilador no le interesa el S.O. sobre el que se ejecuta .

En el caso de la versión 1.0.6 de FP utilizando el extensor go32v2 el tema es bastante fácil . Cuando se utilizan procedimientos y funciones dependientes del S.O. como por ejemplo writeln , write , read ,etc . ( no así sizeof () , len() , etc . ) el compilador enlazada nuestro ejecutable al archivo objeto donde se encuentran estas llamadas , básicamente lo que se hizo en Toro es capturar estas llamadas , creando el archivo Lib/fpclib/fpclib.pas con estas llamadas y linkeandolo junto con todo el kernel .
Por ejemplo :

llamada muy utilizada para el tratamiento de strings

procedure int_strconcat(s1,s2:pointer);[public,alias:'FPC_SHORTSTR_CONCAT'];
var
s1l, s2l : byte;
type
pstring = ^string;
begin
if (s1=nil) or (s2=nil) then
exit;
s1l:=length(pstring(s1)^);
s2l:=length(pstring(s2)^);
if s1l+s2l>255 then
s1l:=255-s2l;
move(pstring(s1)^[1],pstring(s2)^[s2l+1],s1l);
pstring(s2)^[0]:=chr(s1l+s2l);
end;

También se podría haber linkeado directamente el archivo objeto de FP donde se encontrase la llamada , pero haría crecer el kernel enormemente!!! .

En las unidades mientras no se utilicen llamadas que depende del S.O. o que provengan de unidades externas no hay problema , el compilador no realizara llamadas al sistema .
La cosa cambia con un ejecutable . Cuando se compila el archivo kernel/kernel.pas , este ya no es una unidad sino que es un programa , para volverlo “limpio” de llamadas al sistema lo que se hace es simplemente quitarlas del código assembler :

Extracto del archivo /kernel/Makefile .

$(FPC) $(FPC_FLAGS) kernel.pas

$(GREP) -iv "INIT$$SYSTEM" kernel.s > kernel.tmq
$(GREP) -iv "FPC_INITIALIZEUNITS" kernel.tmq > kernel.tmp
$(GREP) -iv "FPC_DO_EXIT" kernel.tmp > kernel.kkk
$(GREP) -iv "OBJPAS" kernel.kkk > kernel.s

Estas son los símbolos que deben ser retirados y que llevan a la caída del kernel cuando bootea ( a la caída me refiero a una excepción , muy común la 13 )

Una vez compilados todos los archivos objetos son linkeados con ld , puede pasar que tire errores de símbolos desconocidos , es decir hay funciones o procedimiento que están llamando a otros que no se encuentran en los archivos objetos linkeados . Lo mas posible es que haya errores en el tipeado de nombres , o que el head de la función no haya sido declara como publica . Si todo esto no es correcto habría que ver si es una llamada a librerías del compilador , si es así , se debería buscar el procedimiento o función en el código de FP , copiarlo al archivo lib/fpclib/fpclib.pas y declararlo como publico con el alias devuelto como error en ld .

FPC 2.0.0 sobre win32 y linux :

Sobre estas plataformas la cosa no me resulto fácil , lamento informa que no he llegado a una versión booteable del kernel de toro compilado sobre win32 , es por eso que las distribuciones se harán por ahora para go32v2 y para linux , o tal ves solo para linux puesto que se dejaron producir versiones de FPC para DOS .

Para el caso de FPC 2.0.0 sobre linux , al compilar el archivo kernel/kernel.pas solo se quita el símbolo :

$(GREP) -i 'FPC_INITIALIZEUNITS' -v kernel.s > kernel.q

Para el caso de llamadas al sistema lo que opte hacer ahora fue directamente el linkeo de los archivos objeto que contienen las llamadas utilizadas por el compilador estas son :

/usr/lib/fpc/2.0.0/units/i386-linux/rtl/prt0.o
/usr/lib/fpc/2.0.0/units/i386-linux/rtl/system.o
/usr/lib/fpc/2.0.0/units/i386-linux/rtl/objpas.o

Lo que hace es incrementar enormemente el archivo toro-1.1 , que posee casi el triple del mismo archivo generado con el FPC para DOS .

La unidad Lib/fpclib/fpclib.pas deja de utilizarse para el FPC sobre linux . Por supuesto , posiblemente dentro de estos archivos objetos hayan funciones que realicen llamadas al sistema , pero no causaran problemas mientras no se las llame :) .

Espero que este articulo les sirva para saber como se puede generar un ejecutable totalmente booteable (por ejemplo un elf para grub o un binario para un booteador propio) sin que posibles llamadas del compilador lleven a excepciones no deseadas .

Aclaración! si el elf generado va a ser utilizado por un booteador como grub tiene que ser creado bajo la norma multiboot sino grub no podrá levantarlo , toro fue creado bajo ese Standard , en próximos documentos describiré como hacer un elf que pueda ser levantado con grub .

Matias Vara
Toro.sourceforge.net
matiasvara@yahoo.com

Compilando el kernel de Toro – 1.1

2005-11-01T15:57:00.000-08:00

Este procedimiento es aplicable a partir de la versión 1.1 de Toro .

Una vez obtenido el paquete zip de la versión de Toro debe ser extraído sobre un directorio cualquiera o bien sobre un disket sobre el cual previamente se debe haber instalado grub . En el raíz del disket deben figurar tres directorio : usr , bin y boot , para que grub pueda bootear .

Para comenzar la compilación se debe modificar el archivo /usr/toro-1.1/make.rules completando las variables de make con sus ubicaciones correctas .

El siguiente paso es hacer un make sobre el directorio /usr/toro-1.1/ y listo! , si todo resulta bien será generado el archivo elf ejecutable toro-1.1 y se moverá al directorio /boot para ser levantado por grub durante el booteo .

También deberán ser compiladas la utilidades que se encuentran en el directorio /usr/tools realizando un make en cada directorio y los ejecutables serán movidos al directorio /bin donde se encuentran todos los binarios .

Una vez tenido compilado correctamente Toro sobre el disket podrá ser booteado bien sobre un emulador o directamente sobre la maquina .

También pude ser compilado sobre linux cualquiera sea el booteador instalado mientras levante el elf de Toro , pero de todos modos en este caso también Toro buscara la shell en la disketera .

En próximas versión Toro podrá bootear sobre discos duros o cualquier dispositivo siempre y cuando tenga los drivers requeridos .

Matias E. Vara
Toro.sourceforge.net
matiasvara@yahoo.com

Nuevos posteos

2005-11-01T15:51:00.000-08:00

Ire posteando los documentos que se encontraban en papers y otros docuementos de como programar sobre , etc . Espero que les sea interesante . Un sa ludo Matias Vara .

Trabajando en la version 1.1.1

2005-10-11T16:45:00.000-07:00

Estoy trabajando en volver alta mente estable la version 1.1 , esta nueva version no incluira nuevas implementacion solo sera muy estable . Espero que me comenten los bug que encontraron en la version 1.1 y asi podre depurarla bien .
Un saludo Matias Vara .

Pd : Ahora puede postear cualquiera asi espero sus comentarios .

Bug en el paquete de la version 1.1

2005-09-15T15:52:00.000-07:00

He encontrado un error en el codigo de la version 1.1 , este se encuentra en el archivo toro-1.1/filesystem/exec.pas , el error se encuentra en la declaracion de la funcion Sys_Exec , esta deveria ser : [public , alias : 'SYS_EXEC'] , en vez de 'SYS_EXE' , Esta se encuentra tanto en el paquete para go32v2 como para el de linux .
Un saludo Matias Vara .

Toro compilado sobre fpc-linux

2005-08-19T18:32:00.000-07:00

Ya esta disponible el paquete .zip te toro-1.1 para ser compilado sobre la utlima version de fpc sobre linux .
Un saludo Matias Vara .

Recien salido del horno Toro 1.1!!

2005-08-01T18:37:00.000-07:00

Despues de mucho trabajo ya se encuentra la version 1.1 de Toro . Esta fue distribuda de dos formas un paquete zip con todo el codigo y listo para ser compilado; y la imagen de un disket de 3 1/2 listo para ser ejecutado . Bueno espero que la pruben y me den sus comentarios . Esta version fue compilada con la version de FPC para go32v2 , puesto que me esta trayendo dolor de cabeza compilarlo con la version para win32 .
Un saludo Matias Vara .

Implementaciones de Toro 1.1

2005-07-16T15:52:00.000-07:00

Aunque la version de Toro 1.1 todavia no ha sido publicada el principal motivo es la gran cantidad de cambios que esta presenta , a continuacion se citaran algunas :

- Implementacion del VFS .
- Se deja de utilizar el torofs para implementar driver para fat12fs .
- Soporte multiboot , toro es booteable sobre grub .
- Reescritura de la unidad dma.pas .Creacion de una pila con paginas para dma .
- Reserva de areas de memoria para io con dispositivos hard.
- Reescritura de la unidad scheduler.pas , Implementacion de los algoritmos RR y FIFO en tiempo real .
- Reescritura de la unidad signal.pas
Y algunas cosas mas

Es por eso que mencionar una fecha es imposible .
Un saludo Matias Vara .