site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On May 28, 2006, at 11:33 AM, Bruce Fancher wrote: This document: 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... <http://developer.apple.com/documentation/Darwin/Conceptual/ KernelProgramming/boundaries/chapter_14_section_1.html> describes a number of mechanisms for communication between the kernel and userland, but is oriented towards calling from userland into the kernel, which is exactly the opposite of what I'm trying to do. Perhaps not. Keep in mind that the kernel is supposed to be passive. It's supposed to only respond to userland requests (and to handle the hardware). This means that it's a but no-no to try to coax the kernel (eg: a kernal thread) to "call out" to userland. The approved way to handle this is to have a userland app call into the kernel (via whatever means you want, but a User Client sounds appropriate) and have that thread block until such time as it has something useful to return to the app. The key here is that you never have kernel threads running code that is not part of the kernel. If having your userland thread block, just create a thread for this purpose. It then feels like the kernel calls out to you when really it's just a thread the app has loaned to the kernel coming back to it. Here's one good example doc I found a while back. It covers these ideas pretty well. <http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ WritingDeviceDriver/MakingHWAccessible/chapter_5_section_3.html> This email sent to site_archiver@lists.apple.com