J'ai besoin d'utiliser la fonction de workqueue-like sur Mac OSX (pilote en mode noyau) et je cherche un moyen d'ajouter du travail dans une file d'attente pour être traité par un thread du noyau plus tard. Conceptuellement, c'est la même chose que la fonctionnalité workqueue disponible dans le noyau Linux. Y a-t-il quelque chose de similaire sur le noyau XNU?existe-t-il une fonctionnalité de file d'attente dans le noyau xnu?
Répondre
Je ne pense pas qu'il y ait un équivalent direct en tant que tel, même si j'avoue que je ne connais pas très bien le côté Linux, donc je vais éviter de comparer et de vous parler de macOS/xnu.
I/O Kit IOWorkLoops
Si vous construisez un pilote Kit E/S, et surtout si vous écrivez un gestionnaire d'interruption secondaire, vous allez utiliser IOWorkLoops. Interruptions are abstracted by IOEventSource objects, which schedule secondary interrupt handlers to run on the driver's IOWorkLoop.
Chaque IOWorkLoop
encapsule un thread de noyau et fournit également un mécanisme de sérialisation/verrouillage pour les ressources partagées avec ce thread. Tous les travaux soumis à un workloop soit explicitement via un IOCommandGate
ou l'objet workloop directement, soit à la suite d'un événement IOEventSource
seront sérialisés. Notez que les travaux IOCommandGate
exécuteront de manière synchrone sur le thread appelant, pas le thread de workloop.
Comme toujours avec les internes macOS/OSX, vous voudrez regarder les commentaires du fichier d'en-tête et éventuellement l'implémentation dans la source xnu pour plus de détails. Je trouve personnellement IOWorkLoop
s un peu maladroit pour certaines tâches, mais si vous avez affaire à des périphériques PCI, etc., vous n'avez pas vraiment le choix.
thread_call
Un mécanisme de travail de fond plus léger est le thread_call API. Il est défini dans <kern/thread_call.h>
et prend en charge les fonctions d'exécution sur un thread d'arrière-plan géré par le système d'exploitation, éventuellement après un délai ou avec une priorité spécifique. Ceci est probablement plus proche de ce que vous savez de Linux, a une API assez simple, mais ne convient pas pour les gestionnaires d'interruption secondaires.