site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jan 9, 2007, at 2:23 PM, Michael Smith wrote: - Greg _______________________________________________ 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... Personally, I would implement a UserClient with two methods; one that blocks waiting for a message from the kernel, the other that ships data in. This avoids blowing a kernel thread on the communication portal (making it easier to have multiple clients) by requiring both threads to be owned by the user process. This does sound like a viable idea. It would still require me to have two threads on the user-land side though (calling these methods), would that be a problem? Also, as I asked in the other email, can you pass a pointer to a user-land allocated buffer as a parameter to a method call for the kernel to use? You don't mention whether the kernel->userspace direction produces arbitrary quantities of data, but using a KC socket you're going to be tempted to ignore the issue of kernel-side buffering/flow control, and may be in for a nasty surprise when the socket buffer fills up and your attempt to enqueue data either blocks or fails. I don't think that should be a problem, there will only be one user- land application talking to the kext and I can implement checks for that. This email sent to site_archiver@lists.apple.com