In che modo un programma parla esattamente con un driver di periferica?

Dove è coinvolto un sistema operativo, i programmi non parlano con i driver dei dispositivi, almeno non direttamente. I programmi parlano di astrazioni che, a loro insaputa, finiscono per parlare ai driver di dispositivo con uno o più livelli di astrazione.

Salterò le complessità dei sistemi operativi moderni e utilizzerò CP / M , un microcomputer che funziona sistema sviluppato 45 anni fa, ad esempio. CP / M era una torta di livello con tre livelli:

Programma. Il livello superiore è un programma che fa qualcosa di utile (elaborazione di testi, giocando a Space Invaders) facendo calcoli e I / O. Diciamo che a un certo punto il programma vuole visualizzare la lettera "A" che l'utente può vedere. CP / M fornisce un'astrazione nota come console , che è dove dovrebbe essere l'utente che interagisce con il programma. Il modo convenzionale di inviare un personaggio è con alcune istruzioni di assemblaggio:

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

(Se non hai familiarità con loro, i registri possono essere pensati come variabili che vivono nel processore.) Vedremo cosa sono in un minuto i numeri magici 2 e 5 . Il takeaway qui è che tutto il programma sa che c'è una console e c'è un modo per scriverlo. Non sa o si preoccupa di nulla oltre a questo. Questa è la prima di due astrazioni che CP / M utilizza per I / O.

BDOS . L'indirizzo 5 del programma chiamato è il punto di ingresso per il livello successivo, il Sistema operativo disco di base o BDOS . Il BDOS fornisce un'intera serie di funzioni numerate che sono come ordinare per numero dal menu di un ristorante. Dicci che ti piacerebbe l'output della console caricando il C registrato con il numero della funzione ( 2 per l'output della console) e il E si registra con il carattere da inviare. L'output della console è un'operazione molto semplice e il BDOS non deve fare molto con esso se non chiamare il livello successivo.

BIOS. Il BIOS o Sistema di input / output di base è il livello in cui risiede tutto il codice specifico dell'hardware. Nei sistemi moderni, questo sarebbe considerato un insieme di driver di dispositivo. Come il BDOS, il BIOS fornisce chiamate per un set standard di operazioni molto primitive che il BDOS usa per fare il suo business . Una di queste operazioni è chiamata CONOUT , che si occupa di far sì che il personaggio che il programma chiede di scrivere due livelli in alto a qualsiasi hardware lo faccia. (A differenza dei PC, allora le cose non erano omogenee: il sistema di tutti aveva diversi modi per farlo accadere). L'output della console è un semplice pass-through per il BDOS, ma fare qualcosa di più complesso come creare un file su un disco potrebbe richiedere molti Il BIOS chiama per manipolare i media. Di nuovo, poiché il BIOS ha un'interfaccia standard e astratta, il BDOS sa sempre come ottenere ciò che vuole e non gli importa come lo fa il BIOS.

Probabilmente ti starai chiedendo perché ci siano due astrazioni (da programma a BDOS e da BDOS a BIOS) invece di una sola. La risposta è che CP / M e il suo BDOS potrebbero essere forniti in forma binaria ai produttori di computer, scriverebbero un BIOS personalizzato con driver di dispositivo per il loro hardware, collegassero i due insieme e lo spedissero come sistema operativo per i loro sistemi. Questo è stato un grosso problema perché il BDOS era gestito da un'organizzazione e quindi era sempre una quantità nota di programmi utente, rendendo possibile l'esecuzione delle stesse applicazioni su una varietà di hardware molto ampia (per il tempo). Questo è il motivo per cui esistono sistemi operativi e non solo scrivi programmi che manipolano l'hardware direttamente .

Tutto ciò che ho descritto qui si applica anche ai moderni sistemi operativi. Unix, ad esempio, astrae tutto come file. Fornisce ai programmi lo stesso insieme di chiamate di sistema ( open() , write() , close() , ecc.) Per comunicare se si tratta di un'unità disco o di una porta seriale. L'insieme di decisioni e astrazioni è molto più complesso, ma alla fine si riduce a scegliere quale codice del driver del dispositivo deve essere eseguito per eseguire l'operazione.

Ci sono un sacco di diverse possibilità:

• Per i dispositivi di uso comune, il sistema operativo spesso include un'API che i driver implementano e che la libreria standard della tua lingua adatta. Esempi tipici: filesystem, stampanti, rete, strumenti MIDI.
• Per i dispositivi più esotici, il produttore del dispositivo deve fornire i driver e a volte quelli includeranno anche i binding della lingua per le lingue più diffuse. Al minimo ci saranno collegamenti C, e praticamente tutte le lingue hanno un modo per chiamare le librerie C.
• In qualche modo tra questi due casi, i dispositivi semplici possono semplicemente utilizzare una connessione generica come una porta seriale e il produttore pubblica solo il protocollo che è possibile utilizzare tramite il driver generico della porta seriale.