UN POCO DE
HISTORIA.
 |
¿Qué y quién es
ZEUS OS? |
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
Definición de primeros objetivos, y forma de trabajo.
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.
Además las premisas de trabajo.
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:
- 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.
- 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:
- Desarrollo de un Kernel.
- Desarrollo de un gestor de memoria.
- Desarrollo de un servidor de ficheros (en desarrollo).
- Desarrollo de un servidor de vídeo.
- Desarrollo de un servidor de teclado.
- Desarrollo de un linkador (no implementado ni
desarrollado).
- Desarrollo de un compilador (desechado).
- Desarrollo de un servidor de red (no implementado ni
desarrollado).
- Desarrollo de un intérprete de comandos (en
construcción).
|
Alternativas
tecnológicas. |
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...
|
Alternativas de
contrucción. |
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.
zeusv2@geocities.com
Última actualización de la página: 12/03/99
Esta página está hospedada en 
Consigue tu Página
Web Gratis