en kernel y espacio de usuario

Question

Ahora sé que se debe evitar el desarrollo de una aplicación que se meta en el kernel, es difícil de depurar, complejo, etc. con eso fuera de la mesa ¿Cuáles son algunas de las ventajas de mover una aplicación? espacio de usuario para el kernel? después de todo, si no hubiera lados positivos, nunca se haría ... ¿qué son algunos?

Answer 1

Algunos posibles ventajas:

sistema

• pide podría ser más rápidos (es decir latencias más bajas), como la CPU no tiene que cambiar del modo de aplicación en modo de núcleo. (Esto no es necesariamente cierto, ya que la CPU puede hacer una distinción más fina que simplemente "espacio de usuario" y "espacio del núcleo". Las CPU Intel x86 por ejemplo tienen un modelo de anillo que abarca 4 niveles de privilegios distintos). ¹⁾

• puede obtener acceso directo al hardware del sistema a través de la memoria y puertos de E/S.

• que podría ser capaz de suprimir la conmutación de tareas, si necesita hacer algo sin ser interrumpido

• que podría ser capaz de mecanismos de seguridad eludir forzadas por el sistema operativo (por ejemplo, leer/modificar memoria de otros procesos). (Malware podría tomar ventaja de esto si se instala como un controlador de dispositivo de modo de núcleo.)

(Y, por supuesto, como saben, hay muchas muchas desventajas y riesgos de seguridad. La distinción entre el espacio de aplicaciones y el espacio del núcleo está ahí por buenas razones.)

---

¹⁾ Véase, por ejemplo el artículo Making system calls from kernel space from Linux mag:

Por ejemplo, un servidor web de alto rendimiento podría residir en el núcleo para un mayor rendimiento y menor latencia. Sin embargo, también existe un compromiso de seguridad [...]

Answer 2

Tiene la posibilidad de que un pequeño error en su programa garabatee toda la memoria y corrompa todo el sistema y todos sus procesos y funciones. Si tiene suerte, el sistema se bloqueará.

Answer 3

Algunas de las razones por las que me vienen a la mente en la búsqueda de opciones, es decir, el modo de núcleo vs modo de usuario:

1) Cuando el procesamiento dedicado es requerido y queremos utilizar las utilidades integradas en el sistema operativo. Ejemplo: si tuviéramos que diseñar un servidor IO. Aquí las latencias son de 1 a 5 ms. Uno no puede esperar los cambios de contexto debido a las compensaciones del modo kernel - usuario. Pero si uno tiene que confiar en el marco de IP de TCP dado por kernel. Tiene que implementarse en modo Kernel vinculando estrechamente la infraestructura de red/TCP/IP y su marco de transporte previsto.

2) Cuando desee poseer completamente el marco de programación.Si bien esto está disponible de forma intuitiva utilizando varias llamadas al sistema y pthread frameworks. Sin embargo, si su producto/subprocesos posee completamente el procesador, entonces hay casos de interbloqueos o bloqueos en vivo de los que puede querer recuperar. En tales situaciones, necesitaría un marco que tenga en cuenta el tiempo que le lleva cada hilo. Esto no se puede hacer desde el usuario lan y, por lo tanto, se requiere soporte del kernel scheduler/schedule subsystem.

3) Cuando desee sobrecargar el acceso a la memoria, nuevamente en entornos donde los recursos están dedicados a una operación en particular. Tiene sentido superponer la memoria física/memoria del kernel para hilos virtuales.

4) Cuando desee virtualizar el acceso al disco para agregar redundancia o mejorar el rendimiento de lectura/escritura.

Podría haber muchas más razones, pero la causa raíz central:

1) Cada vez que se desea reducir capas para obtener un rendimiento que mueve al núcleo. Desde kernel se agrega el marco de virtualización para compartir los recursos (cpu, ram, network, disk).

2) Cuando quiera usar la infraestructura del kernel para usar, es difícil transportarla al usuario lan (Tcp/ip o shceduler).