¿Cómo se comunica exactamente un programa con un controlador de dispositivo?

Así que estoy confundido sobre cómo exactamente nosotros, como programadores, hablamos con los dispositivos en la computadora. Ahora no estoy hablando de las grandes ideas. Sé que hay controladores de dispositivos que se ubican sobre el hardware para que diferentes programas puedan usar sus funciones.

Pero, en general, ¿quién habla exactamente con los conductores? ¿El programador está escribiendo la aplicación responsable de llamar a una función en el controlador? ¿O el programador llama a una función a través del sistema operativo que luego maneja la llamada al controlador?

Cuando hay un sistema operativo involucrado, los programas no hablan con los controladores de dispositivos, al menos no directamente. Los programas hablan de abstracciones que, sin saberlo, terminan hablando con los controladores de dispositivos a través de una o más capas de abstracción.

Voy a omitir las complejidades de los sistemas operativos modernos y usar CP / M , un sistema operativo de microcomputadora desarrollado hace 45 años, como ejemplo. CP / M fue un pastel de capas con tres capas:

Programa. La capa superior es un programa que hace algo útil (procesamiento de textos, reproducción de Space Invaders) al hacer cálculos y E / S. Digamos que en algún momento el programa quiere mostrar la letra 'A' para que la vea el usuario. CP / M proporciona una abstracción conocida como la consola , que es donde debe buscar el usuario que interactúa con el programa. La forma convencional de enviar un personaje allí es con unas pocas instrucciones de montaje:

LD C,2   ; Load 2 into register C
LD E,65  ; Load the ASCII code for 'A' into register E
CALL 5   ; Call CP/M's routine for getting things done

(Si no está familiarizado con ellos, los registros pueden considerarse como variables que viven en el procesador). Llegaremos a los números mágicos 2y 5trataremos en un minuto. La conclusión aquí es que todo lo que el programa sabe es que hay una consola y hay una manera de escribirle. No sabe ni le importa nada más allá de eso. Esta es la primera de las dos abstracciones que CP / M usa para E / S.

BDOS . La dirección 5que llamó el programa es el punto de entrada para la siguiente capa, el sistema operativo de disco básico o BDOS . El BDOS proporciona toda una serie de funciones numeradas que son como ordenar por número desde el menú de un restaurante. Le dice que desea la salida de la consola cargando el Cregistro con el número de función ( 2para la salida de la consola) y el Eregistro con el carácter que se enviará. La salida de la consola es una operación muy simple, y el BDOS realmente no tiene que hacer mucho más que llamar a la siguiente capa.

BIOS El BIOS, o sistema básico de entrada / salida es la capa donde se encuentra todo el código específico del hardware. En los sistemas modernos, esto se consideraría un conjunto de controladores de dispositivo. Al igual que el BDOS, el BIOS proporciona llamadas para un conjunto estándar de operaciones muy primitivas que el BDOS utiliza para hacer sus negocios. Una de esas operaciones se llamaCONOUT, que se encarga de obtener el personaje que el programa le pidió que escriba dos capas arriba a través del hardware que lo haga. (A diferencia de las PC, las cosas no eran homogéneas en ese entonces. El sistema de todos tenía diferentes formas de hacerlo realidad). La salida de la consola es un simple paso para el BDOS, pero hacer algo más complejo como crear un archivo en un disco puede requerir muchos BIOS llama para manipular los medios. Nuevamente, debido a que el BIOS tiene una interfaz abstracta estándar, el BDOS siempre sabe cómo obtener lo que quiere y no le importa cómo lo hace.

Probablemente se esté preguntando por qué hay dos abstracciones (programa a BDOS y BDOS a BIOS) en lugar de solo una. La respuesta es que CP / M y su BDOS podrían proporcionarse en forma binaria a los fabricantes de computadoras, escribirían un BIOS personalizado con controladores de dispositivo para su hardware, los unirían y los enviarían como el SO para sus sistemas. Esto fue un gran problema porque el BDOS fue mantenido por una organización y, por lo tanto, siempre era una cantidad conocida para los programas de usuario, lo que hacía posible ejecutar las mismas aplicaciones en una gran variedad de hardware (por el momento). Es por eso que existen sistemas operativos y no solo escribimos programas que dividen el hardware directamente .

Todo lo que he descrito aquí también se aplica a los sistemas operativos modernos. Unix, por ejemplo, abstrae todo como archivos. Da a los programas de un mismo conjunto de llamadas al sistema ( open(), write(), close(), etc.) para comunicar si se trata de una unidad de disco o un puerto serie. El conjunto de decisiones y abstracciones es mucho más complejo, pero aún así se reduce a elegir qué código de controlador de dispositivo en la capa inferior debe ejecutarse para que la operación suceda.

Hay muchas posibilidades diferentes:

• Para los dispositivos de uso común, el sistema operativo a menudo incluye una API que los controladores implementan y que la biblioteca estándar de su idioma se adapta. Ejemplos típicos: sistemas de archivos, impresoras, red, instrumentos MIDI.
• Para dispositivos más exóticos, el fabricante del dispositivo tiene que proporcionar controladores y, a veces, estos también incluirán enlaces de idiomas para idiomas populares. Como mínimo habrá enlaces C, y casi todos los lenguajes tienen alguna forma de llamar a las bibliotecas C.
• Entre esos dos casos, los dispositivos simples pueden usar una conexión de uso general como un puerto serie y el fabricante solo publica el protocolo que luego puede usar a través del controlador de puerto serie genérico.