site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Aug 5, 2007, at 10:07 PM, Jim Clause wrote: You may not mean this literally, but just in case... By doing this using a blocking user thread this problem is avoided. Good luck! -Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... ... one question that's never been definitively answered is how the kernel can block and then call out to a user level application. The kernel does not "call out" to user space. If you think of the issue this way you are likely to make some poor design choices and have a rough time of it. The correct approach is to have a thread belonging to your background userland app call into your KEXT and block there waiting for something to do. Then, when some other event requires the utility app to do something it can (after arranging for some state or data to be passed to it) unblock that blocked thread. When it's done, it can call into the KEXT and block again. The key difference is thread ownership. If a kernel thread were to execute userland code and that code were to fault it would be very hard to kill the process and clean up the thread without causing a kernel panic. This email sent to site_archiver@lists.apple.com