site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com In the meantime, there are some less-than-ideal workarounds: o As Shaun mentioned, there's KUNC. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ 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... At 10:53 -0700 16/10/07, Eric Long wrote: What's the secret to making this work? It's not what you're missing, it's what the system is missing (-: Both I/O Kit and launchd are strongly oriented towards launch-on-demand semantics. What's missing, however, is a connection between the two. For example, you could imagine a world where your daemon's launchd property list file contains an I/O Kit matching dictionary, and launchd launches it whenever a matching I/O Kit service exists. Alas, implementing this is tricky, because it would introduce a layering violation between launchd and I/O Kit. We're hoping to address this <rdar://problem/4551362>, but you won't see it for a while (you definitely won't see it on 26 Oct :-). o Another option is for your launchd property list to specify some on-demand criteria that your KEXT satisfies. For example, your launchd property list could register a UNIX domain socket with a well known path. When your KEXT comes up, it connects to that socket, thereby triggering the launch of your daemon. This email sent to site_archiver@lists.apple.com