Proyecto Programado # 2

Universidad de Costa Rica

Escuela de Ciencias de la Computación e Informática

CI-0122 Sistemas Operativos

• Descripción

• La segunda fase de NachOS es dar soporte a la multiprogramación. De la misma forma que en la primera asignación le damos parte del código que necesita; su trabajo será completar el sistema y mejorarlo. Hasta ahora el código que ha escrito para NachOS ha sido solo parte del kernel del sistema operativo. En un sistema operativo real, el kernel no solo utiliza sus procedimientos internamente, sino que también permite a programas de los usuarios tener acceso a algunas de sus rutinas utilizando llamados al sistema (system calls)
• El primer paso para desarrollar esta asignación es leer y entender la parte del sistema que hemos escrito para ustedes. Los archivos del kernel se encuentran en "userprog", se adicionan algunas partes para la simulación de la máquina Mips en el directorio "machine" y un sistema de archivos inicial en "filesys". Los programas de los usuarios están en "test" y los utilitarios para crear los programas ejecutables de NachOS están en "bin". Tenga presente que los programas de usuarios deben ser compilados y correr en máquinas con arquitectura Mips (con las que no cuenta la ECCI, por lo que es necesario utilizar un cross-compiler). NachOS debe ser compilado utilizando los utilitarios de las máquinas Linux
• Con el código que le presentamos, NachOS solo puede correr un programa de usuario codificado en C a la vez. Como caso de prueba, presentamos un programa de usuario trivial, "halt", que lo que hace es utilizar un llamado al sistema para hacer que el sistema operativo 'apague' la máquina. Para correr el programa "halt", usted debe compilar (make) y correr NachOS (./nachos -x ../test/halt). Debe seguir la ejecución, como se comporta cuando el programa es cargado en memoria, corre y luego invoca un llamado al sistema (halt)
• Puede encontrar de gran utilidad el artículo de Narten ("Road Map"). También puede hacer cambios razonables a algunas de la constantes que se encuentran en el archivo "machine.h", por ejemplo, cambiar el tamaño de la memoria física, si eso le ayuda a crear mejores casos de prueba. Los archivos que se utilizan para esta asignación son:
  
  

  userkernel.h, userkernel.cc	rutinas para iniciar y probar el kernel de multiprogramación.
  addrspace.h, addrspace.cc	crea un espacio de direcciones en el cual corre un programa del usuario, y lo carga del disco.
  syscall.h	es la interfaz para los llamados al sistema; los procedimientos del kernel que los programas del usuario pueden invocar.
  exception.cc	el manejador para los llamados al sistema y otras excepciones del usuario, tales como "page-faults". En el sistema que presentamos, solo el llamado al sistema "halt" es soportado.
  bitmap.h, bitmap.cc	rutinas para manipular bitmaps (que pueden ser útiles para llevar el control de los marcos de memoria física).
  filesys.h, filesys.cc	(que se encuentran en el directorio "filesys") definen una versión del sistema de archivos de NachOS preliminar. Para esta asignación, hemos implantado el sistema de archivos de NachOS utilizando directamente las rutinas del sistema de archivos de Unix, de manera que solo tenga que probarse una cosa a la vez.
  translate.h, translate.cc	rutinas para la traducción de direcciones. En el código que presentamos, para correr "halt", suponemos que cada dirección virtual es la misma que cada dirección real, esto restringe el sistema a solo poder correr un programa de usuario a la vez. Usted necesita generalizar este esquema para lograr correr varios programas de usuario de manera concurrente. En esta asignación no se solicita implantar el manejo de la memoria virtual, la cual es delegada hasta la asignación #3, por ahora cada página de memoria debe estar en la memoria principal.
  machine.h, machine.cc	emula la parte de la máquina que ejecuta los programas del usuario: memoria principal, los registros del procesador, etc.
  mipssim.h, mipssim.cc	emula el conjunto de instrucciones con números enteros del procesador MIPS R2/3000.
  console.h, console.cc	emula el dispositivo terminal utilizando archivos de Unix. Una terminal es (i) orientada a caracteres (bytes), (ii) los caracteres pueden ser leídos y escritos simultáneamente y (iii) los caracteres pueden llegar de manera asíncrona (como el resultado de las teclas que presiona el usuario), sin ser explícitamente solicitados.
  synchconsole.h, synchconsole.cc	provee acceso sincronizado al dispositivo consola.

  
  
• En esta asignación les estamos presentando una CPU simulada que modela una CPU real. De hecho, la CPU simulada es la misma que la CPU real (un chip Mips), pero simulando la ejecución, se tiene el control completo de cuántas instrucciones se ejecutan, cómo trabaja el espacio de direcciones, y cómo se manipulan las excepciones (incluyendo los llamados al sistema) e interrupciones
• Nuestro simulador puede correr programas escritos en C y compilados para la arquitectura Mips, ver el directorio "test" para encontrar algunos ejemplos. Los programas compilados (utilizando un cross-compiler) deben ser enlazados con una serie de banderas especiales (ver el "Makefile"), luego convertidos al formato de NachOS utilizando el utilitario "coff2noff" (que se provee en "bin"). La única restricción es que no se soportan las instrucciones de punto flotante del Mips
• Usted debe proveer un kernel de NachOS que sea a 'prueba de balas' contra los programas del usuario, no debe haber nada dentro de un programa del usuario que haga que el sistema operativo se 'caiga' (con la excepción de explícitamente llamar a la función "halt")

• Direcciones

1. Implantar el manejo de excepciones y llamados al sistema. Se deben soportar todos los llamados al sistema definidos en "syscall.h". Presentamos una rutina en ensamblador "syscall" que provee la manera de invocar un llamado al sistema desde una rutina C (Unix tiene un método similar, intente "man syscall"). Usted necesita completar la parte 2 de esta asignación con el fin de probar los llamados al sistema "exec" y "wait"
2. Implantar multiprogramación. El código que presentamos le restringe a solo poder correr un programa de usuario a la vez. Usted necesita:
   • Encontrar la manera de asignar los marcos de memoria física de tal manera que varios programas de usuario puedan ser colocados en la memoria principal a la vez. (ver "bitmap.h")
   • Proveer una manera de copiar datos desde/hacia el kernel desde/hacia el espacio de direcciones virtual del usuario (ahora las direcciones que el programa del usuario 've' no son las mismas que el kernel 've')
   • Agregar sincronización a las rutinas que crean e inician el espacio de direcciones, de tal manera que puedan ser accedidas concurrentemente por múltiples programas. Note que "scheduler.cc" ahora guarda y recupera el estado de la máquina en los cambios de contexto. Es deseable tener algunas rutinas como "cp" y "cat" de Unix, y utilizar el shell que proveemos en el directorio "test" para verificar el manejo de llamados al sistema y la multiprogramación
3. Implantar programas de usuario multi-hilos. Implante los llamados al sistema "fork" y "yield", que le permita al usuario llamar a una rutina en el mismo espacio de direccionamiento, y hacer ping pong entre los hilos (Ayuda: necesita cambiar la manera actual del kernel para asignar memoria en el espacio de direcciones del usuario para cada una de las pilas de los threads)
4. (Extra, por 5% )La versión actual del llamado al sistema "exec" no ofrece ninguna manera para que el usuario pueda pasar parámetros o argumentos al nuevo espacio de direcciones creado. Unix permite ésto, por ejemplo, se pueden pasar argumentos en la línea de comandos al nuevo espacio de direcciones. Implantar esta funcionalidad del "exec"