La Arquitectura Microkernel
La Arquitectura Microkernel
La Arquitectura Microkernel
RR-93/08
La arquitectura microkernel:
futuro de los sistemas operativos
Marisa Gil, Angel Toribio, Xavier Martorell
Departament d’Arquitectura de Computadors
Universitat Politècnica de Catalunya. Barcelona (Spain)
ABSTRACT
Con los avances tecnológicos y las nuevas necesidades que van teniendo los usuarios, los
sistemas operativos tradicionales, como UNIX, han ido aumentando en complejidad y tamaño.
En este caso, la tecnología de los microkernels aparece como solución para volver a la
sencillez y la simplicidad del UNIX1 original. Los microkernels ofrecen una plataforma software
donde poder desarrollar y transportar sistemas operativos, y entornos operativos en general, a
partir de aplicaciones que trabajen según el paradigma cliente-servidor.
En este informe, haremos un repaso desde los sistemas operativos tradicionales hasta la
aparición de los microkernels. Veremos la filosofía y características más relevantes que ofrece este
método de diseño de sistemas operativos, deteniéndonos en los ejemplos más importantes.
1. UNIX es una marca registrada de Unix Systems Laboratories Inc. en los Estados Unidos de America y
otros paises.
-1-
DAC/UPC Report No. RR-93/08
Las aplicaciones de sistema son programas ejecutables que acompañan al núcleo del
sistema operativo. Van desde el sencillo comando “ls”, que permite obtener la lista de los
ficheros de un directorio hasta herramientas tan útiles como el compilador de C o los
formateadores de texto. Los usuarios del ordenador dialogan con él mediante el uso de estas
aplicaciones, solas o combinadas para obtener el resultado deseado.
Los sistemas operativos, no obstante, fueron creciendo, para incorporar nuevas
funciones. Con la aparición de los sistemas de ficheros en red fue necesario añadir el software
de control de la red de comunicaciones y ampliar la semántica de las llamadas al sistema
referentes a ficheros y dispositivos; todo ello para permitir el acceso a sistemas de ficheros
remotos. Algunas versiones reforzaron la protección en el acceso a la información por parte de
los usuarios; otras intentaron ofrecer procesamiento en tiempo real; gestión de los
procesadores, distribución, ...
Con todo ello el núcleo de los sistemas operativos (también el núcleo de UNIX) creció
desmesuradamente. Y, UNIX, en concreto, con ello, dejó a un lado la filosofía con la que había
nacido: la sencillez.
-2-
DAC/UPC Report No. RR-93/08
Memory
Message Object
Task
Port
Region
Thread
Kernel
Abstracciones básicas
Es necesario observar que dentro de un proceso puede haber varios flujos ejecutándose
concurrentemente. Si consideramos que desde siempre un proceso ha representado una
máquina virtual que nos ofrece, entre otros recursos, un espacio de direcciones y un procesador,
ahora se ha ampliado esta idea añadiendo más procesadores; en estos momentos un proceso
ofrece un multiprocesador (cada flujo representa un procesador) y, si el ordenador dispone de
más de un procesador físico, será posible ejecutar más de un flujo en paralelo.
Un subsistema diseñado para ofrecer el interfaz UNIX a los usuarios tiene suficiente con
crear un proceso y asociarle un flujo para obtener un proceso UNIX tradicional.
-3-
DAC/UPC Report No. RR-93/08
Otras de las entidades que más destacan de las ofrecidas por los microkernels son, por los
enormes beneficios que aportan en la comunicación entre procesos, el port y el mensaje. Un
port suele representar una dirección donde enviar mensajes. Hace las veces, además, de buzón
ya que los mensajes recibidos se guardan en una cola asociada al port. Los procesos crean ports
y, a través de ellos, se intercambian información. Ésta viaja de un proceso a otro dentro de un
mensaje. Un mensaje es la estructura que se da a la información que se transmite junto con la
dirección (el port) desde donde se envía y la dirección donde se quiere hacer llegar.
El microkernel se ocupa de que todos los mensajes lleguen a su destino. Existe, incluso, la
posibilidad de que, de forma transparente al usuario, estas comunicaciones se lleven a cabo
entre procesos que residen en ordenadores diferentes. En este caso, el microkernel suele ser
cliente de un servidor de mensajes a través de la red. Este servidor tiene la misión de enviar
todos los mensajes destinados a ports remotos a través de la red y de recibir de ella los mensajes
enviados desde otros ordenadores hacia qualquiera de los ports locales.
Los microkernels han introducido, también, mejoras en la gestión de la memoria gracias a
la definición de segmentos y regiones. Un segmento es un objeto (cierta cantidad de
información) que puede ser representado en memoria. Ejemplos de segmentos pueden ser los
ficheros. Cuando un proceso quiere acceder a un segmento, lo hace mapeando parte de él en
una región de memoria. Una de estas regiones no es más que una parte del espacio de
direcciones del proceso donde éste puede leer y/o escribir.
El microkernel o alguno de los servidores se encargan de mantener la coherencia entre el
contenido de la memoria a la que está accediendo el proceso y el contenido del fichero. Así
mismo, aseguran que si dos procesos tienen los mismos datos (el mismo fichero) mapeados en
sus respectivos espacios de direcciones, las modificaciones que realiza uno de ellos son
inmediata y automáticamente vistas por el otro. Hay que observar aquí que, como en el paso de
mensajes, ambos procesos pueden estar en ordenadores distintos conectados en red.
Una vez descritas las herramientas que ofrece un microkernel es posible pensar en UNIX
no como un sistema operativo sino como un programa de aplicación que se ejecuta sobre el
microkernel. Un servidor o un conjunto de servidores pueden proporcionar a los programas
clientes, programas usuarios de UNIX, las abstracciones adecuadas.
En este tipo de arquitectura de sistemas operativos, el microkernel proporciona una serie
de servicios genéricos. La combinación de este conjunto de servicios primitivos forma una
plataforma estándar para el desarrollo de las funciones específicas de un sistema operativo en
particular. Estas operaciones pueden configurarse, de manera adecuada, como servidores que
gestionan los recursos físicos y lógicos del sistema, tales como ficheros, dispositivos y servicios
de comunicación a alto nivel.
La idea de que UNIX puede implementarse como una aplicación es la culminación lógica
de una tendencia que ha terminado implantándose en el diseño de sistemas operativos: la
arquitectura cliente-servidor.
Durante los últimos años el aumento en funcionalidad de los entornos informáticos ha
ido acompañado por el desarrollo de aplicaciones y herramientas basadas en el modelo
anteriormente mencionado. Los servicios de ficheros a través la red (Network File System
“NFS”, Andrew File System “AFS”), servicios de nombres (Domain Name Service “DNS”) y
servicios de bases de datos (Yellow Pages o últimamente denominado Network Information
-4-
DAC/UPC Report No. RR-93/08
System “NIS”) son tan solo algunas de las aplicaciones basadas en ese modelo y que se han
añadido a los sistemas operativos tradicionales.
Usando este enfoque se consigue modularidad, flexibilidad y transparencia de la red.
Estas características resultan imprescindibles ante la serie de cambios tecnológicos que se han
producido desde la aparición de UNIX. La modularidad permite una fuerte estructuración de
las funcionalidades requeridas. Esta estructuración junto con la transparencia de la red
permiten una fácil distribución del sistema sobre máquinas conectadas mediante redes locales.
La arquitectura microkernel hace posible disponer de sistemas informáticos hechos a
medida, la denominada “tailorability”. Por ejemplo versiones de UNIX como System V, y BSD
pueden simplemente tratarse como diferentes aplicaciones que se adquieren por separado y,
potencialmente, pueden ejecutarse a la vez que los otros entornos. Y no sólo es posible mezclar
diferentes versiones de UNIX entre sí, sino también es factible tener sistemas operativos como
DOS coexistiendo con UNIX.
Console
Mach 3.0
DOS
Network
Xterm Xterm
OSF/1 BSD
Coexistencia de subsistemas
-5-
DAC/UPC Report No. RR-93/08
detallado de algunos microkernels veremos como se han solucionado estos puntos: Mach
ofrece el mecanismo de transparent library de cara a ofrecer esta compatibilidad binaria.
Chorus, por otro lado, introduce los denominados “supervisor actors”, la adición de servidores
de manera dinámica, sin tener que parar la máquina, y el encadenamiento de manejadores de
interrupciones (“handlers”) para el servicio de los dispositivos periféricos.
La extensibilidad del propio sistema operativo así como el desarrollo de nuevas
versiones, e incluso de otros sistemas diferentes, se facilita de manera sustancial puesto que
éstas pueden construirse y depurarse junto con las versiones ya existentes. La nueva versión se
verá simplemente como un subsistema diferente. Los errores que se produzcan en la fase de
desarrollo no tienen por qué influir en el resto de programas que se ejecutan sobre la máquina.
Las barreras tradicionales al soporte de tiempo real desaparecen bajo el enfoque de los
microkernels puesto que el mismo kernel no precisa mantener bloqueos de las interrupciones
por tanto tiempo y porque los servicios de UNIX pueden desbancarse.
User
binary Debuger
UNIX User
binary
UNIX
SVR4 server
(secundario)
OSF/1 server
(principal)
Mach Kernel
Hardware
Extensibilidad y escalabilidad
-6-
DAC/UPC Report No. RR-93/08
4.1. V KERNEL
V kernel, desarrollado en Stanford en 1985, puede considerarse el primero de los
microkernels actuales en cuanto a su filosofía de diseño: ofrecer una plataforma base
(“backplane software”, en palabras de sus diseñadores) sobre la cual poder desarrollar
diferentes sistemas según las diferentes necesidades de los usuarios.
Sobre él, V System es el sistema operativo realizado a base de servidores y librerías de
emulación de UNIX, para hacerlo compatible con el software existente.
Se pensó para distribución en redes locales (LAN) por lo que el mecanismo y los
protocolos de comunicación entre procesos están incluidos en el kernel, por cuestiones de
eficiencia. Las abstracciones que exporta el kernel están todavía a caballo entre las de los
sistemas operativos tradicionales y los microkernels; por eso tiene todavía procesos, pero habla
de “grupo de procesos”, o teams, cuando trabajan con memoria compartida, y les llama
“procesos ligeros” (threads, en definitiva).
4.2. MACH
Mach es un kernel multiprocesador desarrollado en la Carnegie Mellon University a
partir de 1986 y sobre el que se continúa investigando en la actualidad. Mach fue elegido hace
años por la Open Software Foundation como núcleo del sistema operativo OSF-1. Este
microkernel comenzó siendo una modificación de UNIX BSD, añadiéndole nuevas
funcionalidades. Hasta la versión 3.0, no incluida, Mach era un sistema operativo monolítico.
En esta última versión se ha seguido ya la tendencia a construir el sistema como un microkernel
y un servidor del subsistema UNIX.
Además de las abstracciones básicas de task, thread, port y mensaje, Mach ofrece objetos
de memoria (porciones de datos que pueden ser mapeadas en una task para su posterior
manipulación). Los ports de Mach representan objetos, de manera que acceder a un objeto es
enviar un mensaje al port que lo identifica. En Mach los mecanismos de comunicación entre
procesos y la gestión de memoria están fuertemente integrados, habiéndose optimizado el
envío de mensajes de gran tamaño, por una parte, y la gestión de la memoria virtual, por la
otra.
Para emular los sistemas operativos tradicionales como UNIX, DOS y Macintosh, entre
otros, Mach se ayuda de la transparent library y servidores.
La transparent library es un mecanismo que permite que una llamada al kernel pueda ser
redireccionada fuera de él y convertirse en una llamada a un servidor o, incluso, ser tratada por
la propia librería. El código de esta librería se va heredando entre tasks (procesos UNIX).
Un servidor, en Mach, consiste en una task con varios flujos de ejecución (threads), que
realiza las funcionalidades del sistema operativo al que emule. En versiones más recientes, el
sistema operativo está incluso formado por diferentes servidores, cada uno representando una
funcionalidad concreta (el gestor de memoria, el sistema de ficheros, el planificador de
procesos); así se consigue una mayor explotación del paralelismo proporcionado por el
-7-
DAC/UPC Report No. RR-93/08
➂ Unix server
Transparent
Library BSD service threads
➃ Inode pager
➄
User Device threads
binary
UNIX
➁
Mach Kernel
Hardware
Tanto los fuentes del microkernel como toda la documentación asociada, incluidos
manuales y reports de investigación, pueden obtenerse a través de ftp anonymous a
mach.cs.cmu.edu.
4.3. CHORUS
Chorus1 es un microkernel desarrollado desde 1986, en el INRIA (Francia), pensado
inicialmente para sistemas de máquinas distribuidas. Uno de los objetivos primordiales de su
desarrollo fue el desplazar el mayor número posible de funciones fuera del núcleo, y demostrar
que UNIX podía construirse como un conjunto de módulos que no compartían memoria. La
versión actual mantiene muchos de los objetivos de las versiones iniciales y añade algunos más
como gestión de sistemas en tiempo real y la comercialización, ya que al poco tiempo el equipo
investigador se constituyó en su propia empresa Chorus Systèmes. El producto, que continúa
en evolución para adaptarse a las necesidades de los usuarios y en los últimos años Chorus ha
sido elegido por AT&T como núcleo para su versión microkernel de UNIX.
El concepto de task en Chorus se denomina actor, el resto de abstracciones fundamentales
tienen nombres idénticos. Sin embargo la semántica asociada a algunas de estas abstracciones
varía sustancialmente. Por ejemplo el concepto de port representa un servicio, identificado de
manera única en todo el sistema distribuido. De este modo, se facilita la migración de servicios
-8-
DAC/UPC Report No. RR-93/08
Process
Device Manager
Manager
Socket
Manager
File
Manager Chorus Nucleus Interface
Chorus Nucleus
Hardware
Estructura de Chorus/MiX V3
Puesto que Chorus Systèmes es una empresa privada, no es posible obtener el sistema si
no es pagando una licencia. Sin embargo es posible obtener información diversa, artículos
fundamentalmente, a través de ftp anonymous en opera.chorus.fr.
4.4. PAROS
Diseñado en la Universitat Politècnica de Catalunya, Paros difiere esencialmente de los
microkernels anteriores, porque se ha realizado para multiprocesadores de memoria
-9-
DAC/UPC Report No. RR-93/08
Ptask
Task Thread
Channel
Port
Paros abstractions.
Hemos visto que las arquitecturas microkernel proporcionan una sólida base para
solventar las necesidades actuales en la construcción de sistemas operativos, ofrecen un
“hardware virtual” o “backplane software”, que sirve como plataforma para el desarrollo y
transporte de sistemas operativos y de entornos de trabajo en general.
Esta arquitectura mantiene las mejores características de la herencia de UNIX
encuadradas en una nueva generación de entornos informáticos:
- 10 -
DAC/UPC Report No. RR-93/08
6. BIBLIOGRAFIA
[1] Michel Gien, “Micro-kernel design “. Unix review, vol. 8 No. 11.
[2] Marc Guillermont, et al. “A Second-Generation Micro-Kernel Based Unix; Lessons in
Performance and compatibility”. USENIX Winter’91. Dallas TX.
[3] Mike Accetta, et al., “Mach: A New Kernel Foundation For Unix development“.Proc.
of USENIX Summer'86 Conference, Atlanta, GA (9-13 June 1.986). pp. 93-112.
[4] Chorus Systèmes. “Overview of the Chorus Distributed Operating System”. Chorus
Systèmes Technical Report CS/TR-90-25.1.
- 11 -
DAC/UPC Report No. RR-93/08
[5] Chorus Systèmes. “Chorus Kernel v3.3 Specification and Interface”. Chorus
Systèmes Technical Report CS/TR-90-58.
[6] Jesús Labarta, Judit Jiménez, “BOS interface”. Esprit Project 2528, Supernode II.
Technical Report UPC-019-9103. Universitat Politécnica de Catalunya. Barcelona
(Spain) 1.991.
[7] Jesús Labarta, et al. “Kernel Evaluation”. Esprit Project 2528, Supernode II.
Technical Report UPC-018-9101. Universitat Politécnica de Catalunya. Barcelona
(Spain) 1.991.
[8] Marc Rozier et al. “Overview of the Chorus Distributed Operating Systems “.
Technical report CS/TR-90-25, Chorus systemes, April 1990.
[9] Vadim Abrossimov, Marc Rozier and Michel Gien. “Virtual Memory
Management in Chorus”. Technical report CS/TR-89-30.1, Chorus Systèmes,
May 1989.
[10] Vadim Abrossimov, Marc Rozier and Marc Shapiro. “Generic Virtual Memory
Management for operating systems kernels”. Technical report CS/TR-89-18,
Chorus Systèmes, September 1989.
[11] Vadim Abrossimov, François Armand, Maria Inés Ortega. “A Distributed
Consistency server for the Chorus System”. Technical report CS/TR-91-91,
Chorus Systèmes, March 1992.
[12] Gerald Malan, Richard Rashid, David Golub, Robert Baron. “DOS as a Mach 3.0
Application”.
[13] José Rogado, Michael Condict, Philippe Bernadat, Simon Patience, François
Borbon del Places. “The OSF/1 server: implementing a UNIX server using
micro-kernel technology (Extended Abstract”.
[14] David R. Cheriton. “The V distributed System”. Communications of the ACM,
vol. 31, num. 3, Marzo 1988.
- 12 -