Así pues nació ZEUS OS, iniciativa de los alumnos José Juan Barco, Javier Cuevas, Oscar García y José Luis Vela, que evaluaron la posibilidad de implementarlo y de crearlo, siendo independiente, y contando con herramientas de programación y de comunicación a través de redes

Los objetivos propuestos para el año 1996/97 fueron:

• Estudio práctico de la teoría de S.O. vista en la asignatura.
• El valorar el trabajo en grupo.
• Saber afrontar los retos que lleva consigo un proyecto de este tipo.
• El sacar una muy buena nota en S.O. II.

La organización del proyecto es llevada a cabo por el grupo de trabajo, organizando el proyecto en varias fases descritas en el organigrama.

Dentro del grupo no hay jerarquía de mando, de manera que se puedan realizar las labores del proyecto de una manera totalmente libre. La forma de la que se tomarán las decisiones será la siguiente:

a) Decisiones generales que atañen a todo el proyecto: se toman por consenso del grupo, estando todos de acuerdo en lo que hay que hacer.

b) Decisiones en las diferentes tareas: se toman por el responsable de realizar dicha tarea.

 La planificación del proyecto se llevó a cabo de tal manera, que fuera posible paralelizar al máximo las tareas a realizar en el proyecto. En primer lugar, el análisis y diseño de ZEUS, la cual fué desarrollada conjuntamente. Posteriormente se pasó a implementar el sistema, los drivers y las herramientas que sean necesarias. Cada tarea fué desarrollada por un componente del grupo. Las tareas que se llevaron a cabo fueron:

1. Desarrollo de un Kernel.
2. Desarrollo de un gestor de memoria.
3. Desarrollo de un servidor de ficheros.
4. Desarrollo de un servidor de vídeo.
5. Desarrollo de un servidor de teclado.
6. Desarrollo de un linkador.
7. Desarrollo de un compilador.
8. Desarrollo de un servidor de red.
9. Desarrollo de un intérprete de comandos.

En principio se plantearon dos líneas de desarrollo ligadas a la arquitectura del PC: el modo real o el modo protegido.

Si se optaba por el modo protegido se dotaría al S.O. de grandes posibilidades, que lo harían más atractivo. Además se facilitan ciertos trabajos como pueden ser la multitarea, protección de memoria y gestión de la memoria virtual. Así mismo hay que decir que este modo de programación dificulta en gran medida la implementación dada la poca experiencia en este terreno, y por la escasa y mala documentación.

Por otra parte, la realización del S.O. en modo real, limita fuertemente las características técnicas del producto a desarrollar, incluso otras, no serán posibles implementar, como memoria virtual, protección de datos. Pero hay que decir que existen gran cantidad de librerías, herramientas y bibliografías para trabajar en modo real.

Cuestiones alternativas a la creación de componentes fueron:

• Planificador: Se evaluaron los diferentes planificadores que se pueden implementar robo de ciclo, por prioridad o no, multitarea preventiva o cooperativa... Cada opción tiene sus características, bien diferentes, y por lo tanto son igualmente distintas a la hora de implementar.
• Memoria: la gestión está íntimamente ligada a funcionamiento de la CPU. Las principales cuestiones a resolver son la fragmentación de memoria, paginación y memoria virtual, acceso lineal a memoria...
• Disco: Las alternativas fueron intentar ser lo más flexibles e independientes del formato del disco, permitiendo hacer uso de la máxima cantidad de formatos existentes, o crear un formato propio de almacenamiento. La primera opción era la más atractiva y versátil, pero también la más compleja, ya que implica un tiempo considerable de estudio y desarrollo. La segunda opción es la más sencilla, pero sólo ofrece la libertad de colocar la información de una forma sencilla para el grupo que desarrolla el sistema.
• Llamadas al sistema: Esta característica debe de ser profundamente estudiada, ya que es fundamental para la rápida aceptación de las demás partes del S.O. Esta parte también está muy ligada a la CPU. Como opciones se evaluaron paso de mensajes entre procesos, implementar una arquitectura Cliente-Servidor, llamadas al sistema por generación de interrupciones, llamadas directas a procedimientos del sistema en zonas de memoria compartida por aplicaciones y S.O., mediante semáforos...
• Controladores de dispositivos: Las interfaces de los controladores de dispositivos deben de ser sencillos y estables. Además éstos deben de estar fuertemente vinculados a la estrategia de llamadas al sistema. Los controladores pueden cargarse o no dinámicamente en tiempo de ejecución o ser compilados directamente en el núcleo.
• Interfaces de usuario: Hay dos alternativas claras el modo texto y el modo gráfico. También hay varias alternativas respecto a la interactividad y conceptualización del interface, como pueden ser menús y ventanas, intérprete de comandos...

De todas las alternativas expuestas en el punto anterior se adoptaron las siguientes:

• Modo real: Se eligió ya que existe una mayor experiencia en este campo, y hubo poco tiempo de desarrollo, además no se buscaba un sistema de grandes características técnicas, sino obtener información acerca de la viabilidad de la construcción de un S.O.
• Planificador: Se adoptó un planificador por prioridades, que dota al S.O. de una multitarea cooperativa. Éste es el más versátil, ya que a partir de él se pueden implementar el resto de planificadores.
• Memoria: Se optó por el control de asignación de memoria y liberación de ésta. El controlador de memoria no tiene ninguna característica adicional, exceptuando que intenta disminuir la fragmentación de la misma.
• Llamadas al sistema: Se implantó un sistema basado en llamadas al sistema bajo una arquitectura Cliente-Servidor. De este modo, queda un sistema abierto a futuras ampliaciones, como por ejemplo migrar al modo protegido sin tener que cambiar la forma en que interactúan las aplicaciones del S.O.
• Interfaz con los controladores de dispositivos: Utiliza la misma arquitectura, Cliente-Servidor.
• Interfaz de usuario: Se optó por la opción de un intérprete de comandos simple, que permita la interacción con todos los componentes del sistema, y que además facilite las labores de depuración y prueba del conjunto de rutinas que forman el sistema operativo.

Organigrama de las fases del proyecto ZEUS OS. Volver al texto.

zeusv2@geocities.com

---

Esta página está hospedada en   Consigue tu Página Web Gratis