Vous devez d'abord définir ce qu'est un pilote. Je vais le définir comme un programme ou un sous-programme qui contrôle un appareil (comme votre appareil photo) ou un sous-système (comme un système de fichiers). Qu'il le fasse directement via le programme système ou via des serveurs du noyau ou des processus utilisateur-land ne devrait pas principalement concerner cette question essentiellement sémantique.
Dans certains cas, Linux ne fournit qu'un protocole générique écrit dans un logiciel où le "pilote" réel est une arborescence de périphériques. Il s'agit d'une configuration des paramètres matériels et du logiciel à utiliser qui constitue un pilote.
De manière générale, les interfaces et les protocoles des pilotes sont implémentés à l'aide de modules du noyau qui sont chargés selon les besoins définis par les arborescences de périphériques ou les règles udev. Un module noyau n'est pas au sens strict un processus ou une bibliothèque.
Une bibliothèque n'est qu'un ensemble statique de code qui peut être chargé dans n'importe quel processus donné. Les systèmes d'exploitation modernes chargent ces bibliothèques dans la mémoire partagée. Un processus peut lui-même être lié à n'importe quel nombre de bibliothèques partagées.
Un processus est un programme en cours d'exécution dans lequel le programme système ou le noyau a alloué des ressources telles que la mémoire système et le temps processeur. Les modules du noyau peuvent suivre ou non ce modèle eux-mêmes mais ne sont pas considérés comme des processus de facto sous Linux.
Donc, pour répondre à votre question, un pilote n'a pas besoin d'être un processus, mais il peut l'être. Bien que le code puisse exister dans une bibliothèque, le pilote est toujours chargé en mémoire via un programme, que ce soit le noyau sous la forme de modules du noyau ou de processus utilisateur.
Cela devient plus un argument sémantique lorsque l'on considère ce qu'est réellement la totalité d'un conducteur. Vous pourriez dire qu'un pilote est toujours un programme, mais parfois ce n'est pas comme dans le cas des arborescences de périphériques, il peut également s'agir d'un processus utilisateur, d'un fichier d'arborescence de périphériques, de règles udev et d'un module de noyau où le processus et le module utilisent tous les deux des bibliothèques pour constituer la logique d'un conducteur.