Die beste Möglichkeit, von KEXT zu Daemon zu kommunizieren und zu blockieren, bis das Ergebnis vom Daemon zurückgegeben wird

Question

In KEXT lausche ich über Vnode oder Dateibereichs-Listener auf das Schließen der Datei. Für bestimmte (sehr wenige) Dateien muss ich einen Dateipfad an meinen Systemdämon senden, der etwas verarbeitet (dies muss im Daemon passieren) und gibt das Ergebnis zurück an KEXT. Das Schließen der Datei muss blockiert werden, bis ich eine Antwort vom Daemon erhalten habe. Basierend auf dem Ergebnis muss ich eine Operation in engem Call durchführen und den Close Call erfolgreich beenden. Es gibt eine Menge Diskussion über KEXT Kommunikation Thema im Forum. Aber sie sind nicht schlüssig und scheinen sehr alt zu sein (Jahr 2002 herum). Diese Anforderung kann von FtlSendMessage(...) Win32 API behandelt werden. Ich suche Äquivalent, dass auf Mac

Hier ist, was ich sah und möchte mein Verständnis zusammenfassen:

1. Mach Nachricht: Bietet sehr gute Möglichkeit der bidirektionalen Kommunikation Absender mit und antworten Ports mit Mechansim anstehen. Die Mach-Nachrichten-APIs (z. B. mach_msg, mach_port_allocate, bootstrap_look_up) scheinen jedoch keine KPIs zu sein. Die Mach API mach_msg_send_from_kernel kann verwendet werden, aber das allein wird nicht in der bidirektionalen Kommunikation helfen. Ist mein Verständnis richtig?
2. IOUserClient: Dies scheint mehr mit der Kommunikation von Benutzerraum zu KEXT zu tun und dann einige Rückrufe von KEXT zu haben. Ich habe keine Möglichkeit gefunden, die Kommunikation von KEXT zum Daemon zu starten und dann auf das Ergebnis vom Daemon zu warten. Fehle ich etwas?
3. Sockets: Dies könnte die letzte Option sein, da ich den gesamten bidirektionalen Kommunikationskanal von KEXT zu Daemon implementieren müsste.
4. ioct l/sysctl: Ich weiß nicht viel über sie. Von dem, was ich gelesen habe, ist es nicht die empfohlene Option vor allem für die bidirektionale Kommunikation
5. RPC-Mig: Wieder weiß ich nicht viel über sie. Sieht kompliziert aus, was ich gesehen habe. Nicht sicher, ob dies empfohlen wird.
6. KÜNCUserNotification: Dies scheint nur eine Benachrichtigung an den Benutzer von KEXT bereitzustellen. Es erfüllt meine Anforderung nicht.

Unterstützte Plattform ist (ab 10.5). Wenn Sie sich die Anforderung ansehen, kann Ihnen jemand Hinweise zu diesem Thema geben?

Vielen Dank im Voraus.

Answer 1

Das Muster, das ich für diesen Prozess verwendet habe, ist, dass der User-Space-Prozess eine Socket-Verbindung zum KEXT initiiert; Der KEXT erstellt einen neuen Thread, um Nachrichten über diesen Socket zu verarbeiten und den Thread zu speichern. Wenn der KEXT ein Ereignis erkennt, auf das er reagieren muss, aktiviert er den Messaging-Thread und verwendet den vorhandenen Socket, um Daten an den Daemon zu senden. Beim Empfang einer Antwort wird die Kontrolle an den anfordernden Thread zurückgegeben, um zu entscheiden, ob die Operation abgelehnt werden soll.

Ich kenne keine einzelne Ressource, die das gesamte Muster vollständig beschreibt, aber die relevanten KPIs werden in Mac OS X Internals (die alt scheint, aber die KPIs haben sich nicht viel geändert seit es geschrieben wurde) und OS X and iOS Kernel Programming (wo ich ein Tech-Reviewer war).

Answer 2

Wenn Sie die Buchse mit ctl_register() auf der Seite kext gegründet verwenden möchten, dann passen Sie auf: Die Kommunikation von kext den User-Space (via ctl_enqueuedata()) funktioniert OK. Die entgegengesetzte Richtung ist jedoch am 10.5 fehlerhaft.x und 10.6.x.

Nach etwa 70,000 oder 80,000 send() Anrufen mit SOCK_DGRAM in der PF_SYSTEM Domain kompletten Netzstapel brechen mit katastrophalen Folgen für die komplette System (hart ausgeschaltet ist der einzige Ausweg). Dies wurde in 10.7.0 behoben. Ich umgehe Abhilfe, indem ich setsockopt() in unserem Projekt für die Richtung von User Space zu Kext verwenden, da wir nur sehr kleine Daten senden (nur um einige Operationen zu erlauben/zu verbieten).

Answer 3

Für das, was es wert ist, autofs verwendet, was ich nehme an, Sie durch „RPC-Mig“ meine, es ist so nicht zu komplizierte (MIG verwendet wird, um die RPC-Aufrufe zu beschreiben, und der Stub-Code erzeugt es Greift die entsprechenden Aufruf Mach-Nachricht Senden und Empfangen von Code, es gibt spezielle Optionen zum Erzeugen von Kernel-Mode-Stubs.

Es müssen jedoch keine Suchvorgänge durchgeführt werden, da automountd (der Benutzermodus-Daemon, dem die autofs kext Nachrichten sendet) ein "host special port" zugewiesen ist. Die Suche nach einem beliebigen Dienst wäre schwieriger.