On 20 Jan 2004, at 06:00, darwin-kernel-request@lists.apple.com wrote: From: Matt Jaffa <matt@knowligent.com> Subject: Re: sosend, soreceive, soconnect Date: Mon, 19 Jan 2004 22:05:56 -0700 To: Amanda Walker <amanda@alfar.com> Amanda and others: I would love to implement what SimpleUserClient is doing but with my application, instead of the KERNEL socket AF_UNIX implementation, I don't know exactly how to do it. So I have a KEXT that is a socket/Protocol filter. And I insert my code to do all the checking within the send function that is within my filter. How am i supposed to do this, my daemon will keep checking with the KEXT to see if it has work to do? And within my send function i block it with a semaphore??? Until the daemon picks it up, signals then does work and then the daemon goes back to checking for work to do???? And what if the daemon is not running, it won't be polling for work to do, so the stuff that is sitting in semaphore_wait mode will always wait and nothing will work. A number of points here Matt.. As pointed out already you can't use the IOKit user client as your not an IOKit kext, unless you want to do a lot of changing to you overall design. I'd recommend that you use the kern control mechanism for communicating with your kext in this instance. It's more than adequate for small simple control like communications and it quite easy to use. Check out the header /sys/sys_domain.h. You can see it in use somewhere ? in the darwin sources.. I remember finding it once upon a time. You could have your kext either launch the daemon using KUNCExecute or else have it send a kernel event when ever it requires action from your daemon. This will remove all polling from your current design. Lastly, you could create a new thread in your kext to handle the comms from user space. e.g. thread_t mattsCommThread = kernel_thread(kernel_task, comms_handler); In this way, you can block the main thread, have the daemon connect to your kext and give it's instructions etc., and then unblock your main thread. Be sure to put a timer on this block in case your daemon does not respond correctly and you block the main thread indefinitely. Your comms thread will really do very little, except register with the controller, then loop around a block. Any incoming comms will wake your thread, be processed by your write function, as entered in the kern_ctl_reg struct, and then it'll block again, after it has unblocked your main thread of course. Please advise me in this area, I am looking to finish my project quickly. Good Luck, -Ollie. Thanks, Matt _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.