2017-09-21 4 views
1

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

0

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.