Diseo e Implementacin de un Sistema Operativo

Walter Artica Zevallos

Facultad de Ingeniera Electrnica UPC (Universidad Peruana de Ciencias Aplicadas) Lima, Per walter.artica@ieee.org
AbstractSe presentan las motivaciones, consideraciones de diseo y criterios de implementacin de un sistema operativo construido desde cero. Adems, se exponen las razones que ameritan la investigacin y desarrollo de nuevos sistemas, as como conclusiones y observaciones del proceso. Trminos de ndice: operating system; kernel; computer architecture.

habitual su investigacin y desarrollo, en el Per el tema se suele pasar por alto, subestimando as la complejidad del hardware actual, que en ausencia de un SO sera difcil de controlar o ineficientemente controlado. III. PLANTEAMIENTOS Y JUSTIFICACIONES

I.

INTRODUCCIN

En los ltimos aos la sola mencin de sistema operativo implica un conjunto de programas sumamente complejos, de tamao descomunal cuyos costos de tiempo/esfuerzo son altsimos. No obstante ello, el progreso en el rea cientfica ha sido constante -aunque lento- llegando a contar a la fecha con un cmulo de principios y tcnicas slidas para la construccin de sistemas operativos. En el presente trabajo se propone el diseo e implementacin de un sistema operativo (SO de aqu en adelante). Si es que tales pantagrulicos programas descansan sobre una base elegantemente planteada, no es acaso posible retomar el esfuerzo de numerosos pioneros ([2], [6] y [8]) y plantear un nuevo sistema, hecho a partir de unas cuantas ideas bsicas, que sintetice lo logrado y contemple las enseanzas que el tiempo ha dejado? Retomar el problema a partir de las ideas esenciales ejemplifica una prctica ingenieril que permite enfrentar la complejidad de sistemas con requerimientos avanzados y diversos. Por otro lado, la sntesis es necesaria para obtener un diseo competitivo. Luego, las experiencias previas y bien estudiadas deberan permitir mnimamente evitar cometer los mismos errores de arquitectura o diseo, a la vez que facilitar una base de cdigo reutilizable en un nuevo proyecto. II. PLANTEAMIENTO DEL PROBLEMA

A. Diseo simple Los sistemas operativos son piezas sumamente delicadas de software, cuyo diseo e implementacin son obras en las que las ms mnimas desconsideraciones por principios slidos de ingeniera tienden a repercutir negativamente en la evolucin y ejecucin del sistema. Es por ello que un diseo simple debera ser una prioridad a la hora de plantear un nuevo sistema. Ejemplos de su aplicacin son el legado de trabajos medianamente populares, como [6] y [8]. Por otro lado, a pesar de la en ocasiones sublime complejidad de algunos sistemas operativos experimentales, la realidad es que los sistemas operativos ms populares y ampliamente usados se basan en arquitecturas relativamente simples, por lo que no es de sorprender que la eleccin de un diseo basado en un mnimo de conceptos ampliamente probados sea una opcin atractiva para un nuevo sistema. B. Uso de un lenguaje de programacin moderno Conforme progresa el desarrollo de los lenguajes de programacin se han reconocido un nmero de principios esenciales que permiten un uso efectivo del formalismo en cuestin (estos cualifican a un lenguaje como moderno). Lamentablemente la antigedad e intenciones originales (ensamblador de alto nivel?) de lenguajes como C repercuten negativamente en la disponibilidad de tales facilidades (lmites de arrays y modularidad por poner algunos ejemplos), que la mayora de nuevos lenguajes poseen desde su concepcin. Sin embargo, la utilizacin de C domina el campo de la implementacin de sistemas operativos desde el xito de Unix, y la tendencia a cambiar se limita en su mayor a parte a usar extensiones compatibles (C++ y Objective-C) o bien una desviacin radical hacia lenguajes con semnticas sofisticadas (p. ej. derivados de Java y C# con capacidades de verificacin semntica, o lenguajes funcionales como Haskell). Una posibilidad poco explorada con la notable excepcin del lenguaje Oberon [7] es la de utilizar un lenguaje orientado a la programacin de sistemas como C, pero con un mnimo de criterios que aseguren las facilidades antes citadas. Es usual llamar a un lenguaje que cumple ciertas normas de confiabilidad en la escritura de programas lenguaje de tipos 1

En lo que concierne a nuestra realidad particular, en el Per no existe un inters genuino en el diseo e implementacin de sistemas operativos, en parte por la falta de conocimiento y profesionales calificados en el tema, as como por la ausencia de un campo de pruebas disponible. No obstante, la necesidad de plataformas de software avanzadas que gobiernen un sistema computacional complejo es cada vez ms imperante, dada la omnipresencia de equipos y componentes que permiten la realizacin de aplicaciones ms sofisticadas y competitivas. No existen registros de investigaciones vinculadas al tema de SOs localmente. Mientras que en el exterior es

seguros (type-safe language). Si es plausible considerar que el uso de las mejores herramientas disponibles contribuye hacia hacia un mejor producto ingenieril, es precisamente esta clase de lenguajes la que asegura una mayor probabilidad de xito en un proyecto de sistemas operativo. Vale mencionar que circunscribirse a la clsica categora de lenguaje de programacin de sistemas implica una enorme simplificacin comparado a utilizar uno de los lenguajes sofisticados antes mencionados. C. Inversin econmica La investigacin de SOs requiere de una mnima inversin econmica en la mayora de casos. Dado que la utilizacin de hardware masivo suele ser la primera opcin como plataforma base, los costos de equipos suelen ser asequibles. En cambio, normalmente el mayor obstculo es el temporal, pues se trata de proyectos que requieren una cantidad amplia y variada de conocimientos, cuya adquisicin require de varios meses de dedicacin. D. Actitud pionera Si se espera que el desarrollo tecnolgico del pas sea progresivo y consecuente con los tiempos actuales, debe mnimamente incluirse dentro de nuestra agenda de investigacin soluciones a problemas esenciales como es el caso de los SOs. El trabajo presente asume pues, una actitud pionera ante la escasez de inters en el tema en nuestro pas. IV. APLICACIONES

Utilizar como base sistemas operativos modernos influyentes como Unix ([1] y [5]), Windows ([4]) y OS/2 ([3]), tanto para modelar las APIs, como para reconocer las funciones requeridas en un sistema moderno. Aplicar los principios de extensibilidad y modularidad del sistema Oberon, que adems proporciona una interfaz de usuario simple y moderna. CARACTERSTICAS DEL PROYECTO CONCLUIDO

VI.

El planteamiento inicial de este proyecto de SO no limita la aplicabilidad de ste a un entorno particular, esto es, el sistema podra utilizarse en desde sistemas embebidos, pasando por computadoras de escritorio, hasta servidores, e inclusive (con algunos criterios y cambios de arquitectura adicionales) supercomputadoras. Sin embargo, dada la ubicuidad de computadoras personales y la amplia disponibilidad y facilidad de recursos para la implementacin y prueba de software en este tipo de mquinas es previsible que el campo objetivo primario sea el de sistemas de escritorio, por lo menos durante las fases de pruebas y primeras versiones. Por otro lado, la aplicacin en sistemas electrnicos embebidos podra tomar mucha relevancia en corto tiempo, pues son la clase de equipos cuya produccin es ms atractiva para nuestro mercado local, ms acorde a las limitaciones de nuestra industria, y cuya inclusin de SOs especficos podra resultar en un valor agregado significativo. V. OBJETIVOS DEL PROYECTO

Sistema operativo de fcil uso (interfaz de usuario moderna en modo grfico, orientada a objetos), estable y seguro por diseo (proteccin a travs de la arquitectura cliente/servidor con aislamiento de tareas, lenguaje de implementacin seguro), ligero en recursos (bajo consumo de memoria y procesamiento, adaptable dependiendo de la carga aplicada), extensible (orientado a objetos, enlace dinmico, etc.). Capacidades de multitarea a travs de procesos (aplicaciones cargadas en espacios de memoria aislados y protegidos) e hilos (mltiples puntos de ejecucin de un mismo programa). Soporte de memoria virtual paginada (~4 GB exclusivos para cada proceso) y bajo demanda (se utiliza espacio de discos como memoria de programa adicional). Primera versin disponible para arquitectura x86 (Intel/AMD) de 32 bits, usando la arquitectura en modo de compatibilidad ISA (esto es, computadoras actuales de escritorio comunes). Entorno de programacin con facilidades tales como portabilidad, bibliotecas estndar, utilidades de depuracin, etc. Documentacin detallada tanto del interior (arquitectura, organizacin) como exterior del sistema (referencias para el programador, manuales de usuario). Disponibilidad del conjunto completo de programas de manera libre (licencia de cdigo abierto open source). Posibilidad de utilizar el sistema como ejemplo prctico para el uso en cursos o investigaciones vinculadas a sistemas operativos. Sistema adaptable y extensible a diferentes entornos de computacin (sistemas embebidos, servidores, etc.). VII. HERRAMIENTAS USADAS Para poder afrontar la complejidad del sistema se requieren de herramientas adaptadas a desarrollo avanzado, por lo que era crtico escoger adecuadamente el conjunto de estas. La suite elemental de herramientas escogidas es OpenWatcom, que es de cdigo abierto y para Windows. Esta proporciona compilador de C, linker y utilidad make usados en el sistema. El ensamblador usado es JWASM (tambin de cdigo abierto), que es una versin mejorada y con documentacin ms extensa del ensamblador de OpenWatcom (WASM).

Proponer un S.O. original con una arquitectura simple, interfaces (APIs) prcticas, e implementado en un lenguaje de programacin moderno. Implementar los mdulos fundamentales del sistema. Preparar un entorno de desarrollo complete multiplataforma.

La integracin entre stas ya estaba garantizada por su mismo origen, lo que incrementa en general la productividad del desarrollo (esto es, no hay problemas de compatibilidad). VIII. CARACTERSTICAS DEL DISEO A. Soporte de CPU El soporte nativo es para microprocesadores de 32 bits de Intel y AMD, que son evidentemente los ms usados en computadoras de escritorio. A.1 Modo protegido La familia de microprocesadores escogida soporta 2 modos de funcionamiento: Real y Protegido. En modo real se comporta como un CPU de 16 bits y se ofrece solo por compatibilidad. En cambio, en modo protegido el CPU habilita todas sus caractersticas avanzadas y es el que usan todos los SOs modernos, por lo que es sin ms explicaciones el modo que se aplica en el proyecto. Son 2 caractersticas las ms interesantes: Proteccin: Discierne entre modos de ejecucin privilegiados. El cdigo y datos por separado tienen asociados privilegios de qu o quin puede o no acceder hasta en 4 niveles de jerarqua. En los sistemas operativos actuales se suele usar solo 2: modo supervisor (tambin denominado kernel o privilegiado) y modo usuario (no privilegiado), para cdigo y datos del sistema y del resto de aplicaciones respectivamente. Memoria virtual: Soportada a travs de segmentacin y paginacin. El primero es rara vez usado en la actualidad, pero el segundo es el estndar de facto de esquemas de gestin de memoria de los SOs contemporneos. Se basa en dividir el espacio de direcciones en bloques pequeos (de 4 KB en nuestro caso) que pueden ser reubicados de acuerdo a tablas. B. Interrupciones El dispositivo bsico de soporte de interrupciones en las PCs convencionales es el i8259 (PIC, Programmable Interrupt Controller). Se tienen dos de estos en cascada, permitiendo controlar hasta 15 fuentes de interrupcin, que pueden ser relocalizadas en cualquiera de los 255 vectores de interrupcin disponibles en el CPU. Su programacin es relativamente sencilla. C. Pantalla en modo texto Para programarla se requiere bsicamente escribir bytes de atributos y carcter pues se maneja mediante puertos de E/S mapeados a memoria. D. Administracin de procesos Se encarga del soporte de multitarea a travs de procesos e hilos. Usa planificacin mediante round-robin (rotacin de tareas con tiempos iguales por turno) y manejo bsico de prioridades.

E. Administracin de memoria Soporta memoria virtual con dos esquemas: espacio de direcciones independiente por proceso y paginacin. Paginacin: Si bien es cierto que la disponibilidad de equipos con memorias de trabajo de 2 GB y superiores cada vez es ms predominante, los programas crecen en consumo de recursos en quizs mayor proporcin. Es por ello, que es inevitable la inclusin de un soporte para memoria virtual en un sistema operativo, de tal manera que se pueda engaar a los programas de que poseen un gran espacio de direcciones que pueden utilizar sin comprometer a otros procesos que estn en ejecucin. La paginacin es hasta hoy el mtodo ms usado para lograr tales objetivos, pues es un mecanismo que permite implementaciones escalables y que se amolda a diferentes polticas de ejecucin. La idea bsica consiste en segmentar la memoria del programa en ejecucin en pequeas porciones llamadas pginas (de un tamao fijo), alineadas especialmente en el espacio de direcciones y que permiten relocalizar cualquier parte del programa mediante el uso de tablas de traduccin, que almacenan las correspondencias entre direcciones virtuales y reales. Adems se suele contar con un mecanismo para controlar el acceso a pginas no marcadas como presentes, de tal manera que se soporte un esquema de memoria virtual bajo demanda. F. Llamadas al sistema Dispone de una interrupcin por software (la nmero 32 en hexadecimal) que se encarga de proporcionar a los programas de usuario acceso restringido a los servicios del sistema operativo (entrada/salida, gestin de procesos, etc.). G. Reporte de errores Por lo menos debe disponerse de una rutina de pnico (PANIC), que muestre un mensaje de error crtico y deje al sistema congelado (en un bucle infinito; no hay mucho que se pueda hacer luego de un error de esta escala) H. Bootstrapping Se trata del conjunto de programas que permiten iniciar el sistema operativo desde el encendido del equipo, cuando solo se dispone de un mnimo de servicios bsicos. Para el prototipo del sistema, se opt por usar FreeDOS (un DOS gratuito) como bootloader y a partir de ah cargar el resto de componentes del sistema. Se dispone de arranque a partir de un diskette de 3 pulgadas y de un CD convencional de 650 MB. I. Formato de archivo ejecutable Se eligi el formato de archivo ejecutable PE (Portable Executable). Es el formato nativo de Windows de 32 bits bits (en 64 bits la versin extendida PE+). Se ejecuta slo en modo protegido (32 bits) o modo long (64 bits). Est optimizado para un entorno de memoria virtual.

IX.
Modo 16 bits 16 bits 32 bits 32 bits

ARCHIVOS DEL SISTEMA

Descripcin Archivos de FreeDOS, utilizado como bootstrapper. Cargador del sistema. Configuracin de inicio del sistema. Kernel. Interfaz de usuario.

Archivo(s) Kernel.sys Command.com Autoexec.bat Dosboot.exe System.ini OSKERNEL Shell.exe

X.

DESCRIPCIN DEL PROCESO DE EJECUCIN

A. En modo real (16 bits) Dosboot.exe se encarga de leer de disco el kernel del sistema (un ejecutable nativo de 32 bits); verifica el mnimo necesario de campos propios del formato ejecutable (PE), como la cabecera de imagen, directorios y cabeceras de secciones (cdigo, datos, relocalizaciones). Adicionalmente, detecta la memoria RAM disponible con ayuda de la BIOS. Cuando se encuentra listo para copiar los datos a la memoria extendida (a partir del primer megabyte), activa la compuerta A20 (habilita todo el bus de direcciones y copia los datos de la imagen ejecutable para cargarla en la direccin 0x100000 (1 megabyte). Para poder ingresar a modo protegido, primero debe crear la tabla del procesador llamada GDT, y a continuacin prepara los parmetros almacenados por este programa en una forma accesible por el kernel. Acto seguido, salta al nuevo punto de entrada y activa el bit del procesador para activar modo protegido. B. En modo protegido (32 bits) El kernel del sistema, llamado oskernel, es un ejecutable en formato PE. Su punto de entrada (escrito en assembly) bsicamente fija una pila temporal, los registros de segmentos con selectores apropiados (cdigo, datos) y salta a una funcin Main ( ), a partir de la cual se trata de cdigo en lenguaje C. Inmediatamente, prepara el manejo de la consola en modo texto, para informar del progreso del sistema, as como de cualquier error que pudiera ocurrir. El siguiente paso es recuperar los parmetros enviados por el cargador de arranque del sistema y colocarlos en tablas locales (informacin relevante como el mapa de la memoria), a la que sigue el reconocimiento de la imagen ejecutable del sistema, con una verificacin mnima de integridad de su metainformacin (cabeceras, etc.). A continuacin se inicia la creacin del mapa de bits de la memoria del sistema, que recupera informacin de la tabla que gener el cargador de arranque. Este mapa de bits mantiene un registro de la memoria reservada y en uso. Llega el momento de inicializar el modo protegido por completo, con las tablas GDT (regiones de cdigo, datos), IDT (manejadores de interrupcin) y TSS (cambio de modo del procesador) completas y en funcionamiento.

Luego sigue una de las fases ms crticas: la habilitacin de la paginacin. Requiere generar varias tablas que acomoden el espacio de memoria utilizado por la imagen del sistema, as como la perteneciente a dispositivos mapeados en memoria. Relocaliza el kernel en la direccin 0xC0000000 y reserva el espacio de direcciones de 0x80000000 a 0xBFFFFFFF para las tablas de paginacin de los procesos de usuario. Al estar habilitada la paginacin, se procede a inicializar los ltimos subsistemas esenciales, empezando con la entrada/salida, que incluye inicializar dispositivos como el teclado, temporizadores, etc. Se habilita tambin la llamada del sistema, la interrupcin 0x32, que proporciona a los programas de usuario de servicios bsicos para comunicarse con el kernel. El turno del mdulo de manejo de tareas habilita las tablas y rutinas que permiten manipular el estado de ejecucin del sistema para soportar la presencia de mltiples procesos, cada uno con su propio espacio de direcciones, registros, pila, etc. Entonces ocurre el salto a modo usuario; el proceso shell.exe (primer mdulo ejecutable externo cargado) es puesto en ejecucin, proporcionando los medios para que el usuario pueda interactuar con el sistema. XI. CONCLUSIONES Y OBSERVACIONES

Una iniciativa que se plante fue simplificar donde fuera posible la estructura del sistema y por ende la complejidad de la implementacin. Signific un diseo cuidadoso de la mayora de mdulos, pero sta en definitiva vali la pena pues se obtuvo un sistema ms sencillo de entender y modificar, as como ms fcil de trasladar a otras plataformas, como por ejemplo dispositivos embebidos. Por el lado negativo, simplificar algunas estructuras provoc muchos mdulos con dependencias del entorno subyacente, aunque esto lleva el contrapeso de la ventaja anterior. Un retraso constante al progreso del proyecto fueron las herramientas usadas (compilador, ensamblador) que tienen errores (bugs) no detectados en las versiones actuales o un comportamiento errtico cuando, por ejemplo, se habilitan optimizaciones (generacin de cdigo ms rpido o ms conciso). Largas sesiones de depuracin se debieron a esta clase de problemas. La eleccin estricta de un estilo de organizacin, escritura y seleccin de nombres increment notablemente la legibilidad del cdigo producido. Se trat de hacer evidente la modularidad al usar nombres largos compuestos del tipo <Mdulo>_<Funcin>. E.g.: Puertos_EscribirByte(), Puertos_LeerByte(). La disponibilidad de herramientas de simulacin (una mquina virtual) con soporte avanzado de depuracin (revisar direcciones fsicas/virtuales, tablas del CPU, definir breakpoints, etc.) se convirti en una necesidad, pues permiti analizar el comportamiento del sistema de prueba minuciosamente. No es nada sencillo depurar un sistema operativo en sus primeras fases de desarrollo. Una de las partes ms crticas del proyecto fue la administracin de memoria. El soporte de memoria virtual paginada requiere implementar un sistema relativamente sofisticado de manejo de pginas y tablas de 4

correspondencia. Depurar estas rutinas puede ser bastante tedioso pues hasta la ms mnima facilidad de depuracin (imprimir las variables del estado actual en pantalla) se inhabilita en los instantes crticos de la transicin de inactivo a activo de la memoria virtual. REFERENCIAS
[1] Andrew S. Tanenbaum y Albert S. Woodhull, Operating Systems: Design and Implementation, 3ra. ed. New Jersey: Pearson Prentice Hall, 2006. Douglas Comer y Timothy V. Fossum, Operating System Design Vol. I: The Xinu Approach. New Jersey, Prentice Hall, 1988.

[3] [4]

[5] [6] [7] [8]

Harvey M. Deitel y Michael S. Kogan, The Design of OS/2. Boston: Addison-Wesley, 1992. Mark E. Russinovich y David A Solomon, Microsoft Windows Internals: Microsoft Windows Server 2003, Windows XP, and Windows 2000, 4ta. ed. Washington: Microsoft Press, 2005. Maurice J. Bach, The Design of the Unix Operating System. New Jersey: Prentice Hall, 1986. Niklaus Wirth y Jrg Gutknecht, The Oberon System, Technical Report 88. Institut fr Informatik, ETH Zrich, 1988. Niklaus Wirth y Martin Reiser, Programming in Oberon: steps beyond Pascal and Modula. New York: ACM Press, 1992. Per Brinch Hansen, Programming a Personal Computer. New Jersey: Prentice Hall, 1983.

[2]