Si un utilisateur souhaite faire tourner du code en mode kernel (noyau). Il doit alors créer un drivers. Les drivers sont comme des extensions du système d’exploitation, qui tournent avec les droits les plus élevées du système.
En général, les pilotes de périphériques et les périphériques ne créent pas du tout de processus. Un fichier de périphérique correspond généralement à un périphérique matériel physique et est utilisé comme un handle pour qu’un processus utilisateur puisse accéder à ce périphérique.
es routines standard du pilote doivent être implémentées par votre pilote. Les routines de support du pilote sont des routines fournies par le système d’exploitation Windows. Les pilotes n’utilisent pas les routines Microsoft Win32, mais les routines de prise en charge des pilotes décrites dans cette section. Les routines de prise en charge des pilotes présentées dans cette section sont organisées par gestionnaires et bibliothèques en mode noyau.
Routines standard du pilote Voici les routines obligatoires et facultatives que vous devez implémenter dans votre pilote pour répondre aux appels de Windows ou d'autres pilotes. Lorsque ces routines sont appelées, votre code doit répondre à l'appel et renvoyer les données appropriées en temps voulu.
Les routines suivantes sont obligatoires pour tous les pilotes :
DriverEntry
AddDevice
DispatchXxx (routines commençant par "Dispatch" telles que DispatchCreate)
DriverUnload
Les autres routines sont facultatives, mais vous devrez peut-être les implémenter en fonction du type de votre pilote et de son emplacement dans la pile de périphériques.DriverEntry est le point d’entrée de tous les pilotes, comme Main() l’est pour de nombreuses applications en mode utilisateur. Le rôle de DriverEntry est d’initialiser les structures et les ressources du pilote.
L’objet driver agit en tant qu’objet parent pour tous les autres objets de framework que vous pouvez créer dans votre driver, ce qui inclut les objets de périphérique, les files d’attente d’E/S, les temporisateurs, les spinlocks, et plus encore.
EvtDeviceAdd est invoqué par le système lorsqu’il détecte l’arrivée de votre périphérique. Son rôle est d’initialiser les structures et les ressources pour ce périphérique. Dans cet exemple, vous avez simplement imprimé un message « Hello World » pour EvtDeviceAdd, créé l’objet périphérique et retourné. Dans d’autres pilotes que vous écrivez, vous pouvez créer des files d’attente d’E/S pour votre matériel, configurer un espace de stockage de contexte de périphérique pour les informations spécifiques au périphérique, ou effectuer d’autres tâches nécessaires pour préparer votre périphérique.
Un driver est une « collection de rappels » qui, une fois initialisés, attendent que le système les appelle lorsqu’il a besoin de quelque chose. Il peut s’agir d’un événement d’arrivée d’un nouveau périphérique, d’une demande d’E/S d’une application en mode utilisateur, d’un événement de mise hors tension du système, d’une demande d’un autre pilote ou d’un événement de retrait surprise lorsqu’un utilisateur débranche le périphérique de manière inattendue. Heureusement, pour dire « Hello World », il suffisait de se préoccuper de la création des pilotes et des périphériques.
https://www.apriorit.com/qa-blog/464-windows-driver-testing-basics
https://learn.microsoft.com/en-us/skype-sdk/sdn/articles/installing-the-trusted-root-certificate
In general, no. Drivers, (at least partially), don’t have a process context because they are given execution by hardware interrupts that transfer execution from currently running processes.