Download La arquitectura microkernel: futuro de los sistemas operativos

DAC/UPC Report No. 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.
Desde los inicios de la Informática, paralelamente al desarrollo del hardware, surgió la
necesidad de suministrar un software de base que realizase las funciones de control del
ordenador. Al principio, este software estaba formado por un conjunto de rutinas que se
cargaban en la memoria del ordenador y proporcionaban, entre otras, operaciones de entrada/
salida de información desde o hacia los dispositivos.
Este conjunto de rutinas fue creciendo en complejidad a medida que se le fueron
asignando más funciones. Contribuyeron a ello, por un lado, nuevos componentes hardware
cada vez más modernos y complicados de manejar (cintas, discos y, más recientemente, la red
de comunicaciones); y, por otro lado, el cada vez mayor número de aplicaciones que se
ejecutaban sobre los ordenadores. Era necesario ofrecer un software de base que controlase su
ejecución.
Nacen, a partir de ese momento los sistemas operativos tradicionales. Entre ellos, UNIX
destaca pronto por su sencillez en el diseño y por su fácil portabilidad.
UNIX tradicional está formado por un núcleo (el sistema operativo propiamente dicho) y
por un conjunto de aplicaciones de sistema. El núcleo reside en memoria desde el “boot” del
ordenador. Se encarga, principalmente, de la gestión de procesos, del acceso a ficheros y
dispositivos, de la gestión de la memoria y de ciertos aspectos de la protección de la
información entre los usuarios.
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.
1.
MICROKERNELS COMO PLATAFORMAS PARA SISTEMAS OPERATIVOS
En los entornos distribuidos y en el diseño de aplicaciones había empezado a usarse el
modelo de programación llamado cliente-servidor. En este modelo las aplicaciones están
compuestas por diferentes procesos que colaboran para llevar a cabo su objetivo. De hecho, una
aplicación está formada por dos tipos de procesos: unos, los servidores, ofrecen un interfaz a
través del cual los otros, los clientes, piden su servicio, consiguiendo, en general, realizar un
trabajo de mayor complejidad. Un proceso cliente puede ser a la vez servidor de otro proceso.
Los procesos suelen comunicarse a través de paso de mensajes.
Se necesitaba una herramienta para cambiar la forma de diseñar sistemas operativos y el
modelo de programación cliente-servidor fue utilizado para encontrarla. Aplicando este
modelo al diseño de sistemas operativos, parte de los servicios que ofrecen éstos, si no todos,
pueden construirse como procesos servidores. De esta forma se ve un sistema operativo como
una aplicación. Al conjunto de servidores que proporcionan el interfaz de un sistema operativo
lo denominamos subsistema. Inicialmente los subsistemas se ejecutaban en modo privilegiado
como los sistemas operativos tradicionales. El siguiente paso es pensar que los subsistemas
puedan ejecutarse en modo usuario.
Podemos, pues, disponer de un servidor de ficheros, de un gestor de procesos, de un
gestor de memoria virtual, de un proceso encargado de verificar los accesos a la información,
etc. Todos ellos constituyen un subsistema y se ejecutan sobre un software de base que controla
el ordenador: el microkernel.
Los microkernels realizan la gestión básica del ordenador. Así, reciben las interrupciones
de los dispositivos y las excepciones (fallos de página, división por cero, ...) e invocan la rutina
que las gestiona o pasan un mensaje hacia el proceso encargado de resolverlas; llevan a cabo la
gestión de procesos, permitiendo, con frecuencia, ejecución en tiempo real; controlan las
comunicaciones entre procesos (la base del modelo cliente-servidor); reparten la memoria del
ordenador; en los multiprocesadores, permiten controlar el número de procesadores que están
ejecutando código de usuario. Con los microkernels se ha vuelto a la filosofía UNIX original: la
sencillez; y, con ella, la gestión del sistema realizada por el microkernel podrá ser más eficiente
y más fácil de diseñar, escribir y mantener.
-2-
DAC/UPC Report No. RR-93/08
2.
SERVICIOS OFRECIDOS POR LOS MICROKERNELS
Aunque, evidentemente, cada microkernel tiene sus peculiaridades, en general todos
ellos proporcionan un interfaz parecido. Entre las abstracciones, o entidades exportadas hacia
el nivel de los subsistemas, que componen el interfaz, están los procesos (denominados tasks o
actors), los flujos de ejecución (threads), los ports de comunicaciones, los mensajes, los
segmentos y las regiones de memoria. A continuación se exponen las características comunes
de estas abstracciones en la mayoría de microkernels.
Un proceso es una entidad a la cual se asocian recursos del sistema (memoria,
procesadores, ficheros, ...). Podemos verlo como la unidad de asignación de recursos. Véase la
similitud con un proceso UNIX, el cual tiene un espacio de direcciones delimitado, una tabla de
ficheros abiertos a los que puede acceder, etc.
Tradicionalmente, el sistema operativo asocia un procesador a los procesos para que se
ejecuten. Sin embargo, en un microkernel, para que un programa de usuario se ejecute es
necesario tener algo más que un proceso con el programa cargado en memoria: los procesos
han de contener, como mínimo, un flujo de ejecución (o thread). Los flujos son uno de los
recursos que se pueden asociar a los procesos y consiste en la representación de código
ejecutándose o, lo que es lo mismo, representa un procesador virtual. Dicha representación
contiene los registros del procesador físico asociado, así como la prioridad de ejecución, etc.
Memory
Object
Message
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.
3.
UNIX PUEDE VERSE COMO UNA APLICACIÓN
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
Otro punto interesante a tener en cuenta es la portabilidad de los sistemas operativos.
Gran parte del código que constituye UNIX es independiente del repertorio de instrucciones de
la máquina, arquitectura y configuración. Por tanto si se identifica qué código es dependiente
de la arquitectura y cuál no, disponer de un sistema operativo como UNIX para una nueva
máquina requiere un menor esfuerzo que usando el tradicional enfoque monolítico de un
sistema operativo. La relativa estandarización y aislamiento que ofrece el interfaz del
microkernel permite aprovechar el mismo código para arquitecturas variopintas tales como
monoprocesadores o multiprocesadores, “embedded systems” y arquitecturas en red.
La portabilidad descrita hasta ahora se refiere estrictamente al código fuente del sistema
operativo. En general se ha de compilar y montar este código con el microkernel. Sin embargo
la industria informática necesita cada vez más una mayor portabilidad, estandarización y
compatibilidad en todos los ámbitos. Se necesitan interfaces compatibles no sólo a nivel de
programas de aplicación sino también a nivel de drivers de dispositivos y de otros
componentes. En muchos casos además se precisa compatibilidad binaria del código. Estos
aspectos afectan a la estructura y organización de los sistemas operativos. Con el estudio
-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
UNIX
Debuger
User
binary
UNIX
SVR4 server
(secundario)
OSF/1 server
(principal)
Mach Kernel
Hardware
Extensibilidad y escalabilidad
Es posible obtener sistemas tolerantes a fallos de manera más sencilla. En la transmisión
de mensajes el microkernel permite duplicar servidores que residirán en máquinas diferentes,
de modo que la desaparición de algún servidor y la aparición de su relevo no tienen por qué ser
percibidos por los usuarios del sistema.
Una vez vistas todas estas características ventajosas, también debemos tener en cuenta
que los sistemas basados en la arquitectura microkernel se enfrentan a una serie de retos puesto
que deben competir con las versiones monolíticas de los sistemas operativos que ellos
soportan. Podríamos plantearnos si resulta posible que un sistema basado en la arquitectura
microkernel ofrezca el mismo rendimiento que un sistema monolítico. La elegancia y
flexibilidad del modelo cliente-servidor exige un coste en el manejo de los mensajes y en el
cambio de contexto. Si este coste es excesivamente alto limitará su aceptación por parte de la
industria informática.
-6-
DAC/UPC Report No. RR-93/08
4.
ARQUITECTURAS MICROKERNEL MAS IMPORTANTES
A continuación describiremos las principales características de los microkernels más
conocidos. Algunos de ellos son tan solo conocidos en el mundo académico, otros sin embargo,
están en plena fase de comercialización.
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
microkernel y, en determinados casos, facilitan la distribución, aunque Mach no ha sido
diseñado como sistema distribuido.
Estos servidores pueden coexistir, de manera que estén ejecutándose a la vez aplicaciones
sobre diferentes sistemas operativos. En la actualidad, existen sobre Mach servidores de UNIX
4.3BSD, MS-DOS, Macintosh, OSF/1 y System V4.2, además de servidores generales como
gestores externos de memoria, planificadores de procesadores y servidores de red.
➂
Transparent
Library
➃
Unix server
BSD service threads
Inode pager
➄
User
binary
UNIX
Device threads
➁
➀
Mach Kernel
Hardware
Emulación de UNIX mediante el servidor y la Transparent Library
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
1. Chorus y Chorus-MiX son marcas registradas de Chorus Systèmes.
-8-
DAC/UPC Report No. RR-93/08
de una máquina a otra, la replicación de servicios en diferentes máquinas (mediante los
llamados grupos de ports) y la transparencia de localización de servicios por parte de los
usuarios.
Chorus/MiX, que es el subsistema UNIX compatible binario con Santa Cruz Operation,
está formado por cuatro tipos servidores, cada uno de ellos especializado en la gestión de
procesos, ficheros, dispositivos y “sockets”. Cada servidor se implementa como un actor con
varios threads, puesto que éste posee su propio contexto puede residir en cualquier máquina de
la red de comunicaciones y por el mismo motivo puede “debugarse” sin afectar al resto del
subsistema. La forma habitual de pedir un servicio a uno de estos servidores es mediante
mensaje con lo cual se obtiene transparencia de la red. Sin embargo, y de cara a soportar
compatibilidad binaria con UNIX, algunos de estos servidores (el gestor de procesos en
concreto) ofrecen un interfaz de traps.
Una última característica a resaltar es la posibilidad de configurar un sistema a medida,
de modo que se cargen solo los servidores necesarios en cada máquina. De todos modos, si
fuere necesaria una ampliación de funcionalidades, Chorus permite cargar cualquier servidor
sin tener que parar la máquina. Estos servidores se cargan en espacio de memoria privilegiado
y son capaces de conectar rutinas de atención a los eventos hardware del ordenador, rutinas
que se encadenan con las ya existentes. Mach por el contrario tiene todos los “drivers” de
dispositivos montados con el kernel y requiere recompilar para añadir la capacidad de manejar
nuevos dispositivos.
aplicaciones y utilidades UNIX
Unix System Calls
Device
Manager
File
Manager
Process
Manager
Socket
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
distribuida. En concreto, su desarrollo inicial ha sido sobre transputers, aunque es portable a
cualquier otro tipo de procesador que trabaje con el mismo paradigma de memoria.
El modelo de proceso, está dividido en tres niveles: Ptask (parallel task), que es la unidad
de contaje y de asignación de recursos de la aplicación; task, que es la unidad de asignación de
memoria (cada task representa un único espacio de direcciones), unidad también de
paralelismo; y el thread que es la unidad de ejecución, flujo de control que se ejecuta
secuencialmente y permite concurrencia. Una Ptask puede estar formada por varias tasks y
cada una de éstas, a su vez, puede contener varios threads.
El paradigma de comunicación también es original, realizando, a partir de canales, el
dual de la comunicación a través de memoria compartida; éstos permiten una comunicación
optimizada entre tasks pertenecientes a una misma Ptask. Entre Ptasks, la comunicación es por
ports.
El entorno operativo UNIX se consigue en Paros a partir de librerías, que permiten
trabajar en un medio compatible. No se puede decir propiamente que, de momento, tenga un
subsistema UNIX.
Paros es un software de libre distribución a través de ftp.ac.upc.es, de donde puede
obtenerse además toda la documentación necesaria.
Ptask
Task
Thread
Channel
Port
Parallel application
Parallel service
Paros abstractions.
5.
EL FUTURO DE LOS MICROKERNELS
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
- reusabilidad de componentes del sistema.
- fuerte concepto de estructuración que favorece la distribución.
- transparencia de la red.
- soporte a la de escalabilidad de sistemas.
- posibilidad de ofrecer tolerancia a fallos.
- compatibilidad con interfaces estándar y sistemas abiertos.
Aunque durante una década se ha estado trabajando en la creación, definición y
refinamiento de los objetos que soportan los microkernels, así como las interfaces que ofrecen
para manejarlos, vemos que existen aún temas en los que se debe profundizar en los próximos
años.
Se ha llegado a un conjunto mínimo de abstracciones definidas de manera que, por un
lado permitieran máxima flexibilidad y adaptación a los niveles superiores, y por otro
ofrecieran la robustez adecuada. Esto ha llevado a códigos fuente del orden de casi dos
megabytes, en contra de la idea que podría suponer. Este crecimiento algo desmesurado podría
sugerir la necesidad de comenzar de nuevo para definir las operaciones y objetos de manera
más sencilla aún.
Por lo que respecta a las arquitecturas multiprocesador con memoria compartida,
podemos afirmar que se ha alcanzado un consenso mundial en cuanto a los conceptos básicos
que se han de ofrecer y gestionar; ahora la investigación ya puede ir más allá y plantearse
objetivos de eficiencia en la planificación de los recursos. Sin embargo la definición de la
arquitectura microkernel en el ámbito de los multiprocesadores con memoria distribuida
requiere aún seguir un proceso de maduración para alcanzar una solidez y estabilidad
comparables a la arquitectura hardware mencionada anteriormente.
Si bien una característica destacable de los microkernels es la portabilidad, existen
problemas relacionados con ésta que deben aún resolverse. En la actualidad es posible
transportar subsistemas a arquitecturas hardware dispares, sin embargo no resulta posible
transportar subsistemas entre arquitecturas microkernel diferentes. No está tan claro que un
subsistema UNIX construido para el microkernel Mach sea portable al microkernel Chorus, o
viceversa, con sólo unos pequeños retoques. Por tanto es necesario y deseable trabajar en la
estandarización de estas plataformas.
La última batalla por ganar es la de lograr la cooperación de los diseñadores de
microkernels con los programadores de aplicaciones paralelas; de forma que los primeros sean
capaces de ofrecer a los últimos todo el potencial que actualmente han de obtener directamente
del hardware, unido a la flexibilidad que ofrece la arquitectura microkernel.
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 -