¿Qué sucederá si los procesos del usuario pudieran interactuar directamente con los dispositivos de E / S sin usar el núcleo?

Las aplicaciones en modo de usuario pueden interactuar con dispositivos de E / S y lo hacen. La E / S en modo de usuario era la norma desde la primera PC en 1982 hasta Windows 2000 .. Las aplicaciones interactuaban con dispositivos de E / S a través de controladores de dispositivos que se ejecutaban en modo de usuario (anillo 3 en x86). Las aplicaciones no se toparon entre sí, las solicitudes fueron serializadas por los controladores. Los problemas eran bastante infrecuentes. Cuando ocurrieron, fue debido a un código de controlador mal escrito que no funcionó correctamente o incluso se bloqueó. En la era Win-95/98, muchos o la mayoría de las fallas del sistema fueron causadas por controladores mal escritos de los fabricantes de hardware, pero la gente los culpó de Windows. Microsoft decidió trasladar los controladores al núcleo para evitar ser culpado por los errores de otros.

Windows basado en NT, comenzando con XP, alentó a los controladores en modo kernel, pero no eliminó los controladores en modo usuario. Todavía se están ejecutando hoy. Un ejemplo de un proceso de usuario que accede directamente a un dispositivo es Olympus Camedia Master Pro 4.0 Photo Suite, fácil de usar. Es un editor de fotos que se descarga directamente de la cámara al tener un controlador de dispositivo USB integrado en el editor. La memoria de la cámara no se parece a una unidad de disco. No está utilizando el sistema de archivos para descargar imágenes, está hablando directamente con la cámara.

Algunos controladores, como ActiveX y Open GL, son principalmente modo de usuario con una pequeña porción ejecutándose en modo kernel. La ventaja de ejecutar en modo de usuario es una mayor estabilidad del sistema porque un controlador errante no tiene acceso a la memoria del núcleo. En el peor de los casos, puede eliminar la aplicación que está sirviendo cuando funciona mal (y posiblemente huérfana de otras aplicaciones que la estaban usando). La desventaja es un rendimiento más lento porque el controlador debe usar las llamadas del sistema para acceder a la memoria y los recursos del kernel. El retraso puede mitigarse mediante una técnica llamada cálculo de referencias , que minimiza las llamadas al sistema al agruparlas y emitirlas cuando el núcleo está inactivo.

Unix y Linux requieren que la mayoría de los controladores se ejecuten en modo kernel, sin embargo, OpenGL se ejecuta en OS X (donde se llama Quartz) y Linux se ejecuta en modo mixto, similar a la forma en que se ejecuta en Windows.

Para más información, ver
General: controlador de dispositivo, modo kernel vs. modo usuario.
Windows: Marco del controlador en modo de usuario (UMDF),
Linux: controladores de dispositivo de espacio de usuario
Microkernel: Microdrivers.

Un moderador para serializar todas las solicitudes del usuario y atenderlo de manera adecuada mediante la asignación eficiente de los recursos. El núcleo es un _moderador_ y _usuario_ es un proceso.

La mayoría de los dispositivos de E / S son recursos escasos (máximo 1 o 2), por lo que se requiere algún tipo de personalidad de administrador para controlarlo, de lo contrario, será inútil.

Considere viajar en autobús, ¿qué sucederá si no hay moderador / conductor para asignar boletos / asientos? Las personas terminarán peleando entre sí y nadie podrá viajar finalmente (al menos en India: P). Los humanos que tienen 6 sentidos necesitan un moderador, ¿por qué no uno para máquinas estúpidas?

Es difícil de lograr y, por lo general, no es una solución de propósito general, pero esta técnica de derivación del núcleo se usa actualmente. Las operaciones privilegiadas todavía se delegan al kernel, pero la E / S de ruta rápida puede ocurrir sin ingresar al kernel. Algunos ejemplos son:

• Asignación de dispositivo PCI en Linux KVM. En Linux KVM, el núcleo es el hipervisor, y los procesos del usuario son máquinas virtuales. La parte del usuario del host KVM (qemu-kvm) usa el kernel del host para hacer cosas privilegiadas, como fijar memoria y programar el IOMMU, reclamar un dispositivo PCI e interceptar interrupciones (si corresponde). El kernel invitado (que es un proceso de usuario de Linux en el host) puede acceder directamente al dispositivo de E / S.
• Verbos RDMA de Linux. Esta API de red de alto rendimiento sustenta gran parte del mundo HPC (supercomputadoras grandes y pequeñas). Nuevamente, el núcleo maneja las operaciones privilegiadas del dispositivo, pero la ruta rápida de E / S puede ser directa desde el proceso del usuario al hardware por medio de E / S mapeadas en memoria y anillos descriptores que se mapean en el espacio de direcciones del proceso.
• Otros usos menos glamorosos de la nueva interfaz VFIO y la antigua interfaz UIO. Cosas en tiempo semi real que quieren manejar el hardware de un proceso de usuario con menos fluctuaciones en los tiempos de respuesta, etc.
• Muchas aplicaciones HFT (comercio de alta frecuencia) usan varios tipos de estas para obtener una latencia más determinista para la ingestión de alimentos en el mercado y la ejecución del comercio / estrategia.

Las siguientes son las razones principales para no permitir que el software en modo de usuario acceda directamente al hardware

Una garantia
B. Gestión de recursos.

Si los procesos en modo de usuario pudieran acceder directamente a los dispositivos de E / S, anularía el mecanismo de seguridad en los sistemas operativos

1) Imagine un proceso de UM que lee / escribe ubicaciones arbitrarias de memoria física. Podría permitir que el software de mensajería unificada omita cualquier medida de seguridad impuesta por el kernel y tome el control de la ejecución del modo kernel.
2) Imagine un proceso de mensajería unificada leyendo / escribiendo directamente en el disco. Esto le permitiría eludir los permisos impuestos por el sistema de archivos.

Desde la perspectiva de la gestión de recursos.
1) El sistema operativo mantiene el estado del hardware. Si permitimos el acceso de hardware a los procesos de mensajería unificada, será difícil sincronizar el acceso a través de diferentes procesos.
2) Una interacción de proceso de modo de usuario con hardware puede provocar una interrupción (por ejemplo, cuando el dispositivo completa la solicitud). Las interrupciones se procesan en modo Kernel. Dado que la interacción no se originó en el modo Kernel, es difícil para Kernel determinar qué proceso la inició y cómo redirigir los resultados de vuelta al proceso de origen.

Este razonamiento solo es aplicable a los sistemas operativos modernos donde se ejecutan múltiples procesos en modo de usuario no confiable en sus propios dominios de protección. Para los sistemas operativos en tiempo real y los sistemas en los que todos los procesos son confiables y su comportamiento está predeterminado, estos motivos no se aplican. De hecho, varios sistemas operativos en tiempo real omiten por completo el concepto de particionamiento UM y KM. Todo, incluido el sistema operativo, se ejecuta en un único espacio de direcciones con el mismo nivel de privilegio.

Tomemos un ejemplo simple:

Dos procesos, P1 y P2.
Un dispositivo de E / S, una grabadora de DVD.

Ahora, como los procesos pueden interactuar directamente con los dispositivos de E / S, el proceso P1 comenzará a grabar su DVD con los archivos de audio que desea que tenga.

Ahora el proceso P2 se da cuenta de que hay un DVD vacío en la unidad. Este proceso P2 pertenece a Windows, que cree que ahora puede escribir datos pendientes desde la última vez en el DVD actual (recuerde el acceso directo a E / S). Ahora ambos procesos comienzan a escribir datos en el mismo DVD, en paralelo (pseudo).

BA dum Tss

Si tiene suerte, cerrará uno de los procesos. Si no lo está, la unidad de DVD está arruinada. Compre otro y espere una mejor arquitectura del sistema.

Respuesta simple:
Creo que es importante que proporcione una interfaz de administración similar a la que lo hará un sistema operativo normal para evitar cualquier comportamiento no deseado del dispositivo.
Hay empresas que manejan toda la ruta de E / S desde un proceso de usuario.
La respuesta a la pregunta es que nada malo le sucederá al dispositivo a menos que lo desee. El sistema operativo avanzado, como Linux, le permite hacer esto.

AFAIK, haces esto todo el tiempo en microcontroladores (ten en cuenta que no procesadores de aplicaciones).

De hecho, hay dispositivos con chip llamados FPGA, donde puede crear su programa como circuitos digitales. Los datos digitales (flujo de 0’s y 1’s) entran como voltajes a través de pines de entrada al chip, son procesados ​​por un circuito digital de FPGA al igual que en su procesador Intel o Mobile y los datos resultantes salen de los pines de salida. Los datos de entrada pueden provenir de la digitalización de una cantidad física como latidos cardíacos, la presión y los datos de salida pueden alimentarse a una pantalla adjunta, luces o controladores, etc. Estos datos de E / S pueden almacenarse en RAM de bloque en el FPGA. Todo esto sucede sin ningún tipo de programa, proceso, kernel, sistema operativo, etc. Si abre su caja de enrutador de Internet, es probable que encuentre un chip FPGA en la placa que procesa total o parcialmente los paquetes de datos.