Estructura de Un SO

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 4

Kernel: Definición

Parte fundamental de un programa, por lo general de un sistema operativo, que reside


en memoria todo el tiempo y que provee los servicios básicos. Es la parte del sistema
operativo que está más cerca de la máquina y puede activar el hardware directamente
o unirse a otra capa de software que maneja el hardware.

La tarea del Kernel es ejecutar procesos (Software, aplicaciones o programas) y


facilitarles a los mismos la tarea de interacción con el Hardware, mediante la
comunicación entre procesos y llamadas al sistema (system calls).

Sistemas monolíticos
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.

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.

Sistemas de capas
Organizar el sistema operativo como una jerarquía de capas, cada una construida
encima de la que tiene abajo. El primer sistema construido de esta forma fue el sistema
THE, construido en Technische Hogeschool Eindhoven en Holanda por E. W. Dijkstra
(1968) y sus estudiantes. El sistema THE era un sistema simple de procesamiento por
lotes para una computadora holandesa, la Electrologica X8, que tenía 32K de palabras
de 27 bits (los bits eran costosos en aquel entonces).

El sistema tenía seis capas:

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.

Microkernels
La idea básica detrás del diseño de microkernel es lograr una alta confiabilidad al dividir
el sistema operativo en módulos pequeños y bien definidos, sólo uno de los cuales (el
microkernel) se ejecuta en modo kernel y el resto se ejecuta como procesos de usuario
ordinarios, sin poder relativamente.

En especial, al ejecutar cada driver de dispositivo y sistema de archivos como un


proceso de usuario separado, un error en alguno de estos procesos puede hacer que
falle ese componente, pero no puede hacer que falle todo el sistema. Así, un error en el
driver del dispositivo de audio hará que el sonido sea confuso o se detenga, pero la
computadora no fallará.

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.

Una generalización obvia de esta idea es hacer que los clientes y los servidores se
ejecuten en distintas computadoras, conectadas mediante una red de área local o
amplia. Como los clientes se comunican con los servidores mediante el envío de
mensajes, no necesitan saber si los mensajes se manejan en forma local en sus
propios equipos o si se envían a través de una red a servidores en un equipo remoto.
En cuanto a lo que al cliente concierne, lo mismo ocurre en ambos casos: se envían las
peticiones y se regresan las respuestas. Por ende, el modelo cliente-servidor es una
abstracción que se puede utilizar para un solo equipo o para una red de equipos.

Cada vez hay más sistemas que involucran a los usuarios en sus PCs domésticas
como clientes y equipos más grandes que operan en algún otro lado como servidores.
De hecho, la mayor parte de la Web opera de esta forma. Una PC envía una petición
de una página Web al servidor y la página Web se envía de vuelta. Éste es un uso
común del modelo cliente-servidor en una red.

Máquinas virtuales
Este sistema, que en un principio se llamó CP/CMS y posteriormente cambió su
nombre a VM/370, estaba basado en una astuta observación: un sistema de tiempo
compartido proporciona (1) multiprogramación y (2) una máquina extendida con una
interfaz más conveniente que el hardware por sí solo. La esencia de VM/370 es separar
por completo estas dos funciones.

El corazón del sistema, que se conoce como monitor de máquina virtual, se ejecuta
en el hardware solamente y realiza la multiprogramación, proporcionando no una, sino
varias máquinas virtuales a la siguiente capa hacia arriba. Sin embargo, a diferencia de
otros sistemas operativos, estas máquinas virtuales no son máquinas extendidas, con
archivos y otras características adecuadas. En vez de ello, son copias exactas del
hardware, incluyendo el modo kernel/ usuario, la E/S, las interrupciones y todo lo
demás que tiene la máquina real.

Como cada máquina virtual es idéntica al verdadero hardware, cada una puede
ejecutar cualquier sistema operativo que se ejecute directamente sólo en el hardware.
Distintas máquinas virtuales pueden (y con frecuencia lo hacen) ejecutar distintos
sistemas operativos.

En el sistema VM/370 original, algunas ejecutaban OS/360 o uno de los otros sistemas
operativos extensos de procesamiento por lotes o de procesamiento de transacciones,
mientras que otros ejecutaban un sistema interactivo de un solo usuario llamado CMS
(Conversational Monitor System; Sistema monitor conversacional) para los usuarios
interactivos de tiempo compartido.

En los últimos años, se han combinado nuevas necesidades, nuevo software y nuevas
tecnologías para convertirla en un tema de moda.

Primero hablaremos sobre las necesidades. Muchas compañías han ejecutado


tradicionalmente sus servidores de correo, servidores Web, servidores FTP y otros
servidores en computadoras separadas, algunas veces con distintos sistemas
operativos. Consideran la virtualización como una forma de ejecutarlos todos en la
misma máquina, sin que una falla de un servidor haga que falle el resto.

La virtualización también es popular en el mundo del hospedaje Web. Sin ella, los
clientes de hospedaje Web se ven obligados a elegir entre el hospedaje compartido
(que les ofrece sólo una cuenta de inicio de sesión en un servidor Web, pero ningún
control sobre el software de servidor) y hospedaje dedicado (que les ofrece su propia
máquina, lo cual es muy flexible pero no es costeable para los sitios Web de pequeños
a medianos).

Cuando una compañía de hospedaje Web ofrece la renta de máquinas virtuales, una
sola máquina física puede ejecutar muchas máquinas virtuales, cada una de las cuales
parece ser una máquina completa. Los clientes que rentan una máquina virtual pueden
ejecutar cualesquier sistema operativo y software que deseen, pero a una fracción del
costo de un servidor dedicado (debido a que la misma máquina física soporta muchas
máquinas virtuales al mismo tiempo).

Otro uso de la virtualización es para los usuarios finales que desean poder ejecutar dos
o más sistemas operativos al mismo tiempo, por decir Windows y Linux, debido a que
algunos de sus paquetes de aplicaciones favoritos se ejecutan en el primero y algunos
otros en el segundo.

También podría gustarte