Meilleure façon de communiquer de KEXT à Daemon et de bloquer jusqu'à ce que le résultat soit retourné par Daemon

Question

Dans KEXT, j'écoute la fermeture de fichier via vnode ou l'écouteur d'étendue de fichier. Pour certains (très peu) fichiers, je dois envoyer un chemin de fichier à mon démon système qui effectue un traitement (cela doit se produire dans le démon) et renvoie le résultat à KEXT. L'appel de fermeture de fichier doit être bloqué jusqu'à ce que j'obtienne une réponse du démon. Basé sur le résultat, j'ai besoin de certaines opérations en appel rapproché et retour ferme l'appel avec succès. Il y a beaucoup de discussions sur le sujet lié à la communication de KEXT sur le forum. Mais ils ne sont pas concluants et semblent être très vieux (année 2002 autour). Cette exigence peut être gérée par FtlSendMessage(...) API Win32. Je cherche l'équivalent de ce Mac

Voici ce que je l'ai regardé et que vous voulez résumer ma compréhension:

1. Mach un message: Constitue très bon moyen de communication bidirectionnelle utilisant l'expéditeur et de réponse ports avec un mécanisme de file d'attente. Cependant, les API de message mach (par exemple mach_msg, mach_port_allocate, bootstrap_look_up) ne semblent pas être des KPI. L'API mach mach_msg_send_from_kernel peut être utilisée, mais cela ne suffit pas dans la communication bidirectionnelle. Est-ce que je comprends bien?
2. IOUserClient: Cela semble être plus à faire avec la communication de l'espace utilisateur vers KEXT et ensuite avoir quelques rappels de KEXT. Je n'ai pas trouvé un moyen d'initier la communication de KEXT vers le démon, puis d'attendre le résultat du démon. Est-ce que je manque quelque chose?
3. Sockets: Cela pourrait être la dernière option puisque je devrais implémenter le canal de communication bidirectionnel entier de KEXT à Daemon.
4. ioct l/sysctl: Je n'en sais pas beaucoup à leur sujet. De ce que j'ai lu, son option non recommandée, en particulier pour la communication bidirectionnelle
5. RPC-Mig: Encore une fois je ne sais pas beaucoup à leur sujet. Regarde compliqué de ce que j'ai vu. Je ne sais pas si c'est recommandé.
6. KUNCUserNotification: Cela semble juste fournir une notification à l'utilisateur de KEXT. Cela ne répond pas à mes exigences.

La plate-forme prise en charge est (à partir de 10,5). Donc, en regardant l'exigence, quelqu'un peut-il suggérer et donner quelques indications sur ce sujet?

Merci d'avance.

Answer 1

Le modèle que j'ai utilisé pour ce processus est d'avoir le processus d'espace utilisateur initier une connexion socket à la KEXT; le KEXT crée un nouveau thread pour gérer les messages sur ce socket et dort le thread. Lorsque le KEXT détecte un événement auquel il doit répondre, il réveille le thread de messagerie et utilise le socket existant pour envoyer des données au démon. À la réception d'une réponse, le contrôle est renvoyé au thread demandeur pour décider s'il doit mettre son veto à l'opération.

Je ne connais aucune ressource unique qui décrira ce modèle tout complètement, mais les indicateurs de performance clés sont analysés plus loin dans Mac OS X Internals (ce qui semble vieux, mais les indicateurs de performance clés ont pas beaucoup changé depuis qu'il a été écrit) et OS X and iOS Kernel Programming (que j'étais un critique technique sur).

Answer 2

Si vous souhaitez utiliser la socket établie avec ctl_register() du côté KExt, alors attention: La communication de kext vers l'espace utilisateur (via ctl_enqueuedata()) fonctionne bien. Cependant la direction opposée est buggée sur 10.5.x et 10.6.x.

Après environ 70,000 ou 80,000 send() appels avec SOCK_DGRAM dans les sauts de pile net complet de domaine PF_SYSTEM avec des conséquences désastreuses pour le système complet (tournage dur est hors la seule sortie). Cela a été corrigé dans 10.7.0. Je contourne en utilisant setsockopt() dans notre projet pour la direction de l'espace utilisateur à kext car nous n'envoyons que de très petites données (juste pour permettre/interdire certaines opérations).

Answer 3

Pour ce que ça vaut, autofs utilise ce que je suppose que vous entendez par « RPC-Mig », il est donc pas trop compliqué (MIG est utilisé pour décrire les appels RPC, et le code stub il génère des poignées appelant le approprié Mach-message envoi et réception de code, il existe des options spéciales pour générer des stubs en mode noyau).

Cependant, il n'a pas besoin d'effectuer de recherches, car automountd (le démon en mode utilisateur auquel autofs kext envoie des messages) a un "port spécial hôte" qui lui est assigné. Faire les recherches pour trouver un service arbitraire serait plus difficile.