site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Brian, Cheers, - Dean _______________________________________________ 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... On Jan 8, 2005, at 11:48 PM, Brian Kendall wrote: I'm wondering what methods exist for having a kernel extension send a message of some kind that can be received by an application in user space. I searched the archives, and apparently circa a couple of years ago someone asked a similar question and was directed to the source of an example kext called TCPLogger in the Darwin source, but it doesn't look like it exists anymore. Is there anywhere I can find that source, or forgetting that, how could one send a message from a kext to an application? What type of kext are you developing, or more specifically, what API sets are you already using? There are different approaches for IOKit kexts and BSD kexts, and variants within each of these depending on the details. Life will probably be easier if you stick to interfaces closer to what you are already using. Also, pretty much all kernel->user notification channels require the user-land piece to make the first move; signing up for a notification, getting a mach port and waiting for a message, select, etc...). This is done to avoid having kernel threads transition into a user-level task. Instead, the user-level task supplies a thread that is blocked in the kernel waiting for something to happen (synchronous), or the app establishes an event thread and signs it up for notifications (async). Examples include read()/write(), select, mach ports (which underly IOKit messaging), and even signals – all of which execute in a user-supplied context. This email sent to site_archiver@lists.apple.com