Comment un programme parle-t-il exactement à un pilote de périphérique?

Je suis donc confus sur la façon dont nous, les programmeurs, parlons exactement aux périphériques de l'ordinateur. Maintenant, je ne parle pas des grandes idées. Je sais qu'il existe des pilotes de périphériques qui se trouvent au sommet du matériel afin que différents programmes puissent utiliser ces fonctionnalités.

Mais en général, qui parle exactement aux chauffeurs? Le programmeur écrivant l'application est-il responsable de l'appel d'une fonction sur le pilote? Ou le programmeur appelle-t-il une fonction via le système d'exploitation qui gère ensuite l'appel au pilote?

Lorsqu'un système d'exploitation est impliqué, les programmes ne parlent pas aux pilotes de périphérique, du moins pas directement. Les programmes parlent à des abstractions qui, à leur insu, finissent par parler aux pilotes de périphériques au moyen d'une ou plusieurs couches d'abstraction.

Je vais ignorer la complexité des systèmes d'exploitation modernes et utiliser CP / M , un système d'exploitation de micro-ordinateur développé il y a 45 ans, à titre d'exemple. CP / M était un gâteau de couches à trois couches:

Programme. La couche supérieure est un programme qui fait quelque chose d'utile (traitement de texte, lecture des Space Invaders) en effectuant des calculs et des E / S. Disons qu'à un moment donné, le programme souhaite afficher la lettre «A» pour que l'utilisateur puisse la voir. CP / M fournit une abstraction connue sous le nom de console , qui est l'endroit où l'utilisateur qui interagit avec le programme doit chercher. La façon conventionnelle d'envoyer un personnage est avec quelques instructions d'assemblage:

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 vous ne les connaissez pas, les registres peuvent être considérés comme des variables qui vivent dans le processeur.) Nous arriverons à ce que sont les nombres magiques 2et 5tout cela dans une minute. Le point à retenir ici est que tout ce que le programme sait, c'est qu'il y a une console et qu'il existe un moyen d'écrire dessus. Il ne sait rien ni ne se soucie de rien d'autre. Il s'agit de la première des deux abstractions utilisées par CP / M pour les E / S.

BDOS . L'adresse 5appelée par le programme est le point d'entrée de la couche suivante, le système d'exploitation de disque de base ou BDOS . Le BDOS fournit toute une série de fonctions numérotées qui sont comme commander par numéro à partir d'un menu de restaurant. Vous lui dites que vous souhaitez une sortie console en chargeant le Cregistre avec le numéro de fonction ( 2pour la sortie console) et le Eregistre avec le caractère à envoyer. La sortie de la console est une opération très simple, et le BDOS n'a pas vraiment à faire grand-chose d'autre que d'appeler la couche suivante.

BIOS. Le BIOS, ou Basic Input / Output System, est la couche où réside tout le code spécifique au matériel. Dans les systèmes modernes, cela serait considéré comme un ensemble de pilotes de périphériques. Comme le BDOS, le BIOS fournit des appels pour un ensemble standard d'opérations très primitives que le BDOS utilise pour faire ses affaires. L'une de ces opérations s'appelleCONOUT, qui prend en charge le caractère que le programme a demandé d'écrire deux couches au-dessus sur n'importe quel matériel. (Contrairement aux PC, les choses n'étaient pas homogènes à l'époque. Le système de tout le monde avait différentes manières d'y arriver.) La sortie de la console est un simple relais pour le BDOS, mais faire quelque chose de plus complexe comme la création d'un fichier sur un disque peut nécessiter beaucoup Le BIOS appelle à manipuler les médias. Encore une fois, parce que le BIOS possède une interface abstraite standard, le BDOS sait toujours comment obtenir ce qu'il veut et ne se soucie pas de la façon dont le BIOS le fait.

Vous vous demandez probablement pourquoi il y a deux abstractions (programme vers BDOS et BDOS vers BIOS) au lieu d'une seule. La réponse est que CP / M et son BDOS pourraient être fournis sous forme binaire aux fabricants d'ordinateurs, ils écriraient un BIOS personnalisé avec des pilotes de périphérique pour leur matériel, les assembleraient et les expédieraient comme OS pour leurs systèmes. C'était un gros problème car le BDOS était géré par une seule organisation et était donc toujours une quantité connue pour les programmes utilisateur, ce qui permettait d'exécuter les mêmes applications sur une très grande variété (pour le moment) de matériel. C'est pourquoi les systèmes d'exploitation existent et nous n'écrivons pas uniquement des programmes qui déforment directement le matériel .

Tout ce que j'ai décrit ici s'applique également aux systèmes d'exploitation modernes. Unix, par exemple, résume tout sous forme de fichiers. Il donne des programmes le même ensemble d'appels système ( open(), write(), close(), etc.) pour communiquer , que ce soit un disque ou un port série. L'ensemble des décisions et des abstractions est beaucoup plus complexe, mais il se résume finalement à choisir le code de pilote de périphérique à la couche inférieure à exécuter pour que l'opération se produise.

Il existe de nombreuses possibilités:

• Pour les appareils couramment utilisés, le système d'exploitation inclut souvent une API que les pilotes implémentent et que la bibliothèque standard de votre langue adapte. Exemples typiques: systèmes de fichiers, imprimantes, réseau, instruments MIDI.
• Pour les appareils plus exotiques, le fabricant de l'appareil doit fournir des pilotes et parfois ceux-ci incluront également des liaisons de langue pour les langues populaires. Au minimum, il y aura des liaisons C, et à peu près tous les langages ont un moyen d'appeler les bibliothèques C.
• Entre ces deux cas, les appareils simples peuvent simplement utiliser une connexion à usage général comme un port série et le fabricant ne publie que le protocole que vous pouvez ensuite utiliser via le pilote de port série générique.