La mejor manera de comunicarse de KEXT a Daemon y bloquear hasta que se devuelva el resultado de Daemon

Question

En KEXT, estoy escuchando el archivo cerrado a través de vnode o el oyente del alcance del archivo. Para ciertos (muy pocos) archivos, debo enviar la ruta del archivo a mi daemon del sistema, lo que hace algo de procesamiento (esto tiene que suceder en daemon) y devuelve el resultado a KEXT. La llamada cercana al archivo debe bloquearse hasta que reciba la respuesta de daemon. De acuerdo con el resultado, necesito alguna operación en la llamada cercana y devolver la llamada cercana exitosamente. Hay mucho debate sobre el tema relacionado con la comunicación KEXT en el foro. Pero no son concluyentes y parece ser muy viejo (año 2002 alrededor). Este requisito puede ser manejado por FtlSendMessage(...) Win32 API. Busco equivalente de que en Mac

Aquí es lo que he mirado y quiere resumir mi entendimiento:

1. mensaje Mach: Proporciona una muy buena forma de comunicación bidireccional utilizando remitente y responder puertos con cola mechansim. Sin embargo, las API de mensajes mach (por ejemplo, mach_msg, mach_port_allocate, bootstrap_look_up) no parecen ser KPI. Se puede usar la API mach mach_msg_send_from_kernel, pero eso solo no ayudará en la comunicación bidireccional. Es mi entendimiento ¿verdad?
2. IOUserClient: Esto parece tener más que ver con la comunicación desde el espacio de usuario a KEXT y luego tener algunas devoluciones de llamadas de KEXT. No encontré una forma de iniciar la comunicación de KEXT a daemon y luego esperar el resultado de daemon. ¿Me estoy perdiendo de algo?
3. Enchufes: Esta podría ser la última opción, ya que tendría que implementar todo el canal de comunicación bidireccional de KEXT a Daemon.
4. ioct l/sysctl: No sé mucho sobre ellos. Por lo que he leído, no es una opción recomendada especialmente para comunicación bidireccional
5. RPC-Mig: De nuevo, no sé mucho sobre ellos. Parece complicado por lo que he visto. No estoy seguro si esta es la manera recomendada.
6. KUNCUserNotification: Parece que se trata de una notificación al usuario de KEXT. No cumple con mis requisitos.

La plataforma compatible es (10.5 en adelante). Entonces, al observar el requisito, ¿alguien puede sugerir y proporcionar algunos consejos sobre este tema?

Gracias de antemano.

Answer 1

El patrón que he usado para ese proceso es hacer que el proceso de espacio de usuario inicie una conexión de socket al KEXT; KEXT crea un nuevo hilo para manejar mensajes sobre ese socket y duerme el hilo. Cuando el KEXT detecta un evento al que debe responder, despierta el hilo de mensajes y utiliza el socket existente para enviar datos al daemon. Al recibir una respuesta, el control pasa de nuevo al hilo solicitante para decidir si vetar la operación.

No sé de cualquier recurso único que va a describir todo ese patrón completo, pero los indicadores clave de rendimiento pertinentes se discuten en Mac OS X Internals (que parece viejo, pero los KPI no han cambiado mucho desde que fue escrito) y OS X and iOS Kernel Programming (en el cual yo era un crítico de tecnología).

Answer 2

Si desea utilizar el zócalo establecido con ctl_register() en el lado KExt, tenga cuidado: la comunicación de kext al espacio de usuario (a través de ctl_enqueuedata()) funciona bien. Sin embargo, la dirección opuesta tiene errores en 10.5.x y 10.6.x.

Después de unos 70.000 o 80.000 send() llamadas con SOCK_DGRAM en los PF_SYSTEM de dominio completos rompe la pila de red con consecuencias desastrosas para el sistema completo (torneado en duro fuera es la única forma de salir). Esto ha sido arreglado en 10.7.0. Me propongo usar setsockopt() en nuestro proyecto para la dirección del espacio de usuario a kext, ya que solo enviamos datos muy pequeños (solo para permitir/deshabilitar alguna operación).

Answer 3

Por lo que vale la pena, autofs utiliza lo que supongo que quiere decir con "RPC-Mig", así que no es demasiado complicado (MIG se utiliza para describir las llamadas RPC y el código auxiliar que genera asas llamando a la adecuada Mensaje de Mach enviando y recibiendo código; hay opciones especiales para generar stubs en modo kernel).

Sin embargo, no es necesario realizar ninguna búsqueda, ya que automountd (el daemon de modo de usuario al que el autofs kext envía mensajes) tiene asignado un "puerto especial de host". Hacer las búsquedas para encontrar un servicio arbitrario sería más difícil.