Vanguard (microkernel)

Vanguard es un microkernel experimental discontinuado desarrollado en Apple Computer [ ^{1 ]} en el Grupo de Tecnología Avanzada de Apple (ATG), orientado a la investigación, a principios de la década de 1990. Basado en el ^V -System , Vanguard introdujo identificadores de objetos estandarizados y un sistema único de encadenamiento de mensajes para mejorar el rendimiento. Vanguard no se utilizó en ningún producto comercial de Apple. Su desarrollo finalizó en 1993 cuando Ross Finlayson, el investigador principal del proyecto, dejó Apple.

Vanguard era, en general, muy similar a V-System, pero añadía soporte para la programación orientada a objetos del sistema operativo . Esto significaba que las interfaces del núcleo y del servidor se exportaban como objetos, que podían heredarse y extenderse en código nuevo. Este cambio no tiene un efecto visible en el sistema; se trata principalmente de una modificación del código fuente que facilita la programación.

Por ejemplo, Vanguard contaba con una clase de entrada/salida (E/S) compatible con varios servidores, como servidores de red y de archivos , con la que las nuevas aplicaciones podían interactuar importando la interfaz de E/S y llamando a sus métodos. Esto también facilitó enormemente el desarrollo de nuevos servidores, ya que disponían de un estándar de programación y podían compartir el código con mayor facilidad.

Un concepto clave en casi todos los microkernels es dividir un kernel más grande en un conjunto de servidores que se comunican entre sí. En lugar de tener un único programa que controle todo el hardware de un sistema informático, las distintas tareas se distribuyen entre programas más pequeños a los que se les otorgan permisos para controlar diferentes partes de la máquina. Por ejemplo, un servidor puede controlar el hardware de red, mientras que otro se encarga de gestionar los discos duros . Otro servidor gestionaría el sistema de archivos , llamando a ambos servidores de nivel inferior. Las aplicaciones de usuario solicitan servicios enviando mensajes a estos servidores, utilizando algún tipo de comunicación entre procesos (IPC), en lugar de solicitar al kernel que realice este trabajo mediante una llamada al sistema (syscall) o una trampa .

En la arquitectura V, el sistema IPC parece estar conceptualmente modelado a partir de llamadas a procedimientos remotos (RPC) desde la perspectiva de la aplicación cliente . El cliente importaba un archivo de definición de interfaz que contenía información sobre las llamadas compatibles con el kernel u otras aplicaciones, y luego utilizaba esta definición para agrupar las solicitudes. Al ser invocadas, el kernel tomaba el control de inmediato, examinaba los resultados y pasaba la información al controlador adecuado, posiblemente dentro del propio kernel. Los resultados se devolvían al cliente a través del kernel.

El funcionamiento del sistema, tal como lo percibe la aplicación cliente, es muy similar al de un núcleo monolítico convencional . Si bien los resultados devueltos podían provenir de un gestor externo, esto era prácticamente invisible para el cliente. Los servidores que gestionaban estas solicitudes operaban de forma similar a los clientes, estableciendo conexiones con el núcleo para transmitir datos. Sin embargo, los servidores generalmente creaban nuevos hilos según fuera necesario para gestionar las solicitudes de mayor duración. Una vez procesadas y enviadas las respuestas, el hilo podía liberarse y los servidores podían pasar a un modo de recepción a la espera de nuevas solicitudes.

En contraste, la mayoría de los sistemas de microkernel se basan en un modelo de comunicaciones asíncronas , en lugar de llamadas a procedimientos síncronos . El sistema de microkernel canónico, Mach , modelaba los mensajes como E/S, lo que tiene varios efectos secundarios importantes. El principal es que los planificadores de tareas normales en sistemas tipo Unix normalmente bloquean a un cliente que espera una solicitud de E/S, por lo que las acciones de pausar y reiniciar aplicaciones que esperan mensajes ya estaban integradas en el sistema subyacente. La desventaja de este enfoque es que el planificador es bastante pesado , y su llamada representaba un serio cuello de botella en el rendimiento y conllevó grandes esfuerzos de desarrollo para mejorarlo. Bajo el modelo V-System, la sobrecarga de paso de mensajes se reduce porque no es necesario consultar al planificador de procesos; no hay dudas sobre qué debe ejecutarse a continuación, que es el servidor al que se llama. La desventaja del enfoque V es que requiere más trabajo para el servidor si la respuesta puede tardar algún tiempo en procesarse.

Una importante novedad del sistema IPC en Vanguard, a diferencia de V, fue el concepto de cadenas de mensajes , que permitía enviar un mensaje entre varios servidores que interactuaban en un solo viaje de ida y vuelta. En teoría, el encadenamiento podía mejorar el rendimiento de las operaciones comunes de varios pasos.

Consideremos el caso en que una aplicación cliente debe leer un archivo. Normalmente, esto requeriría un mensaje al kernel para localizar el servidor de archivos, seguido de tres mensajes adicionales: uno para convertir el nombre del archivo en un identificador de objeto, otro para abrir dicho identificador y, finalmente, un tercero para leer el archivo. Mediante el encadenamiento de Vanguard, el cliente podría construir un único mensaje que contuviera todas estas solicitudes. Este mensaje se enviaría al kernel y, posteriormente, se reenviaría al servidor de archivos, que procesaría las tres solicitudes antes de devolver los datos.

Gran parte de los problemas de rendimiento asociados a los sistemas de microkernel se deben a los cambios de contexto durante el intercambio de mensajes entre aplicaciones. En el ejemplo anterior, ejecutado en un sistema V, se producirían un total de ocho cambios de contexto: dos por cada solicitud, ya que el cliente alternaría entre el kernel y el sistema. En Vanguard, el uso de una cadena de mensajes reduciría este número a solo tres: uno del cliente al kernel, otro del kernel al servidor de archivos y, finalmente, del servidor al cliente. En algunos casos, la sobrecarga de un cambio de contexto es mayor que el tiempo que tarda en ejecutarse la solicitud, por lo que el mecanismo de encadenamiento de Vanguard podría generar mejoras de rendimiento reales.

V también introdujo un servicio de nombres distribuido simple . Este servicio almacenaba nombres de caracteres conocidos que representaban diversos objetos en un sistema V distribuido, por ejemplo, 2nd floor laser printer. Las aplicaciones podían solicitar al servidor de nombres objetos por su nombre y recibían un identificador que les permitía interactuar con dicho objeto. El servicio de nombres no era un servidor independiente, sino que era administrado por código en el núcleo. Compárese esto con el servidor de nombres completo del sistema operativo Spring , que no solo conocía los objetos dentro del sistema, sino que también era utilizado por otros servidores del sistema para traducir sus nombres privados, por ejemplo, nombres de archivos y direcciones IP.

En el sistema V, los objetos en los servidores se identificaban mediante una clave privada específica , por ejemplo, un entero de 32 bits . Los clientes enviaban estas claves a los servidores para mantener una comunicación sobre una tarea concreta. Por ejemplo, una aplicación podía solicitar al kernel el sistema de archivos y recibir una clave de 32 bits que representaba un identificador de programa. A continuación, utilizaba esa clave para enviar un mensaje al sistema de archivos solicitando que abriera el archivo , lo que resultaba en la devolución de una clave de 64 bits . En este ejemplo, las claves eran propiedad de los servidores; no existía un formato de clave común en todo el sistema.my addresses

Este tipo de resolución de nombres era tan común en V que los autores decidieron convertir estas claves en elementos de primera clase en Vanguard. En lugar de usar los identificadores de objeto que los servidores utilizaran por casualidad, en Vanguard se esperaba que todos los servidores comprendieran y devolvieran una clave global única de 128 bits , cuyos primeros 64 bits contenían un identificador de servidor y los últimos identificaban un objeto en ese servidor. El identificador del servidor se mantenía en el núcleo, lo que permitía transferir el mensaje a través de la red si el servidor referenciado se encontraba en una máquina remota. Para el cliente, esto era invisible. No está claro si los identificadores se asignaban aleatoriamente para evitar que software malintencionado los adivinara .