Réalisation d’un driver du noyau

Le lecteur aura compris ce qui précède, cette étape du projet est en cours de réalisation. Toutefois, il me semble important d’expliquer les enjeux techniques de ce qui est déjà fait et de ce qui le sera.

L’accès au matériel sous Windows NT ne peut se faire qu’à partir de la couche Kernel du système. Par contre les applications, elles, ne fonctionnent que dans la couche User. Il faut donc définir une interface de communication entre ces deux couches de sorte que les applications puissent accéder aux données du matériel.

Si les couches User et Kernel sont complémentaires pour former le système d’exploitation tel qu’on le connaît, elles sont également totalement hétérogènes de part leur aspect fonctionnel: alors que la première s’attache à réaliser les opérations liées à l’utilisation de l’ordinateur (gestion de l’interface, des fichiers...), la seconde travaille à son fonctionnement interne. C’est par conséquent au niveau du Kernel que l’imposant ouvrage de communication sécurisée et distribuée doit s’exécuter.

Pour créer un exécutable du Kernel NT, le programmeur a à sa disposition le DDK (Driver Development Kit). Cet ensemble de documentation et d’outils constituent le strict nécessaire logiciel. Toutefois, une fois le driver écrit, il faut encore le tester. Pour cela, un deuxième ordinateur relié au premier soit par réseau, soit par liaison série s’impose: il joue le rôle de station de débuggage. Ainsi, et seulement de cette façon, est-il possible d’inspecter les réactions du système vis à vis du programme testé.

Les étapes de réalisation d’un driver NT sont les suivantes:

  1. Conception des interfaces du mode User
  2. Conception des interfaces du mode Kernel
  3. Ecriture du driver de la couche Kernel
  4. Ecriture de la librairie d’accès du mode User
  5. Ecriture d’une application de tests unitaires
  6. Test et debuggage de l’ensemble
  7. Validation du driver
La carte que je devais interfacer est la DAS-1601 de Keithley. La documentation fournie avec est suffisamment complète pour réaliser le driver de toute pièce. Cette année, axé principalement par l’évolution de la version existante du produit, je n’ai réalisé que partiellement les 6 premières étapes du développement; ainsi, la communication entre les deux couches est complète, l’accès aux ressources, par contre, n’est pas terminé.

Ma conception générale divise donc le driver en deux modules distincts:

  1. la librairie dynamique du niveau user (das160x.dll), regroupant les interfaces de la carte d'acquisition.
  2. le fichier système du niveau kernel (das160x.sys), communiquant avec le matériel au travers du HAL .

En ce qui concerne les interfaces de programmations, je renvoie le lecteur aux annexes où il trouvera les références de celles-ci. En effet, je pense plus intéressant de discuter ici de la technique de configuration du driver. J’ai choisi de suivre la méthode désormais standard sous Windows NT, de sauvegarde d’information concernant le système. Elle consiste à utiliser ce que l’on appelle le « Registre du système ». Il s’agit d’une mini-base de données regroupant la configuration de la machine mais aussi les données propres à la personnalisation des utilisateurs. Chaque type d’information y est sauvegardé sous une des clés prédéfinies. Celle qui nous intéresse concerne la configuration système. Mais voyons les possibilités en détail.

La configuration de la carte DAS, effectuée lors de l'installation du driver, est enregistrée au niveau du registre système sous la clé: "das node"\Parameters dans le HKEY_LOCAL_MACHINE

par défaut

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Das160x\Parameters

L'architecture des cartes DAS-160x permet de faire fonctionner jusqu'à deux cartes à la fois. Par conséquent, il est nécessaire de différencier les paramètres des différentes cartes. Ceci est réalisé à l'aide d'une clé supplémentaire \Device%n% où %n% correspond au numéro de la carte configurée: 0 ou 1. Les configurations possibles sont donc:
soit

\Parameters\Device0

soit

\Parameters\Device0
\Parameters\Device1

Pour chacune des cartes, les paramètres reconnus sont (indifféremment sous \Parameters\Device0 ou \Parameters\Device1):

...\BoardType : REG_DWORD

correspond au type de la carte utilisée. Les DAS-160x formant une famille de cartes d'acquisition aux caractéristiques similaires, un driver unique les pilote. Toutefois, afin de prendre en considération les caractéristiques exactes, la valeur BoardType identifie le type exact de la carte:

0 pour la DAS-1601
1 pour la DAS-1602

...\BoardName : REG_SZ

correspond au nom en clair de la carte. Le nom précisé ici est celui qui sera présenté à l'utilisateur final de la carte afin de l'identifier. Le nom proposé par défaut est:

"Keithley DAS-1601" pour la DAS-1601
"Keithley DAS 1602" pour la DAS-1602

...\InterfaceType : REG_DWORD

correspond au type de connecteur du bus sur lequel est branché la carte. Les valeurs reconnues sont celles du type INTERFACE_TYPE du DDK, à savoir:

  1. Internal
  2. Isa
  3. Eisa
  4. MicroChannel
  5. TurboChannel
  6. PCIBus
  7. VMEBus
  8. NuBus
  9. PCMCIABus
  10. CBus
  11. MPIBus
  12. MPSABus

...\BusNumber : REG_DWORD

correspond au numéro du slot utilisé par la carte.

...\IoPortAddress : REG_DWORD

correspond à l'adresse du port hardware de communication de la carte. Sa valeur doit être la même que celle choisie par le positionnement des switches nommés BASE ADDRESS SWITCHES sur la carte . La valeur par défaut est 0x300 soit sur la carte:

...\Interrupt : REG_DWORD

correspond au niveau d'interruption choisi pour la carte. La valeur doit être unique pour le système. Les valeurs possibles sont: 0 (none, disabled), 2, 3, 4, 5, 6 ou 7.

...\DmaChannel : REG_DWORD

correspond au choix effectué au niveau de la carte à l'aide des switches nommés DMA SEL. La valeur doit être unique pour le système. Les seules valeurs autorisées sont: 1 et 3. Par conséquent, si deux cartes sont utilisées, l'une devra être configurée en DMA channel 1, l'autre en DMA channel 3.