2009-06-25 6 views
0

J'écris un pilote/module PCIe pour un périphérique personnalisé. Comme l'appareil est enfichable à chaud, il peut disparaître à tout moment.Écrire un pilote PCIe hotplug personnalisé Linux 2.6.x

Voici comment je configurer la pci_driver Structure:

struct pci_driver my_pci_driver = { 
    .name = "my_pci_driver", 
    .id_table = ids, 
    .probe = "my_pci_driver_probe", 
    .remove = "my_pci_driver_remove" 
}; 

Mais je ne sais pas comment gérer correctement l'événement supprimer. Lorsque la fonction .remove est appelée, j'ai plusieurs processus qui ont un handle ouvert avec le pilote et exécutant plusieurs ioctl.

Alors, quelle est la bonne façon de gérer la suppression d'un périphérique? Comment puis-je attendre en toute sécurité que l'exécution d'ioctl soit terminée et puis retirer correctement l'appareil de mon pilote?

Répondre

0

Ceci est une question très large. Vous devez concevoir votre code de manière à prendre en charge la suppression des périphériques. Vous pouvez prendre un exemple de n'importe quel pilote USB/usr/src/linux/drivers/usb/... qui est amovible par nature.

Réaction de réponse:
Non, le sous-système USB n'est pas responsable de la synchronisation dans votre pilote. Il y a beaucoup de façons de synchroniser ref count vous pouvez utiliser une opération de verrouillage ou d'utiliser un spinlock ou ...
Il existe un bon document décrivant les primitives de synchronisation sur Windows, la terminologie est un peu différente, mais les concepts sont les mêmes, donc je recommande.

+0

C'est ce que j'ai fait mais je pense qu'il est géré par la couche USB du noyau, pas par le pilote. Ma première pensée était d'utiliser un compteur de référence sur mon objet géré dans ioctl(). Lorsque le compteur est égal à 0, il n'est pas utilisé par une poignée ouverte et je peux retirer le périphérique en toute sécurité. Mais je n'ai pas trouvé un moyen d'attendre correctement que le compteur de référence devienne 0 (une sorte de sémaphore inversé, quelque chose qui verrouille jusqu'à ce que sa valeur ne soit pas égale à 0). –

0

Parce que le matériel est retiré ne signifie pas que votre pilote est retiré. Vous devez donc savoir si votre matériel est là ou non.

Ensuite, vous devez terminer toutes les transactions en cours. Cela signifie que, quelle que soit l'opération que vous effectuez dans vos opérations de fichiers, il doit à un certain moment se terminer et retourner avec un code d'erreur, que vous pouvez retourner au code utilisateur. Pour les périphériques USB, une fonction le fait pour vous.

Le code d'espace utilisateur est capable de lire/écrire/ioctl après que votre appareil a été retiré. Ces appels système savent que le matériel n'est plus là, ils devraient donc retourner un code d'erreur. Toute application saine quittera ou fermera le descripteur de fichier correspondant.

Donc, refcounting devrait avoir lieu dans la méthode open/release. Quelle que soit la ressource que vous avez allouée, elle peut toujours exister après la suppression de votre appareil.

Questions connexes