1.1.2 Estructura general del sistema
operativo
Se ha visto el aspecto externo de los
sistemas operativos (es decir, la interfaz con el programador y con el
usuario), en este apartado se echará un vistazo al interior del sistema
operativo. En las subsecciones siguientes se examinarán algunas de las formas
posibles de estructurar el código de un sistema operativo. Los diseños
estudiados no son exhaustivos, pero dan una idea de las posibilidades.
Sistemas
monolíticos
Este tipo de organización es, con diferencia,
la más común. El sistema operativo se escribe como una colección de
procedimientos, cada uno de los cuales puede llamar a los demás cada vez que
así lo requiera. Cuando se usa esta técnica, cada procedimiento del sistema
tiene una interfaz bien definida en términos de parámetros y resultados, y cada
uno de ellos es libre de llamar a cualquier otro, si éste último proporciona un
cálculo útil para el primero.
Para construir el programa objeto
real del sistema operativo siguiendo este punto de vista, se compilan de forma
individual los procedimientos, o los ficheros que contienen los procedimientos,
y después se enlazan en un sólo fichero objeto con el enlazador.
En términos de ocultación de la información, ésta es prácticamente nula: cada
procedimiento es visible a los demás (en contraste con una estructura con
módulos o paquetes, en la que la mayoría de la información es local a un
módulo, y donde sólo los datos señalados de forma expresa pueden ser llamados
desde el exterior del módulo).
Los servicios (mediante llamadas al
sistema) que proporciona el sistema operativo se solicitan colocando los
parámetros en lugares bien definidos, como los registros o la pila,
para después ejecutar una instrucción especial de trampa, a veces referida como
llamada al núcleo o llamada al supervisor. Esta instrucción cambia la máquina
del modo usuario al modo núcleo (también conocido como modo supervisor), y
transfiere el control al sistema operativo, lo que se muestra en el evento (1)
de la figura 5.1.
El sistema operativo examina entonces
los parámetros de la llamada para determinar cual de ellas se desea realizar,
como se muestra en (2) de la figura 5.1. A continuación, el sistema operativo
analiza una tabla que contiene en la entrada k un apuntador al procedimiento
que implementa la k-ésima llamada al sistema. Esta operación, que se muestra en
(3) de la figura 5.1, identifica el procedimiento de servicio, al cual se
llama. Por último, la llamada al sistema termina y el control vuelve al
programa del usuario.
Esta organización sugiere una
estructura básica del sistema operativo:
Un programa
principal que llama al procedimiento del servicio solicitado.
Un conjunto
de procedimientos de servicio que lleva a cabo las llamadas al sistema.
Un conjunto
de procedimientos de utilidades que ayudan a los procedimientos de servicio.
En este modelo, para cada llamada al
sistema existe un procedimiento de servicio que se encarga de ella. Los
procedimientos de utilidad hacen cosas necesarias para varios procedimientos de
servicio, como por ejemplo, buscar los datos del programa del usuario. Esta división
de los procedimientos en tres capas se muestra en la figura 5.2.
Modelo
cliente-servidor
Una tendencia de los sistema
operativos modernos es la de trasladar el código a capas superiores, y eliminar
la mayor parte posible del sistema operativo para mantener un núcleo mínimo. El
punto de vista usual es el implantar la mayoría de las funciones del sistema
operativo como procesos de usuario. Para solicitar un servicio, como la lectura
de un bloque de cierto fichero, un proceso de usuario (denominado en este caso
proceso cliente)
envía la solicitud a un proceso servidor,
que realiza el trabajo y devuelve la respuesta.
En este modelo, que se muestra en la
figura 5.3, lo único que hace el núcleo es controlar la comunicación entre los
clientes y los servidores. Al separar el sistema operativo en partes, cada una
de ellas controla una faceta del sistema, como el servicio a ficheros, servicio
a procesos, servicio a terminales o servicio a la memoria; cada parte es
pequeña y controlable. Además, puesto que todos los servidores se ejecutan como
procesos en modo usuario, y no en modo núcleo, no tienen acceso directo al
hardware. En consecuencia, si hay un error en el servidor de ficheros éste
puede fallar, pero esto no afectará en general a toda la máquina.
Otra de las ventajas del modelo
cliente-servidor es su capacidad de adaptación para su uso en sistemas
distribuidos (véase la figura 5.4). Si un cliente se comunica con un servidor
mediante mensajes, el cliente no necesita saber si el mensaje se gestiona de
forma local, en su máquina, o si se envía por medio de una red a un servidor en
una máquina remota. En lo que respecta al cliente, lo mismo ocurre en ambos
casos: se envió una solicitud y se recibió una respuesta.
La idea anterior de un núcleo que
sólo controla el transporte de mensajes de clientes a servidores, y viceversa,
no es totalmente real. Algunas funciones del sistema operativo (como la
introducción de órdenes en los registros físicos de lo scontroladores de
E/S) son difíciles, si no es que imposible de realizar, a partir de
programas de usuario. Existen dos formas de afrontar este problema. Una es
hacer que algunos procesos de servidores críticos (por ejemplo, los gestores de
los dispositivos de E/S) se ejecuten en realidad en modo núcleo, con acceso
total al hardware, pero de forma que se comuniquen con los demás procesos
mediante el mecanismo normal de mensajes.
La otra forma es construir una
cantidad mínima de mecanismos dentro del núcleo, pero manteniendo las
decisiones de política relativos a los usuarios dentro del espacio de los
usuarios. Por ejemplo, el núcleo podría reconocer que cierto mensaje enviado a
una dirección especial indica que se tome el contenido de ese mensaje y se
cargue en los registros del controlador de algún disco, para iniciar la lectura
del disco. En este ejemplo, el núcleo ni siquiera inspeccionaría los bytes del
mensaje para ver si son válidos o tienen algún sentido; sólo los copiaría
ciegamente en losregistros del
controlador del disco. Es evidente que debe utilizarse cierto esquema para
limitar tales mensajes sólo a los procesos autorizados. La separación entre
mecanismos y política es un concepto importante, aparece una y otra vez en
diversos contextos de los sistemas operativos.
No hay comentarios:
Publicar un comentario