En el apartado 3 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.
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.
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 los controladores 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 los registros 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