Mach (núcleo)

Mach () es un núcleo desarrollado en la Universidad Carnegie Mellon por Richard Rashid y Avie Tevanian para respaldar la investigación de sistemas operativos, principalmente computación distribuida y paralela. Mach a menudo se considera uno de los primeros ejemplos de un microkernel. Sin embargo, no todas las versiones de Mach son micronúcleos. Los derivados de Mach son la base del kernel del sistema operativo en GNU Hurd y del kernel XNU de Apple utilizado en macOS, iOS, iPadOS, tvOS y watchOS.

El proyecto en Carnegie Mellon se desarrolló entre 1985 y 1994 y finalizó con Mach 3.0, que es un verdadero microkernel. Mach se desarrolló como reemplazo del kernel en la versión BSD de Unix, por lo que no sería necesario diseñar un nuevo sistema operativo a su alrededor. Mach y sus derivados existen dentro de varios sistemas operativos comerciales. Estos incluyen todos los que utilizan el kernel del sistema operativo XNU, que incorpora un Mach anterior sin microkernel como componente principal. El sistema de administración de memoria virtual Mach también fue adoptado en 4.4BSD por los desarrolladores de BSD en CSRG y aparece en los sistemas Unix modernos derivados de BSD, como FreeBSD.

Mach es el sucesor lógico del kernel Accent de Carnegie Mellon. El desarrollador principal del proyecto Mach, Richard Rashid, ha estado trabajando en Microsoft desde 1991; fundó la división de investigación de Microsoft. Otro de los desarrolladores originales de Mach, Avie Tevanian, fue jefe de software en NeXT y luego director de tecnología de software en Apple Inc. hasta marzo de 2006.

Historia

Nombre

Los desarrolladores tuvieron que ir en bicicleta a almorzar a través de los charcos de lodo lluviosos de Pittsburgh, y Tevanian bromeó con la palabra "muck" podría formar un backronym para su Multi-User (o Multiprocessor Universal) C Kernel de comunicación. El ingeniero italiano de CMU, Dario Giuse, luego le preguntó al líder del proyecto, Rick Rashid, sobre el título actual del proyecto y recibió 'MUCK'. como respuesta, aunque no deletreada sino pronunciada: IPA: [mʌk] que él, según el alfabeto italiano, escribió como Mach. A Rashid le gustó la ortografía de Giuse "Mach" tanto que prevaleció.

Tubos Unix

Un concepto clave en el sistema operativo Unix original era la idea de una tubería. Una tubería era una abstracción que permitía mover datos como un flujo de bytes no estructurado de un programa a otro. Usando canalizaciones, los usuarios (o programadores) podrían vincular varios programas para completar tareas, alimentando datos a través de varios programas pequeños a su vez. Esto contrastaba con los sistemas operativos típicos de la época, que requerían un solo programa grande que pudiera manejar toda la tarea o, alternativamente, usaban archivos para pasar datos, lo que requería mucho tiempo y recursos.

Las tuberías se construyeron sobre el sistema de entrada/salida subyacente. Este sistema, a su vez, se basaba en un modelo en el que se esperaba que los conductores "bloquear" mientras esperaban que se completaran las tareas. Por ejemplo, un controlador de impresora puede enviar una línea de texto a una impresora de línea y luego no tener nada que hacer hasta que la impresora termine de imprimir esa línea. En este caso, el controlador indicaría que estaba bloqueado y el sistema operativo permitiría que se ejecutara algún otro programa hasta que la impresora indicara que estaba lista para recibir más datos. En el sistema de tuberías, el recurso limitado era la memoria, y cuando un programa llenaba la memoria asignada a la tubería, naturalmente se bloqueaba. Normalmente, esto haría que el programa de consumo se ejecutara, vaciando la tubería nuevamente. En contraste con un archivo, donde el archivo completo debe leerse o escribirse antes de que el siguiente programa pueda usarlo, las canalizaciones hicieron que el movimiento de datos a través de múltiples programas ocurriera de manera fragmentada sin la intervención de ningún programador.

Sin embargo, la implementación de canalizaciones en los búferes de memoria obligó a que los datos se copiaran de un programa a otro, una operación que consumía mucho tiempo y recursos. Esto hizo que el concepto de tubería no fuera adecuado para tareas en las que se necesitaba una respuesta rápida o baja latencia, como en la mayoría de los controladores de dispositivos. En cambio, el núcleo del sistema operativo y la mayor parte de la funcionalidad principal se escribieron en un solo programa grande. Cuando se agregó al sistema operativo una nueva funcionalidad, como redes informáticas, el tamaño y la complejidad del núcleo también crecieron.

Nuevos conceptos

Los conductos de Unix ofrecían un sistema conceptual que podía utilizarse para crear soluciones arbitrariamente complejas a partir de pequeños programas interactivos. Al ser más pequeños, estos programas eran fáciles de programar y mantener, y tenían interfaces bien definidas que simplificaban la programación y la depuración. Estas cualidades son aún más valiosas para los controladores de dispositivos, donde el tamaño pequeño y el rendimiento sin errores son extremadamente importantes. Había un fuerte deseo de modelar el propio núcleo sobre la misma base de pequeños programas interactivos.

Uno de los primeros sistemas en utilizar un sistema similar a una tubería como base del sistema operativo fue el núcleo Aleph desarrollado en la Universidad de Rochester. Esto introdujo el concepto de puertos, que eran esencialmente una implementación de memoria compartida. En Aleph, el propio kernel se reducía a proporcionar acceso al hardware, incluida la memoria y los puertos, mientras que los programas convencionales que utilizaban el sistema de puertos implementaban todo el comportamiento, desde los controladores de dispositivos hasta los programas de usuario. Este concepto redujo en gran medida el tamaño del kernel y permitió a los usuarios experimentar con diferentes controladores simplemente cargándolos y conectándolos en tiempo de ejecución. Esto alivió en gran medida los problemas al desarrollar un nuevo código de sistema operativo, que de otro modo generalmente requería reiniciar la máquina. El concepto general de un kernel pequeño y controladores externos se conoció como microkernel.

Aleph se implementó en las minicomputadoras Data General Eclipse y estaba estrechamente vinculada a ellas. Esta máquina estaba lejos de ser ideal, ya que requería que la memoria se copiara entre programas, lo que implicaba una sobrecarga de rendimiento considerable. También era bastante caro. Sin embargo, Aleph demostró que el sistema base era sólido y pasó a demostrar la agrupación de computadoras copiando la memoria en una de las primeras interfaces de Ethernet.

Por esta época, estaba llegando al mercado una nueva generación de procesadores centrales (CPU), que ofrecía espacios de direcciones de 32 bits y (inicialmente opcional) soporte para una unidad de administración de memoria (MMU). La MMU manejó las instrucciones necesarias para implementar un sistema de memoria virtual al realizar un seguimiento de las páginas de memoria que estaban utilizando varios programas. Esto ofreció una nueva solución al concepto de puerto, utilizando el mecanismo de copia en escritura proporcionado por el sistema de memoria virtual. En lugar de copiar datos entre programas, todo lo que se tenía que enviar eran los datos necesarios para indicarle a la MMU que proporcionara acceso a la misma memoria. Este sistema implementaría el sistema de comunicaciones entre procesos con un rendimiento mucho mayor.

Este concepto fue retomado en Carnegie-Mellon, que adaptó Aleph para la estación de trabajo PERQ y lo implementó mediante copia en escritura. El puerto fue exitoso, pero el kernel Accent resultante tuvo un uso práctico limitado porque no ejecutaba el software existente. Además, Accent estaba tan estrechamente ligado a PERQ como Aleph lo estaba a Eclipse.

Máquina

El principal cambio entre estos núcleos experimentales y Mach fue la decisión de hacer una versión del núcleo 4.2BSD existente reimplementado en los conceptos de paso de mensajes de Accent. Dicho kernel sería compatible binariamente con el software BSD existente, lo que haría que el sistema fuera inmediatamente útil para el uso diario sin dejar de ser una plataforma experimental útil. Además, el nuevo núcleo se diseñaría desde el principio para soportar múltiples arquitecturas de procesador, incluso permitiendo la construcción de clústeres heterogéneos. Para que el sistema funcione lo más rápido posible, el sistema se implementaría comenzando con el código BSD existente y reimplementándolo poco a poco como programas basados en comunicación entre procesos (basados en IPC). Por lo tanto, Mach comenzaría como un sistema monolítico similar a los sistemas UNIX existentes y evolucionaría más hacia el concepto de micronúcleo con el tiempo.

Mach comenzó en gran parte como un esfuerzo por producir un Accent altamente portátil, basado en UNIX y claramente definido. El resultado es una breve lista de conceptos genéricos:

• un "task" es un objeto que consiste en un conjunto de recursos del sistema que permiten "los hilos" ejecutar
• un "pan" es una sola unidad de ejecución, existe dentro de un contexto de una tarea y comparte los recursos de la tarea
• a "port" es una cola de mensaje protegida para la comunicación entre tareas; tareas propias enviar derechos (permisiones) y recibir derechos a cada puerto.
• Los "mensajes" son colecciones de objetos de datos escritos, sólo pueden ser enviados a puertos, no específicamente tareas o hilos

Mach se desarrolló sobre los conceptos de IPC de Accent, pero hizo que el sistema fuera mucho más parecido a UNIX, incluso capaz de ejecutar programas UNIX con poca o ninguna modificación. Para hacer esto, Mach introdujo el concepto de un puerto, que representa cada extremo de un IPC bidireccional. Los puertos tenían seguridad y derechos como archivos bajo UNIX, lo que permitía aplicarles un modelo de protección muy parecido a UNIX. Además, Mach permitía que cualquier programa manejara privilegios que normalmente se otorgarían solo al sistema operativo, para permitir que los programas del espacio del usuario manejaran cosas como la interacción con el hardware.

Bajo Mach, y como UNIX, el sistema operativo vuelve a ser principalmente una colección de utilidades. Al igual que UNIX, Mach mantiene el concepto de controlador para el manejo del hardware. Por lo tanto, todos los controladores para el hardware actual deben incluirse en el microkernel. Otras arquitecturas basadas en la capa de abstracción de hardware o exokernels podrían sacar los controladores del microkernel.

La principal diferencia con UNIX es que, en lugar de que las utilidades manejen archivos, pueden manejar cualquier "tarea". Se movió más código del sistema operativo fuera del kernel y al espacio del usuario, lo que resultó en un kernel mucho más pequeño y el surgimiento del término microkernel. A diferencia de los sistemas tradicionales, en Mach un proceso, o 'tarea', puede constar de una serie de subprocesos. Si bien esto es común en los sistemas modernos, Mach fue el primer sistema en definir tareas e hilos de esta manera. El trabajo del kernel se redujo de ser esencialmente el sistema operativo a mantener las "utilidades" y programar su acceso al hardware.

La existencia de puertos y el uso de IPC es quizás la diferencia más fundamental entre Mach y los núcleos tradicionales. Bajo UNIX, llamar al núcleo consiste en una operación denominada llamada al sistema o trampa. El programa utiliza una biblioteca para colocar datos en una ubicación bien conocida en la memoria y luego provoca una falla, un tipo de error. Cuando un sistema se inicia por primera vez, su kernel se configura para ser el "controlador" de todas las faltas; por lo tanto, cuando un programa causa una falla, el núcleo toma el control, examina la información que se le pasa y luego lleva a cabo las instrucciones.

Bajo Mach, el sistema IPC se usaba para esta función. Para llamar a la funcionalidad del sistema, un programa le pediría al kernel acceso a un puerto, luego usaría el sistema IPC para enviar mensajes a ese puerto. Aunque enviar un mensaje requiere una llamada al sistema, al igual que una solicitud de funcionalidad del sistema en otros sistemas requiere una llamada al sistema, bajo Mach enviar el mensaje es prácticamente todo lo que hace el kernel; el manejo de la solicitud real dependería de algún otro programa.

La compatibilidad con subprocesos y simultaneidad se benefició del paso de mensajes con mecanismos IPC, ya que las tareas ahora consistían en múltiples subprocesos de código que Mach podía congelar y descongelar durante el manejo de mensajes. Esto permitió que el sistema se distribuyera en múltiples procesadores, ya sea usando memoria compartida directamente como en la mayoría de los mensajes Mach, o agregando código para copiar el mensaje a otro procesador si fuera necesario. En un núcleo tradicional esto es difícil de implementar; el sistema debe asegurarse de que diferentes programas no intenten escribir en la misma memoria desde diferentes procesadores. Sin embargo, los puertos de Mach, su proceso de acceso a la memoria, lo hacen bien definido y fácil de implementar, y se convirtió en un ciudadano de primera clase en ese sistema.

El sistema IPC inicialmente tenía problemas de rendimiento, por lo que se desarrollaron algunas estrategias para minimizar el impacto. Al igual que su predecesor, Accent, Mach utilizaba un único mecanismo de memoria compartida para pasar físicamente el mensaje de un programa a otro. Copiar físicamente el mensaje sería demasiado lento, por lo que Mach confía en la unidad de administración de memoria (MMU) de la máquina para mapear rápidamente los datos de un programa a otro. Solo si los datos se escriben, tendrían que copiarse físicamente, un proceso llamado "copiar al escribir".

El kernel también verificaba la validez de los mensajes, para evitar que los datos erróneos colapsaran uno de los muchos programas que componen el sistema. Los puertos se modelaron deliberadamente sobre los conceptos del sistema de archivos UNIX. Esto permitió al usuario encontrar puertos utilizando los conceptos de navegación del sistema de archivos existentes, así como también asignar derechos y permisos como lo harían en el sistema de archivos.

El desarrollo bajo tal sistema sería más fácil. El código en el que se está trabajando no solo existiría en un programa tradicional que podría construirse con las herramientas existentes, sino que también podría iniciarse, depurarse y eliminarse con las mismas herramientas. Con un monokernel, un error en el código nuevo detendría toda la máquina y requeriría un reinicio, mientras que con Mach esto solo requeriría reiniciar el programa. Además, el usuario podía adaptar el sistema para incluir o excluir las funciones que necesitara. Dado que el sistema operativo era simplemente una colección de programas, podían agregar o eliminar partes simplemente ejecutándolos o eliminándolos como lo harían con cualquier otro programa.

Finalmente, bajo Mach, todas estas características fueron diseñadas deliberadamente para ser extremadamente neutrales en cuanto a plataforma. Para citar un texto en Mach:

A diferencia de UNIX, que se desarrolló sin tener en cuenta el multiprocesamiento, Mach incorpora soporte multiprocesador en todo. Su soporte multiprocesador también es extremadamente flexible, desde sistemas de memoria compartidos a sistemas sin memoria compartida entre procesadores. Mach está diseñado para funcionar en sistemas informáticos que van desde uno a miles de procesadores. Además, Mach es fácilmente portado a muchas arquitecturas informáticas variadas. Un objetivo clave de Mach es ser un sistema distribuido capaz de funcionar en hardware heterogéneo.

Sin embargo, hay una serie de desventajas. Una relativamente mundana es que no está claro cómo encontrar puertos. En UNIX, este problema se resolvió con el tiempo, ya que los programadores acordaron una serie de "bien conocidos" ubicaciones en el sistema de archivos para cumplir diversas funciones. Si bien este mismo enfoque también funcionó para los puertos de Mach, bajo Mach se suponía que el sistema operativo era mucho más fluido, con puertos que aparecían y desaparecían todo el tiempo. Sin algún mecanismo para encontrar puertos y los servicios que representan, se perdería gran parte de esta flexibilidad.

Desarrollo

Mach se alojó inicialmente como código adicional escrito directamente en el kernel 4.2BSD existente, lo que permitió al equipo trabajar en el sistema mucho antes de que estuviera completo. El trabajo comenzó con el ya funcional Accent IPC/port system, y pasó a otras partes clave del sistema operativo, las tareas, los subprocesos y la memoria virtual. A medida que se completaron partes, varias partes del sistema BSD se reescribieron para llamar a Mach, y también se realizó un cambio a 4.3BSD durante este proceso.

Para 1986, el sistema estaba completo hasta el punto de poder funcionar solo en el DEC VAX. Aunque con poco valor práctico, se logró el objetivo de crear un micronúcleo. A esto pronto le siguieron versiones para IBM RT PC y para estaciones de trabajo basadas en Sun Microsystems 68030, lo que demuestra la portabilidad del sistema. Para 1987, la lista incluía las máquinas Encore Multimax y Sequent Balance, probando la capacidad de Mach para ejecutarse en sistemas multiprocesador. Ese año se hizo un lanzamiento público 1, y el lanzamiento 2 siguió al año siguiente.

A lo largo de este tiempo, la promesa de un "verdadero" microkernel aún no se estaba entregando. Estas primeras versiones de Mach incluían la mayoría de 4.3BSD en el núcleo, un sistema conocido como servidor POE, lo que resultó en un núcleo que en realidad era más grande que el UNIX en el que se basaba. La idea, sin embargo, era sacar la capa de UNIX del kernel al espacio del usuario, donde se podía trabajar más fácilmente e incluso reemplazarla por completo. Desafortunadamente, el rendimiento resultó ser un problema importante y se realizaron varios cambios en la arquitectura para resolver este problema. Los problemas de licencias de UNIX difíciles de manejar también estaban afectando a los investigadores, por lo que este esfuerzo inicial para proporcionar un entorno de sistema similar a UNIX sin licencia siguió encontrando uso, hasta bien entrado el desarrollo de Mach.

El Mach 3 resultante se lanzó en 1990 y generó un gran interés. Un pequeño equipo había construido Mach y lo había portado a una serie de plataformas, incluidos los complejos sistemas multiprocesador que estaban causando serios problemas a los núcleos de estilo antiguo. Esto generó un interés considerable en el mercado comercial, donde varias empresas estaban considerando cambiar las plataformas de hardware. Si el sistema existente pudiera ser portado para ejecutarse en Mach, parecería que sería fácil cambiar la plataforma debajo.

Mach recibió un gran impulso en visibilidad cuando la Open Software Foundation (OSF) anunció que alojaría futuras versiones de OSF/1 en Mach 2.5 y que también estaban investigando Mach 3. También se seleccionó Mach 2.5 para el sistema NeXTSTEP y varios proveedores comerciales de multiprocesadores. Mach 3 condujo a una serie de esfuerzos para portar otras partes del sistema operativo para el microkernel, incluido el sistema operativo Workplace de IBM y varios esfuerzos de Apple para crear una versión multiplataforma del Mac OS clásico.

Problemas de rendimiento

Mach originalmente estaba destinado a ser un reemplazo del UNIX monolítico clásico y, por esta razón, contenía muchas ideas similares a UNIX. Por ejemplo, Mach usó un sistema de permisos y seguridad modelado en el sistema de archivos de UNIX. Dado que el kernel tenía privilegios (ejecutándose en kernel-space) sobre otros servidores y software del sistema operativo, era posible que programas maliciosos o que funcionaran mal le enviaran comandos que dañarían el sistema, y por esta razón el núcleo comprobó la validez de todos los mensajes. Además, la mayor parte de la funcionalidad del sistema operativo debía ubicarse en programas de espacio de usuario, por lo que esto significaba que tenía que haber alguna forma en que el kernel otorgara a estos programas privilegios adicionales, por ejemplo, para operar en hardware.

Algunas de las características más esotéricas de Mach también se basaron en este mismo mecanismo IPC. Por ejemplo, Mach pudo admitir máquinas multiprocesador con facilidad. En un kernel tradicional, se necesita llevar a cabo un trabajo extenso para que sea reentrante o interrumpible, ya que los programas que se ejecutan en diferentes procesadores podrían llamar al kernel al mismo tiempo. Bajo Mach, los bits del sistema operativo están aislados en servidores, que pueden ejecutarse, como cualquier otro programa, en cualquier procesador. Aunque en teoría el kernel de Mach también tendría que ser reentrante, en la práctica esto no es un problema porque sus tiempos de respuesta son tan rápidos que simplemente puede esperar y atender las solicitudes a su vez. Mach también incluía un servidor que podía reenviar mensajes no solo entre programas, sino incluso a través de la red, que fue un área de intenso desarrollo a fines de la década de 1980 y principios de la de 1990.

Desafortunadamente, el uso de IPC para casi todas las tareas resultó tener un impacto serio en el rendimiento. Los puntos de referencia en el hardware de 1997 mostraron que las implementaciones de un solo servidor UNIX basadas en Mach 3.0 eran aproximadamente un 50% más lentas que las UNIX nativas.

El estudio de la naturaleza exacta de los problemas de rendimiento reveló una serie de hechos interesantes. Una era que el IPC en sí no era el problema: había cierta sobrecarga asociada con la asignación de memoria necesaria para admitirlo, pero esto agregaba solo una pequeña cantidad de tiempo para realizar una llamada. El resto, el 80% del tiempo invertido, se debió a tareas adicionales que el kernel estaba ejecutando en los mensajes. El principal de estos fue la verificación de los derechos de puerto y la validez del mensaje. En los puntos de referencia en un 486DX-50, una llamada al sistema UNIX estándar tardó un promedio de 21 μs en completarse, mientras que la operación equivalente con Mach IPC promedió 114 μs. Solo 18 μs de esto estaban relacionados con el hardware; el resto era el kernel de Mach ejecutando varias rutinas en el mensaje. Dada una llamada al sistema que no hace nada, un viaje completo de ida y vuelta bajo BSD requeriría alrededor de 40 μs, mientras que en un sistema Mach de espacio de usuario tomaría poco menos de 500 μs.

Cuando Mach se empezó a usar seriamente en las versiones 2.x, el rendimiento era más lento que los sistemas operativos monolíticos tradicionales, quizás hasta un 25 %. Sin embargo, este costo no se consideró particularmente preocupante porque el sistema también ofrecía compatibilidad con múltiples procesadores y fácil portabilidad. Muchos sintieron que este era un costo esperado y aceptable a pagar. Cuando Mach 3 intentó mover la mayor parte del sistema operativo al espacio del usuario, la sobrecarga aumentó aún más: los puntos de referencia entre Mach y Ultrix en un MIPS R3000 mostraron un rendimiento de hasta el 67 % en algunas cargas de trabajo.

Por ejemplo, obtener la hora del sistema implica una llamada IPC al servidor de espacio de usuario que mantiene el reloj del sistema. La persona que llama primero entra en el kernel, provocando un cambio de contexto y un mapeo de memoria. Luego, el kernel verifica que la persona que llama tenga los derechos de acceso requeridos y que el mensaje sea válido. Si es así, hay otro cambio de contexto y asignación de memoria para completar la llamada al servidor de espacio de usuario. Luego, el proceso debe repetirse para devolver los resultados, sumando un total de cuatro cambios de contexto y asignaciones de memoria, más dos verificaciones de mensajes. Esta sobrecarga se combina rápidamente con servicios más complejos, donde a menudo hay rutas de código que pasan a través de muchos servidores.

Esta no fue la única fuente de problemas de rendimiento. Otro se centró en los problemas de tratar de manejar la memoria correctamente cuando la memoria física se agotaba y tenía que ocurrir la paginación. En los sistemas operativos monolíticos tradicionales, los autores tenían experiencia directa con qué partes del kernel llamaron a qué otras, lo que les permitió ajustar su buscapersonas para evitar la paginación del código que estaba a punto de usarse. Con Mach esto no era posible porque el kernel no tenía una idea real de en qué consistía el sistema operativo. En su lugar, tuvieron que usar una solución única para todos, lo que se sumó a los problemas de rendimiento. Mach 3 intentó abordar este problema proporcionando un buscapersonas simple, confiando en buscapersonas en el espacio del usuario para una mejor especialización. Pero esto resultó tener poco efecto. En la práctica, cualquier beneficio que tuviera fue anulado por el costoso IPC necesario para llamarlo.

Otros problemas de rendimiento estaban relacionados con la compatibilidad de Mach con sistemas multiprocesador. Desde mediados de la década de 1980 hasta principios de la de 1990, el rendimiento de las CPU comerciales aumentó a una tasa de alrededor del 60% anual, pero la velocidad de acceso a la memoria creció solo un 7% anual. Esto significó que el costo de acceder a la memoria creció enormemente durante este período, y dado que Mach se basaba en la asignación de memoria entre programas, cualquier "pérdida de caché" hizo que las llamadas IPC fueran lentas.

Soluciones potenciales

La sobrecarga de IPC es un problema importante para los sistemas Mach 3. Sin embargo, el concepto de un sistema operativo multiservidor sigue siendo prometedor, aunque aún requiere algo de investigación. Los desarrolladores deben tener cuidado de aislar el código en módulos que no llamen de un servidor a otro. Por ejemplo, la mayoría del código de red se colocaría en un solo servidor, lo que minimizaría el IPC para las tareas normales de red.

La mayoría de los desarrolladores se quedaron con el concepto POE original de un solo servidor grande que proporciona la funcionalidad del sistema operativo. Para facilitar el desarrollo, permitieron que el servidor del sistema operativo se ejecutara en el espacio del usuario o en el espacio del kernel. Esto les permitió desarrollarse en el espacio del usuario y tener todas las ventajas de la idea original de Mach, y luego mover el servidor depurado al espacio del kernel para obtener un mejor rendimiento. Desde entonces, se han construido varios sistemas operativos utilizando este método, conocido como coubicación, entre ellos Lites, MkLinux, OSF/1 y NeXTSTEP/OPENSTEP/macOS. El microkernel Chorus hizo de esto una característica del sistema básico, lo que permite que los servidores se eleven al espacio del kernel utilizando mecanismos integrados.

Mach 4 intentó abordar estos problemas, esta vez con un conjunto más radical de actualizaciones. En particular, se descubrió que el código del programa normalmente no se podía escribir, por lo que los posibles aciertos debido a la copia en escritura eran raros. Por lo tanto, tenía sentido no mapear la memoria entre programas para IPC, sino migrar el código del programa que se usaba al espacio local del programa. Esto condujo al concepto de "shuttles" y parecía que el rendimiento había mejorado, pero los desarrolladores continuaron con el sistema en un estado semiutilizable. Mach 4 también introdujo primitivos de coubicación integrados, lo que lo convirtió en parte del núcleo mismo.

A mediados de la década de 1990, el trabajo en los sistemas de microkernel estaba prácticamente estancado, aunque el mercado generalmente creía que todos los sistemas operativos modernos estarían basados en microkernel para la década de 1990. Los principales usos generalizados restantes del kernel de Mach son macOS de Apple y su hermano iOS, que se ejecutan sobre un Open Software Foundation Mach Kernel (OSFMK 7.3) híbrido muy modificado llamado "XNU" también se utiliza en OSF/1. En XNU, los sistemas de archivos, las pilas de red y las funciones de gestión de procesos y memoria se implementan en el kernel; y el sistema de archivos, las redes y algunas funciones de gestión de procesos y memoria se invocan desde el modo de usuario a través de llamadas ordinarias al sistema en lugar de pasar mensajes; Los mensajes Mach de XNU se utilizan para la comunicación entre procesos en modo usuario y para algunas solicitudes del código en modo usuario al kernel y del kernel a los servidores en modo usuario.

Microkernels de segunda generación

Un análisis posterior demostró que el problema de rendimiento de IPC no era tan obvio como parecía. Recuerde que un solo lado de una llamada al sistema tomó 20 μs bajo BSD y 114 μs en Mach ejecutándose en el mismo sistema. De los 114, 11 se debieron al cambio de contexto, idéntico a BSD. La MMU utilizó 18 adicionales para mapear el mensaje entre el espacio del usuario y el espacio del kernel. Esto suma solo 29 μs, más que una llamada al sistema tradicional, pero no mucho.

El resto, la mayor parte del problema real, se debió a que el núcleo realizó tareas como verificar el mensaje de los derechos de acceso al puerto. Si bien parece que se trata de un problema de seguridad importante, de hecho, solo tiene sentido en un sistema similar a UNIX. Por ejemplo, un sistema operativo de un solo usuario que ejecuta un teléfono celular o un robot podría no necesitar ninguna de estas características, y este es exactamente el tipo de sistema en el que el sistema operativo de elegir y elegir de Mach sería más valioso. Del mismo modo, Mach causó problemas cuando el sistema operativo había movido la memoria, otra tarea que solo tiene sentido si el sistema tiene más de un espacio de direcciones. DOS y los primeros Mac OS tienen un único espacio de direcciones grande compartido por todos los programas, por lo que en estos sistemas la asignación no proporcionó ningún beneficio.

Estas realizaciones dieron lugar a una serie de micronúcleos de segunda generación, que redujeron aún más la complejidad del sistema y colocaron casi toda la funcionalidad en el espacio del usuario. Por ejemplo, el kernel L4 (versión 2) incluye solo siete llamadas al sistema y usa 12k de memoria, mientras que Mach 3 incluye alrededor de 140 funciones y usa alrededor de 330k de memoria. Las llamadas IPC bajo L4 en un 486DX-50 toman solo 5 μs, más rápido que un syscall UNIX en el mismo sistema y más de 20 veces más rápido que Mach. Por supuesto, esto ignora el hecho de que L4 no maneja permisos o seguridad; pero al dejar esto a los programas de espacio de usuario, pueden seleccionar tanta o tan poca sobrecarga como necesiten.

Las posibles ganancias de rendimiento de L4 se ven atenuadas por el hecho de que las aplicaciones del espacio del usuario a menudo tendrán que proporcionar muchas de las funciones que antes admitía el kernel. Para probar el rendimiento de un extremo a otro, MkLinux en modo coubicado se comparó con un puerto L4 que se ejecuta en el espacio del usuario. L4 agregó entre un 5 % y un 10 % de gastos generales, en comparación con el 29 % de Mach.

Software basado en Mach

La siguiente es una lista de kernels de sistemas operativos derivados de Mach y sistemas operativos con kernels derivados de Mach: