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


12

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?



1
Un peu des deux, et cela varie selon le système d'exploitation et le type d'appareil.
whatsisname

Réponses:


12

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.


Je n'ai pas vraiment regardé le code CP / M auparavant (c'est un peu avant mon temps ... J'ai utilisé des ordinateurs CP / M mais je n'ai jamais écrit de code pour eux), mais je suis plutôt surpris par l'utilisation d' call 5ici. N'aurait pas rst 8été beaucoup plus efficace (cela sacrifierait 3 octets de mémoire à l'adresse de destination, mais économiser 2 à chaque fois qu'elle est appelée ...)?
Jules

@Jules: CP / M a été développé pour le 8080, qui n'avait qu'un seul mode d'interruption où les dispositifs d'interruption mettraient une instruction à un octet (généralement a RST) sur le bus de données. Je ne peux pas le dire avec certitude, mais il se peut qu'il n'y ait pas assez de fentes pour faire le tour pour couvrir les besoins de tous les appareils, plus le DDT (qui les a utilisés pour que les points d'arrêt se produisent) et en utiliser un pour entrer dans le BDOS .
Blrfl

Ah. Cela a du sens, oui. Mon expérience de développement 8 bits est limitée aux machines qui n'avaient qu'une seule source d'interruption et n'avaient donc pas à se soucier autant de telles choses ... :)
Jules

Question rapide, comment ce processus est-il plus lié au système d'exploitation Windows et au noyau Windows? Ou devrais-je poser une nouvelle question pour cela.
Jason

@ Jason: Wikipedia a une page qui décrit l'architecture et fournit la réponse. Tout ce que Microsoft a produit depuis 1993 utilise cette architecture. C'est à peu près la même chose, juste avec plus de couches dans le gâteau.
Blrfl

0

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.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.