Un pilote communique avec le périphérique via le bus informatique ou le sous-système de communication auquel le matériel est connecté. Lorsqu'un programme appelant invoque une routine du pilote, ce dernier envoie des commandes au périphérique (le pilote). Une fois que le périphérique a renvoyé des données au pilote, celui-ci peut invoquer des routines du programme appelant initial.
Les pilotes dépendent du matériel et du système d'exploitation. Ils assurent généralement la gestion des interruptions nécessaire à toute interface matérielle asynchrone dépendante du temps.
l'abstraction matérielle en servant d'intermédiaire entre un périphérique et les applications ou systèmes d'exploitation qui l'utilisent. Les programmeurs peuvent ainsi écrire du code applicatif de haut niveau indépendamment du matériel utilisé par l'utilisateur final.Par exemple, une application de haut niveau permettant d'interagir avec un port série peut se limiter à deux fonctions : l'envoi et la réception de données . À un niveau inférieur, un pilote de périphérique implémentant ces fonctions communique avec le contrôleur de port série installé sur l'ordinateur de l'utilisateur. Les commandes nécessaires pour contrôler un UART 16550 diffèrent considérablement de celles requises pour contrôler un adaptateur USB-série , mais chaque pilote spécifique au matériel abstrait ces détails dans une interface logicielle identique (ou similaire).
Développement
La création d'un pilote de périphérique exige une compréhension approfondie du fonctionnement du matériel et du logiciel pour une fonction donnée de la plateforme . Les pilotes nécessitant un accès bas niveau aux fonctions matérielles pour fonctionner, ils s'exécutent généralement dans un environnement hautement privilégié et peuvent engendrer des dysfonctionnements système en cas d'erreur. À l'inverse, les comportements anormaux de la plupart des logiciels de niveau utilisateur sur les systèmes d'exploitation modernes peuvent être stoppés sans impacter significativement le reste du système. Même les pilotes exécutés en mode utilisateur peuvent provoquer un plantage système si le périphérique est mal programmé . Ces facteurs rendent le diagnostic des problèmes plus difficile et plus risqué.
La tâche de développer des pilotes de périphériques incombe généralement aux ingénieurs logiciels ou informatiques travaillant pour des entreprises de développement de matériel. En effet, en tant qu'employés, ils disposent d'informations plus précises que la plupart des intervenants externes sur la conception du matériel. De plus, il était traditionnellement dans l' intérêt du fabricant de matériel de garantir à ses clients une utilisation optimale de son matériel. Typiquement, la partie du pilote relative à l'abstraction matérielle est écrite par l'éditeur du système d'exploitation, tandis que la partie d'accès physique au périphérique, de plus bas niveau, est implémentée par le fabricant du périphérique. Cependant, ces dernières années, de nombreux pilotes pour périphériques propriétaires, principalement destinés aux systèmes d'exploitation libres et open source , ont été développés par des tiers . Dans ce cas, il est important que le fabricant du matériel fournisse des informations sur le fonctionnement du périphérique. Bien que ces informations puissent être obtenues par rétro-ingénierie , cette opération est beaucoup plus complexe pour le matériel que pour le logiciel.
Windows utilise une combinaison de pilotes et de minipilotes : le pilote de classe/port complet est fourni par le système d’exploitation, tandis que les pilotes de miniclasse/miniport sont développés par les fournisseurs et implémentent un sous-ensemble du pilote complet, spécifique au matériel ou à la fonction. Le modèle miniport est utilisé par les pilotes NDIS , WDM , WDDM , WaveRT , WIA et HID ; chacun d’eux utilise des API spécifiques au périphérique et nécessite toujours que le développeur gère les tâches d’administration du périphérique.
Microsoft a cherché à réduire l'instabilité du système due à des pilotes de périphériques mal conçus en créant un nouveau cadre de développement de pilotes, appelé Windows Driver Frameworks (WDF). Ce cadre inclut le User-Mode Driver Framework (UMDF), qui encourage le développement de certains types de pilotes – principalement ceux qui implémentent un protocole de communication par messages avec leurs périphériques – en tant que pilotes en mode utilisateur. En cas de dysfonctionnement de ces pilotes, l'instabilité du système n'est pas affectée. Le modèle Kernel-Mode Driver Framework (KMDF) permet toujours le développement de pilotes de périphériques en mode noyau, mais vise à fournir des implémentations standardisées des fonctions connues pour causer des problèmes, notamment l'annulation des opérations d'E/S, la gestion de l'alimentation et la prise en charge des périphériques Plug-and-Play.
Apple dispose d'un framework open source pour le développement de pilotes sur macOS , appelé I/O Kit.
Dans les environnements Linux, les programmeurs peuvent créer des pilotes de périphériques soit intégrés au noyau , soit séparément sous forme de modules chargeables , soit encore sous forme de pilotes en mode utilisateur pour certains types de périphériques disposant d'interfaces noyau, comme les périphériques USB. Makedev inclut une liste des périphériques Linux, notamment ttyS (terminal), lp ( port parallèle ), hd (disque), loop et sound (qui comprend mixeur , séquenceur , DSP et audio).
Les fichiers .sys de Microsoft Windows et les fichiers .ko de Linux peuvent contenir des pilotes de périphériques chargeables. L'avantage de ces pilotes est qu'ils ne peuvent être chargés qu'en cas de besoin, puis déchargés, ce qui permet d'économiser la mémoire du noyau.
niveaux de privilège
Selon le système d'exploitation, les pilotes de périphériques peuvent être autorisés à s'exécuter à différents niveaux de privilèges . Le choix du niveau de privilèges des pilotes dépend principalement du type de noyau utilisé par le système d'exploitation. Un système d'exploitation utilisant un noyau monolithique , tel que le noyau Linux , exécutera généralement les pilotes de périphériques avec les mêmes privilèges que tous les autres objets du noyau. En revanche, un système conçu autour d' un micro-noyau , tel que Minix , exécutera les pilotes comme des processus indépendants du noyau, mais qui utilisent ces pilotes pour les fonctions d'entrée/sortie essentielles . Sous Windows NT , un système doté d'un noyau hybride , il est courant que les pilotes de périphériques s'exécutent en mode noyau ou en mode utilisateur .
Le mécanisme le plus courant de segmentation de la mémoire en différents niveaux de privilèges repose sur les anneaux de protection . Sur de nombreux systèmes, notamment ceux équipés de processeurs x86 et ARM , le passage d'un anneau à l'autre entraîne une perte de performance. Ce facteur est pris en compte par les développeurs de systèmes d'exploitation et les ingénieurs logiciels embarqués lors de la création de pilotes pour des périphériques tels que les cartes d'interface réseau , qui privilégient une faible latence. Le principal avantage de l'exécution d'un pilote en mode utilisateur réside dans une stabilité accrue, car un pilote de périphérique en mode utilisateur mal conçu ne peut pas provoquer de plantage système en écrasant la mémoire du noyau.
Les niveaux d'abstraction courants pour les pilotes de périphériques incluent :
- Pour le matériel :
- Interface directe
- Écriture ou lecture d'un registre de contrôle de périphérique
- Utilisation d'une interface de niveau supérieur (par exemple, BIOS vidéo )
- Utilisation d'un autre pilote de périphérique de niveau inférieur (par exemple, les pilotes de système de fichiers utilisant des pilotes de disque)
- Simuler le travail avec du matériel, tout en faisant quelque chose de complètement différent
- Pour les logiciels :
- Autoriser le système d'exploitation à accéder directement aux ressources matérielles
- Implémentation des seules primitives
- Mise en œuvre d'une interface pour les logiciels autres que les pilotes (par exemple TWAIN )
- Implémentation d'un langage, parfois de très haut niveau (par exemple PostScript )
Applications
En raison de la diversité des interagir avec :
- Imprimantes
- Adaptateurs vidéo
- cartes réseau
- cartes son
- chipsets pour PC
- Gestion de l'alimentation et de la batterie
- Bus locaux de tous types, notamment pour la gestion des bus sur les systèmes modernes
- Bus d' E/S à faible bande passante de différents types (pour les périphériques de pointage tels que les souris , les claviers , etc.)
- Dispositifs de stockage informatique tels que les bus de disques durs , de lecteurs CD-ROM et de disquettes ( ATA , SATA , SCSI , SAS )
- Mise en œuvre de la prise en charge de différents systèmes de fichiers
- scanners d'images
- appareils photo numériques
- Tuners de télévision numérique terrestre
- Adaptateurs émetteurs-récepteurs de communication radiofréquence pour réseaux personnels sans fil utilisés pour la communication sans fil à courte portée et à faible débit dans la domotique (par exemple Bluetooth Low Energy (BLE) , Thread , Zigbee et Z-Wave ).
- Adaptateurs IrDA
Le choix et l’installation des pilotes de périphériques appropriés pour le matériel donné constituent donc souvent un élément clé de la configuration d’un système informatique.
Pilotes de périphériques virtuels
Les périphériques virtuels peuvent également fonctionner dans un environnement non virtualisé. Par exemple, une carte réseau virtuelle est utilisée avec un réseau privé virtuel (VPN) , tandis qu'un disque virtuel est utilisé avec iSCSI . Daemon Tools constitue un bon exemple de pilote de périphérique virtuel .
Il existe plusieurs variantes de pilotes de périphériques virtuels, telles que VxDs , VLMs et VDDs.
pilotes open source
- Pilote de périphérique graphique
- Imprimantes : CUPS
- RAID : CCISS (Interface de commande Compaq pour la prise en charge SCSI-3 )
- Scanners : SANE
- Vidéo : Vidix , infrastructure de rendu direct
Descriptions des pilotes de périphériques couramment utilisés sous Solaris :
- fas : Contrôleur SCSI rapide/large
- hme : Ethernet rapide (10/100 Mbit/s)
- FAI : Contrôleurs SCSI différentiels et carte SunSwift
- glm : (Module de liaison Gigabit ) Contrôleurs UltraSCSI
- SCSI : Périphériques d'interface série pour petits ordinateurs (SCSI)
- sf : boucle arbitrée Fibre Channel sociale (FCAL)
- SoC : contrôleurs de baies de stockage SPARC (SSA) et dispositif de contrôle
- social : Contrôleurs optiques série pour FCAL (soc+)
Apis
- Modèle de pilote d'affichage Windows (WDDM) – l'architecture de pilote d'affichage graphique pour Windows Vista et versions ultérieures.
- Modèle audio unifié (UAM)
- Fondation des pilotes Windows (WDF)
- Matériel à composants déclaratifs (DCH) - Pilote de plateforme Windows universelle
- Modèle de pilote Windows (WDM)
- Spécification d'interface de pilote réseau (NDIS) – une API standard pour les pilotes de cartes réseau
- Architecture sonore Linux avancée (ALSA) – l'interface standard des pilotes audio Linux
- Scanner Access Now Easy (SANE) – une interface du domaine public pour le matériel de numérisation d'images raster
- Système de fichiers installable (IFS) – une API de système de fichiers pour IBM OS/2 et Microsoft Windows NT
- Interface de liaison de données ouverte (ODI) – API de carte réseau similaire à NDIS
- Interface de pilote uniforme (UDI) – un projet d'interface de pilote multiplateforme
- Dynax Driver Framework (dxd) – Framework de pilote multiplateforme open source C++ pour KMDF et IOKit
Identifiants
Un périphérique connecté au bus PCI ou USB est identifié par deux identifiants de deux octets chacun. L'identifiant du fournisseur indique le fabricant du périphérique. L'identifiant du périphérique permet d'identifier un périphérique spécifique de ce fabricant/fournisseur.
Un périphérique PCI possède souvent une paire d'identifiants pour la puce principale du périphérique, ainsi qu'une paire d'identifiants de sous-système qui identifie le fournisseur, lequel peut être différent du fabricant de la puce.
Sécurité
Les ordinateurs possèdent souvent de nombreux pilotes de périphériques divers et personnalisés fonctionnant dans le noyau de leur système d'exploitation, qui contiennent souvent divers bogues et vulnérabilités , ce qui en fait une cible pour les exploits . propriétaire et non accessible à l'examen, et où les pilotes disposent souvent de nombreux privilèges.
Un groupe de chercheurs en sécurité considère le manque d'isolation comme l'un des principaux facteurs compromettant la sécurité du noyau [ a publié un cadre d'isolation pour protéger les noyaux des systèmes d'exploitation, principalement le noyau monolithique Linux dont les pilotes reçoivent environ 80 000 commits par an.
Les mécanismes ou politiques fournis par le noyau peuvent être classés selon plusieurs critères, notamment :
- qu'elles soient statiques (appliquées au moment de la compilation ) ou dynamiques (appliquées au moment de l'exécution ) ;
- qu’elles soient préventives ou postérieures à la détection ;
- qu’ils soient basés sur du matériel ou sur le langage ;
- qu’il s’agisse plutôt d’un mécanisme ouvert ou d’une politique contraignante ;
- selon les principes de protection qu’ils satisfont (par exemple, Denning );
- et bien d'autres encore.