Diseño de Sistemas Operativos - Revisión 20 Aniversario

Proceso de creación de un sistema operativo, más como un proyecto de ingeniería que una ciencia exacta.

Necesidad de una visión clara para el diseño de un sistema operativo exitoso, para guiar las decisiones.

PL/I, intento de combinar características de diferentes lenguajes (FORTRAN, COBOL, Algol) sin una visión unificadora.

C, creado con un objetivo específico (programación de sistemas) por Dennis Ritchie.

Sistema operativo desarrollado por Tanenbaum y colaboradores, mencionado como ejemplo de diseño.

Sistema operativo desarrollado por Tanenbaum y Woodhull, mencionado como ejemplo de diseño.

Sistema operativo desarrollado por Van Steel y colaboradores, mencionado como ejemplo de diseño.

No hay consenso sobre la mejor forma de diseñar un sistema operativo, lo que hace al diseño más complejo.

Consiste en crear las abstracciones (como archivos y operaciones como 'read') que los programadores utilizarán para interactuar con el sistema operativo.

La interfaz principal de un SO a través de la cual los programadores interactúan con el núcleo del sistema.

Menos es más. Una interfaz simple es más fácil de entender e implementar evitando errores.

La interfaz debe permitir realizar todas las tareas necesarias por los programadores, sin omitir funcionalidad.

Interfaces especializadas que permiten a los programadores interactuar con dispositivos específicos del hardware.

Programador que usa el SO a través de llamadas al sistema (no usuario final).

Una interfaz que integra todas las características necesarias para los programadores.

Keep It Simple, Stupid (Manténganlo breve y simple). Un principio de diseño que enfatiza la simplicidad como clave.

Un método de diseño de sistemas operativos donde las funciones se organizan en capas separadas, con cada capa construyéndose sobre las anteriores.

Capa que se encarga de ocultar las características complejas del hardware a las capas superiores.

Operaciones que gestiona una capa intermedia en los sistemas en capas.

Hilos (procesos ligeros) que se manejan como hilos independientes y que pueden ser interrumpidos o suspendidos.

Módulo que administra los distintos dispositivos hardware del sistema.

Eventos que llaman la atención del procesador para tareas específicas de las capas inferiores.

Mecanismo de exclusión mutua para controlar el acceso a recursos compartidos entre múltiples hilos.

Diseño de sistemas operativos donde todas las funciones están integradas en un solo módulo.

Estructuras que mapean nombres de archivos externos a entradas internas en la tabla de archivos (MFT).

Sistemas para organizar y nombrar archivos y otros recursos.

Asignación de recursos o nombres a objetos en un momento específico temprano en el proceso.

Asignación de recursos o nombres a objetos en el momento en que se necesitan.

Asignación de recursos en un momento entre la vinculación anticipada y la postergada.

Estructura interna que gestiona la información de los archivos en el sistema de ficheros.

Punto en el proceso en el que un nombre se asigna a un objeto en un sistema operativo.

Variables definidas fuera de cualquier función y disponibles en toda la aplicación.

En las primeras etapas de desarrollo, las operaciones de entrada/salida (E/S) y el sistema de archivos pueden ser ignoradas, excepto por mecanismos básicos para leer desde el teclado y escribir en la pantalla, necesarios para la evaluación y depuración del código.

Las estructuras de datos de bajo nivel deben protegerse con acceso restringido a través de procedimientos específicos. Esto se logra a través de programación orientada a objetos, independientemente del lenguaje utilizado.

El proceso de desarrollo del sistema avanza de abajo hacia arriba, similar a la construcción de un edificio, donde los niveles inferiores se completan y evalúan primero, antes de continuar con los niveles superiores.

En equipos de desarrollo grandes, una alternativa al enfoque ascendente es diseñar todo el sistema primero y luego dividirlo en módulos que se desarrollan y prueban en forma independiente. Una vez que cada módulo está listo, se integran y evalúan en conjunto.

El método modular presenta el desafío de que si el sistema no funciona correctamente después de la integración, es difícil identificar si el fallo se debe a uno o más módulos, o a una mala interpretación entre módulos.

Los detalles específicos del hardware, en la medida de lo posible, deben ocultarse a las capas superiores del sistema, a menos que el hardware ofrezca capacidades especiales que deban ser expuestas.

Un nivel de abstracción, como HAL (Hardware Abstraction Layer), puede utilizarse para encapsular muchos detalles del hardware de bajo nivel.

Las interrupciones, aunque necesarias, pueden complicar la programación. Una forma de manejarlas es convertirlas en hilos emergentes para un manejo más inmediato.

Variables especiales que se definen durante la compilación de un programa para controlar comportamientos específicos del código, como la arquitectura del procesador o el tamaño de datos.

Mecanismo para incluir o excluir secciones de código durante la compilación, dependiendo del valor de una bandera de tiempo de compilación.

El tipo de datos 'Registro' se define como 'int' si 'LONG_PALABRA' es 32 y se define como 'long' si 'LONG_PALABRA' es 64.

Un archivo que contiene las definiciones de las banderas de tiempo de compilación, como 'CPU' y 'LONG_PALABRA'.

La compilación condicional mejora la eficiencia al incluir solo el código necesario para la arquitectura y configuración específicas del sistema.

La compilación condicional permite adaptar un programa a diferentes plataformas y configuraciones sin crear múltiples versiones del código.

En la figura 13-6(a), se utiliza una bandera llamada 'CPU' para elegir entre el código de inicialización para Pentium o UltraSPARC.

En la figura 13-6(b), se usa una bandera llamada 'LONG_PALABRA' para definir el tamaño de la variable 'Registro' según la arquitectura, ya que el código de 32 bits o 64 bits genera un tamaño diferente de dato.