Las abstracciones del sistema

En general, y antes de discutir el diseño de cada abstracción en particular, hemos seguido los siguientes pasos en el diseño de las abstracciones del sistema:

• Partir de la ``abstracción'' implementada por el hardware.
• Abstraerla lo necesario para que pueda utilizarse (referenciarse e invocarse) desde otros nodos de la red.
• Mantenerla en ese nivel de abstracción.

Al contrario que Engler [60], nosotros no creemos que si una abstracción es ``portable'' su nivel de abstracción es (probablemente) demasiado alto. En este sentido, la filosofía de Off está de acuerdo con lo sostenido por J. Liedtke [110]:

``Es posible alcanzar kernels con buen rendimiento mediante implementaciones específicas [para una arquitectura] de abstracciones independientes [de la arquitectura].''

La diferencia estriba en que, en el caso de Off, estas abstracciones son tan sólo las suministradas por el hardware. Cualquier otra abstracción de más alto nivel debiera ser suministrada por las aplicaciones. Un buen esquema para ello podría ser el uso de la orientación a objetos tal y como pusieron de manifiesto (ver alguno de [28, 32, 141, 114, 29]) sistemas como Choices [31] y Choices. .

Retomando el compromiso entre adaptabilidad y transparencia en la distribución, mencionado en el apartado 1.1, éste no parece deberse a ninguna propiedad inherente a los sistemas distribuidos. Parece deberse en cambio al nivel en que situamos la barrera entre el kernel y los servicios realizados en área de usuario: si la situamos en niveles superiores perdemos adaptabilidad y ganamos transparencia, si la situamos en niveles inferiores perdemos transparencia y ganamos adaptabilidad.

En Off hemos tratado de ``bajar'' esa barrera tanto como sea posible y nos hemos centrado en el diseño de tres abstracciones elementales, utilizadas como base para que las aplicaciones puedan implementar servicios de más alto nivel sobre ellas tales como gestión distribuida de procesos y memoria junto con mecanismos de IPC.

La elección de cuántas y qué abstracciones debe suministrar el sistema es siempre complicada y, como ya dijimos en el capítulo anterior, siempre suele resolverse insatisfactoriamente (al menos para algunas aplicaciones). Otro agravante es la contradicción existente en el proceso de elección [39]:

La facilidad de reconfiguración requiere abstracciones únicas e inamovibles; la flexibilidad se mejora con el uso de múltiples abstracciones; y, la eficiencia mejora cuando no hay abstracciones.

En el prototipo de DAMN hemos adoptado como abstracciones aquellas derivadas (mediante su extensión a la red) de las suministradas por el hardware y algunas otras (como shuttles y portales) que son necesarias para implementar en área de usuario servicios tradicionalmente suministrados por el sistema operativo (gestión de procesos e intercomunicación de procesos).

Hemos partido de las siguientes ``abstracciones'' suministradas por el hardware disponible en la red:

• Contextos de procesador. Constituidos por un conjunto de valores para los registros disponibles, incluyendo también aquellos registros que definen parte del contexto como registros base de tablas de páginas, etc.
• Interrupciones y excepciones. Constituidas por un número asociado a la línea de interrupción o excepción considerada y por determinados valores que identifican el manejador del evento considerado.
• TLBs y Tablas de páginas. En realidad, un conjunto de traducciones (incluyendo protecciones) de direcciones virtuales de memoria a direcciones físicas de memoria.
• Marcos de página. Fragmentos de memoria que pueden ser el destino de una traducción en una TLB o tabla de páginas.
• Puertos de E/S. Direcciones de un nodo que admiten operaciones de E/S.

Estos elementos implementados directamente en hardware se han abstraído hasta el punto en que pueden referenciarse y utilizarse de forma remota. Este proceso de abstracción ha permitido dotarlos de la capacidad de migrar y persistir y, debido al escaso nivel de abstracción empleado, mantener al mismo tiempo la adaptabilidad.

• Shuttles. Contextos hardware extensibles reemplazan en Off a los contextos de procesador. Pueden instalarse en un procesador para su ejecución y son el soporte para la ejecución de tareas, procesos y threads o flujos de control --abstracciones estas que debe implementar el software de aplicación que ejecute sobre Off.

  Los Shuttles pueden cambiar de procesador al igual que en sistemas multiprocesador, con la salvedad de que en Off los procesadores origen y destino pueden residir en distintos nodos. La estructura que presentan internamente (esto es, los valores de los registros del procesador y de las extensiones que presenten) es accesible al usuario lo mismo que ocurre con los contextos hardware.

  No soportan migración entre sistemas heterogéneos ya que no hay un único y mejor modo de implementar esta habilidad. No obstante, se le suministran al usuario los mecanismos necesarios para implementar diversos sistemas de migración heterogénea.

• Portales. Abstraen las interrupciones hardware así como los traps y excepciones. Igual que ocurre con los Shuttles, no se fuerza la distinción entre portales locales y remotos. Una interrupción puede tratarse en otro nodo si se considera oportuno --aunque en general esto es una mala práctica.

  Permiten implementar diversos mecanismos de intercomunicación de procesos incluyendo RPCs, transferencias protegidas de control y envío de mensajes asíncronos. Además, como suele ocurrir con sistemas de IPC en otros kernels, se utilizan como puntos de acceso al sistema de forma local o remota, de tal modo que en realidad sólo se utilizan llamadas al sistema para utilizar portales; el resto de los servicios están disponibles mediante portales.

• DTLBs. Abstraen el hardware de traducción de direcciones, permitiendo el uso de traducciones hacia marcos de página de otros nodos. Igual que ocurre en algunos multiprocesadores, la coherencia en el manejo de la memoria compartida se deja bajo el control de los usuarios del sistema.

Otros elementos manejados por el sistema son los siguientes:

• Nodos. Elementos que contienen procesadores, bancos de memoria, y puertos de entrada/salida.
• Bancos de memoria. Formados por un conjunto de marcos de página de un tamaño determinado.
• Bancos de E/S. Formados por un conjunto de puertos de E/S.
• Marcos de página. Instalados en un banco de memoria perteneciente a un nodo.
• Puertos de E/S. Instalados en un nodo. Incluimos en esta categoría los relojes existentes en la red.
• Procesadores. Capaces de ejecutar código, recibir interrupciones y traps.
• Interrupciones. Diferentes en cada procesador.
• Traps. Excepciones provocadas por la ejecución de código en un procesador.

Estos han necesitado pocas modificaciones con respecto a los suministrados directamente por el hardware. Por este motivo no son tan centrales en el diseño de Off como lo son las tres abstracciones básicas que mencionamos primero.

Dado que dedicamos un capítulo a las tres abstracciones básicas, discutiremos el resto de los servicios del sistema junto con la abstracción básica con la que se más se relacionen: veremos la gestión de procesadores al describir los Shuttles; interrupciones y traps al describir los portales; y los marcos de página y puertos de E/S al describir las DTLBs.

Lo que resta de capítulo lo dedicaremos a ciertos aspectos que, aún teniendo que ver con las abstracciones y servicios suministrados por el sistema, afectan al sistema en su conjunto.