Najlepszy sposób na komunikowanie się z KEXT do Daemona i blokowanie aż do zwrócenia wyniku z Daemona

Question

W KEXT, odsłuchuję plik close przez vnode lub detektor zakresu plików. Dla niektórych (bardzo nielicznych) plików, muszę wysłać ścieżkę do mojego demona systemu, który wykonuje pewne przetwarzanie (to musi się zdarzyć w daemonie) i zwraca wynik z powrotem do KEXT. Zamknięcie pliku musi zostać zablokowane, dopóki nie otrzymam odpowiedzi od demona. Na podstawie wyniku muszę wykonać operację w trybie bliskiego połączenia i pomyślnie zakończyć połączenie. Istnieje wiele dyskusji na temat tematu komunikacji KEXT na forum. Ale nie są one rozstrzygające i wydają się bardzo stare (rok 2002 wokół). To wymaganie może być obsługiwane przez interfejs API Win32 Win32. Szukam odpowiednika że na Mac

Oto co mam spojrzał i chcą podsumować moje rozumienie:

1. Mach wiadomość: Zapewnia bardzo dobry sposób komunikacji dwukierunkowej użyciu nadawcę i odpowiadać porty z kolejkowym mechanizmem. Jednak interfejsy API komunikatów mach (na przykład mach_msg, mach_port_allocate, bootstrap_look_up) nie wydają się być kluczowymi wskaźnikami wydajności. Można użyć interfejsu API Mach mach_msg_send_from_kernel, ale samo to nie pomoże w komunikacji dwukierunkowej. Czy moje zrozumienie jest właściwe?
2. IOUserClient: To wydaje się być bardziej związane z komunikowaniem się z przestrzeni użytkownika do KEXT, a następnie wywołania zwrotnego z KEXT. Nie znalazłem sposobu na zainicjowanie komunikacji z KEXT do daemona, a następnie czekanie na wynik z daemona. Czy czegoś brakuje?
3. Gniazda: To może być ostatnia opcja, ponieważ musiałbym wdrożyć cały dwukierunkowy kanał komunikacji z KEXT do Daemona.
4. ioct l/sysctl: Niewiele o nich wiem. Z tego, co przeczytałem, nie jest to zalecana opcja, szczególnie w przypadku komunikacji dwukierunkowej:
5. RPC-Mig: Ponownie niewiele o nich wiem. Wygląda na skomplikowaną z tego, co widziałem. Nie jestem pewien, czy to jest zalecany sposób.
6. KUNCUserNotification: To wydaje się być po prostu powiadomienie użytkownika z KEXT. Nie spełnia moich wymagań.

Obsługiwana platforma to (10.5). Patrząc na wymagania, czy ktoś może zaproponować i dostarczyć wskazówek na ten temat?

Z góry dziękuję.

Answer 1

Wzorzec użyty w tym procesie polega na zainicjowaniu przez proces przestrzeni użytkownika połączenia z KDE; KEXT tworzy nowy wątek do obsługi wiadomości nad tym gniazdem i przesypia wątek. Kiedy KEXT wykrywa zdarzenie, na które musi zareagować, budzi wątek wiadomości i używa istniejącego gniazda do wysyłania danych do demona. Po otrzymaniu odpowiedzi kontrola jest przekazywana do wątku, który zadał pytanie, aby zdecydować, czy zawetować operację.

Nie znam żadnego zasobu, który opisałby cały ten wzorzec w całości, ale odpowiednie kluczowe wskaźniki efektywności zostały omówione w artykule Mac OS X Internals (który wydaje się stary, ale wskaźniki KPI nie zmieniły się od czasu jego napisania) i OS X and iOS Kernel Programming (na którym byłem recenzentem technologii).

Answer 2

Jeśli chcesz użyć gniazda ustanowionego z ctl_register() po stronie KExt, to uwaga: komunikacja z kext do przestrzeni użytkownika (przez ctl_enqueuedata()) działa OK. Jednak przeciwny kierunek jest błędny na 10.5.x i 10.6.x.

Po około 70.000 lub 80.000 send() połączeń z SOCK_DGRAM w PF_SYSTEM domen kompletnych przerw stosu netto z katastrofalnymi skutkami dla całego systemu (twarde wyłączenie jest jedynym wyjściem). Zostało to naprawione w wersji 10.7.0. Zastanawiam się przy użyciu setsockopt() w naszym projekcie dla kierunku od przestrzeni użytkownika do kekstu, ponieważ wysyłamy bardzo małe dane (tylko po to, aby pozwolić/zabronić jakiejś operacji).

Answer 3

Na co warto, autofs korzysta co sądzę masz na myśli przez „RPC-Mig”, więc nie jest to zbyt skomplikowane (MIG jest używany do opisania wywołania RPC, a kod stub generuje uchwyty wywołanie odpowiedniej Kod wysyłania i odbioru Mach-message, istnieją specjalne opcje do generowania kodów trybu jądra).

Jednak nie trzeba wykonywać żadnych wyszukiwań, ponieważ automountd (demon trybu użytkownika, do którego autofs kext wysyła wiadomości) ma przypisany "specjalny port hosta". Wykonanie wyszukiwania w celu znalezienia dowolnej usługi byłoby trudniejsze.