Estructura de un S.O.
Sistema Monolítico
En este diseño, que hasta ahora se considera como la
organización más común, todo el sistema operativo se ejecuta como un solo
programa en modo kernel. El sistema operativo se escribe como una colección de
procedimientos, enlazados entre sí en un solo programa binario ejecutable
extenso. Cuando se utiliza esta técnica, cada procedimiento en el sistema tiene
la libertad de llamar a cualquier otro, si éste proporciona cierto cómputo útil
que el primero necesita. Al tener miles de procedimientos que se pueden llamar
entre sí sin restricción, con frecuencia se produce un sistema poco manejable y
difícil de comprender. Para construir el programa objeto actual del sistema
operativo cuando se utiliza este diseño, primero se compilan todos los
procedimientos individuales (o los archivos que contienen los procedimientos) y
luego se vinculan en conjunto para formar un solo archivo ejecutable, usando el
enlazador del sistema. En términos de ocultamiento de información, en esencia
no hay nada: todos los procedimientos son visibles para cualquier otro
procedimiento (en contraste a una estructura que contenga módulos o paquetes,
en donde la mayor parte de la información se oculta dentro de módulos y sólo
los puntos de entrada designados de manera oficial se pueden llamar desde el
exterior del módulo).
Esta organización sugiere una estructura básica para el
sistema operativo:
1. Un programa principal que invoca el procedimiento de
servicio solicitado.
2. Un conjunto de procedimientos de servicio que llevan a
cabo las llamadas al sistema.
3. Un conjunto de
procedimientos utilitarios que ayudan a los procedimientos de servicio.
Sistema por capas
El sistema tenía seis capas, como se muestra en la figura
1-25. El nivel 0 se encargaba de la asignación del procesador, de cambiar entre
un proceso y otro cuando ocurrían interrupciones o expiraban los
temporizadores. Por encima del nivel 0, el sistema consistía en procesos
secuenciales, cada uno de los cuales e podía programar sin necesidad de
preocuparse por el hecho de que había varios procesos en ejecución en un solo
procesador. En otras palabras, el nivel 0 proporcionaba la multiprogramación
básica de la CPU. La capa 1 se encargaba de la administración de la memoria.
Asignaba espacio para los procesos en la memoria principal y en un tambor de
palabras de 512 K que se utilizaba para contener partes de procesos (páginas),
para los que no había espacio en la memoria principal. Por encima de la capa 1,
los procesos no tenían que preocuparse acerca de si estaban en memoria o en el
tambor; el software de la capa 1 se encargaba de asegurar que las páginas se
llevaran a memoria cuando se requerían
La capa 2 se encargaba de la comunicación entre cada proceso
y la consola del operador (es decir, el usuario). Encima de esta capa, cada
proceso tenía en efecto su propia consola de operador. La capa 3 se encargaba
de administrar los dispositivos de E/S y de guardar en búferes los flujos de
información dirigidos para y desde ellos. Encima de la capa 3, cada proceso
podía trabajar con los dispositivos abstractos de E/S con excelentes
propiedades, en vez de los dispositivos reales con muchas peculiaridades. La
capa 4 era en donde se encontraban los programas de usuario. No tenían que
preocuparse por la administración de los procesos, la memoria, la consola o la
E/S. El proceso operador del sistema se encontraba en el nivel 5.
Microkernel
Con el diseño de capas, los diseñadores podían elegir en
dónde dibujar el límite entre kernel y usuario. Tradicionalmente todos las
capas iban al kernel, pero eso no es necesario. De hecho, puede tener mucho
sentido poner lo menos que sea posible en modo kernel, debido a que los errores
en el kernel pueden paralizar el sistema de inmediato. En contraste, los
procesos de usuario se pueden configurar para que tengan menos poder, por lo
que un error en ellos tal vez no sería fatal. Varios investigadores han
estudiado el número de errores por cada 1000 líneas de código (por ejemplo,
Basilli y Perricone, 1984; y Ostrand y Weyuker, 2002). La densidad de los
errores depende del tamaño del módulo, su tiempo de vida y más, pero una cifra
aproximada para los sistemas industriales formales es de diez errores por cada
mil líneas de código. Esto significa que es probable que un sistema operativo
monolítico de cinco millones de líneas de código contenga cerca de 50,000
errores en el kernel. Desde luego que no todos estos son fatales, ya que
algunos errores pueden ser cosas tales como emitir un mensaje de error
incorrecto en una situación que ocurre raras veces. Sin embargo, los sistemas
operativos tienen tantos errores que los fabricantes de computadoras colocan
botones de reinicio en ellas (a menudo en el panel frontal), algo que los
fabricantes de televisiones, estéreos y autos no hacen, a pesar de la gran
cantidad de software en estos dispositivos.
Modelo cliente-servidor
Una ligera variación de la idea del microkernel es
diferenciar dos clases de procesos: los servidores, cada uno de los cuales
proporciona cierto servicio, y los clientes, que utilizan estos servicios. Este
modelo se conoce como cliente-servidor.
A menudo la capa inferior es un microkernel, pero eso no es requerido.
La esencia es la presencia de procesos cliente y procesos servidor. La
comunicación entre clientes y servidores se lleva a cabo comúnmente mediante el
paso de mensajes. Para obtener un servicio, un proceso cliente construye un
mensaje indicando lo que desea y lo envía al servicio apropiado. Después el
servicio hace el trabajo y envía de vuelta la respuesta. Si el cliente y el
servidor se ejecutan en el mismo equipo se pueden hacer ciertas optimizaciones,
pero en concepto estamos hablando sobre el paso de mensajes.
Máquinas virtuales
Las versiones iniciales del OS/360 eran, en sentido
estricto, sistemas de procesamiento por lotes. Sin embargo, muchos usuarios del
360 querían la capacidad de trabajar de manera interactiva en una terminal, por
lo que varios grupos, tanto dentro como fuera de IBM, decidieron escribir
sistemas de tiempo compartido para este sistema. El sistema de tiempo compartido
oficial de IBM, conocido como TSS/360, se liberó después de tiempo y cuando por
fin llegó era tan grande y lento que pocos sitios cambiaron a este sistema. En
cierto momento fue abandonado, una vez que su desarrollo había consumido cerca
de 50 millones de dólares (Graham, 1970). Pero un grupo en el Scientific Center
de IBM en Cambridge, Massachusetts, produjo un sistema radicalmente distinto
que IBM aceptó eventualmente como producto. Un descendiente lineal de este
sistema, conocido como z/VM, se utiliza ampliamente en la actualidad, en las
mainframes de IBM (zSeries) que se utilizan mucho en centros de datos
corporativos extensos, por ejemplo, como servidores de comercio electrónico que
manejan cientos o miles de transacciones por segundo y utilizan bases de datos
cuyos tamaños llegan a ser hasta de varios millones de gigabyte.
