¿Cómo se compara el kernel de Linux con las arquitecturas de microkernel?

Una vez leí que una ventaja de una arquitectura de microkernel es que puede detener / iniciar servicios esenciales como redes y sistemas de archivos, sin necesidad de reiniciar todo el sistema. Pero teniendo en cuenta que el kernel de Linux hoy en día (¿fue siempre el caso?) Ofrece la opción de usar módulos para lograr el mismo efecto, ¿cuáles son las ventajas (restantes) de un microkernel?

Los microkernels requieren menos código para ejecutarse en el modo más interno y confiable que los kernels monolíticos . Esto tiene muchos aspectos, como:

• Los microkernels permiten que se carguen y descarguen a voluntad características no fundamentales (como controladores para hardware que no está conectado o no está en uso). Esto se puede lograr principalmente en Linux, a través de módulos.
• Los microkernels son más robustos: si un componente que no es del kernel se bloquea, no se llevará todo el sistema. Un sistema de archivos defectuoso o un controlador de dispositivo pueden bloquear un sistema Linux. Linux no tiene otra forma de mitigar estos problemas que no sean las prácticas de codificación y las pruebas.
• Los microkernels tienen una base informática más pequeña y confiable . Por lo tanto, incluso un controlador de dispositivo malicioso o un sistema de archivos no puede tomar el control de todo el sistema (por ejemplo, un controlador de origen dudoso para su último dispositivo USB no podría leer su disco duro).
• Una consecuencia del punto anterior es que los usuarios comunes pueden cargar sus propios componentes que serían componentes del núcleo en un núcleo monolítico.

Las interfaces gráficas de usuario de Unix se proporcionan a través de X window, que es el código de usuario (a excepción de (parte del) controlador del dispositivo de video). Muchos dispositivos modernos permiten a los usuarios comunes cargar controladores de sistema de archivos a través de FUSE . Parte del filtrado de paquetes de red de Linux se puede realizar en el país de usuario. Sin embargo, los controladores de dispositivos, los planificadores, los administradores de memoria y la mayoría de los protocolos de red siguen siendo solo kernel.

Una lectura clásica (si está fechada) sobre Linux y microkernels es el debate Tanenbaum-Torvalds . Veinte años después, se podría decir que Linux se está moviendo muy, muy lentamente, hacia una estructura de microkernel (los módulos cargables aparecieron al principio, FUSE es más reciente), pero aún queda un largo camino por recorrer.

Otra cosa que ha cambiado es la mayor relevancia de la virtualización en computadoras de escritorio y computadoras integradas de alta gama: para algunos propósitos, la distinción relevante no es entre el núcleo y el país de usuario, sino entre el hipervisor y los sistemas operativos invitados.

Un microkernel limita el tiempo que el sistema está en modo kernel, en oposición al espacio de usuario, al mínimo absoluto posible.

Si ocurre un bloqueo en modo kernel, todo el kernel se cae, y eso significa que todo el sistema se cae. Si ocurre un bloqueo en el modo de usuario, solo ese proceso se desactiva. Linux es robusto a este respecto, pero aún es posible que cualquier subsistema del núcleo escriba sobre la memoria de cualquier otro subsistema del núcleo, ya sea a propósito o accidentalmente.

El concepto de microkernel pone muchas cosas que tradicionalmente son el modo kernel, como la red y los controladores de dispositivos, en el espacio de usuario. Dado que el microkernel no es realmente responsable de mucho, eso también significa que puede ser más simple y más confiable. Piense en la forma en que el protocolo IP, al ser simple y estúpido, realmente conduce a redes robustas al empujar la complejidad hasta los bordes y dejar el núcleo delgado y malo.

Debería leer el otro lado del problema:

Computación de alto rendimiento extremo o por qué los microkernels apestan

El sistema de archivos pertenece al núcleo

Solo eche un vistazo a la arquitectura x86: el núcleo monolítico solo usa los anillos 0 y 3. Un desperdicio, de verdad. Pero, de nuevo, puede ser más rápido, debido a una menor conmutación de contexto.

1. El núcleo monolítico es mucho más antiguo que el microkernel . Se usa en Unix, mientras que la idea del microkernel apareció a fines de la década de 1980 .

2. Ejemplos de sistemas operativos que tienen núcleos monolíticos son UNIX, LINUX, mientras que los sistemas operativos que tienen microkernel son QNX, L4, HURD e inicialmente Mach (no MacOS X) que luego se convirtió en núcleo híbrido. Incluso MINIX no es un microkernel puro porque sus controladores de dispositivo se compilan como parte del kernel.

3. Los granos monolíticos son más rápidos que los microkernels . El primer microkernel Mach es 50% más lento que los núcleos monolíticos. Las versiones posteriores como L4 son solo un 2% o 4% más lentas que el núcleo monolítico .

4. Los núcleos monolíticos son generalmente voluminosos, mientras que el microkernel puro tiene que ser de tamaño pequeño , incluso encajar en el caché de primer nivel del procesador (microkernel de primera generación).

5. En los núcleos monolíticos, los controladores de dispositivos residen en el espacio del núcleo, mientras que en los controladores de dispositivos de microkernel residen en el espacio del usuario .

6. Dado que los controladores de dispositivo residen en el espacio del kernel, hace que el kernel monolítico sea menos seguro que el microkernel (una falla en el controlador puede provocar un bloqueo). Los microkernels son más seguros que los núcleos monolíticos, por lo tanto, se usan en muchos dispositivos militares.

7. Los núcleos monolíticos usan señales y zócalos para garantizar IPC, mientras que el enfoque de microkernel utiliza colas de mensajes . La ^primera generación de microkernel implementó IPC de manera deficiente, por lo que fueron lentos en los cambios de contexto.

8. Agregar nuevas funciones a un sistema monolítico significa volver a compilar todo el núcleo, mientras que puede agregar nuevas funciones o parches sin volver a compilar

Windows NT (el núcleo subyacente a los sistemas Windows actuales) comenzó como un diseño de microkernel bastante básico. Debido a problemas de rendimiento, cada vez más del código "userland" migró al "micokernel" ... hoy en día su estructura de microkernel es vestigial.

El caso es que el kernel de Linux es un híbrido de monolítico y microkernel. En una implementación monolítica pura, no hay módulos que se carguen en tiempo de ejecución.

Los términos monolithic kernely microkernelno se pueden comparar seriamente ya que describen diferentes aspectos del diseño del núcleo (estructura versus tamaño).

Un núcleo monolítico típico era el núcleo SunOS-4.x y Linux sigue siendo similar, ya que configura manualmente el contenido del núcleo básico.

El núcleo de Solaris (a partir de 2.1 en 1992) ya no se puede llamar monolítico, ya que todos los controladores se cargan automáticamente a pedido y solo se carga una pequeña parte durante el arranque inicial.

SunOS-4.xy Solaris (SunOS-5.x) y Linux son implementaciones de contexto único. Todo su código se ejecuta en un solo contexto MMU.

Mac OS X se basa en Mach y se ejecuta como una implementación de contexto múltiple con varios procesos separados por contextos MMU. En este concepto, los controladores están en procesos separados y contextos MMU separados.

Muchas personas llaman a Mac OS X un "sistema de microkernel", pero puede ser que el núcleo básico no sea más pequeño que el núcleo básico de Solaris.

Así que parece que sería mejor hablar de single context kernelsfrente multi context kernels.