site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jan 9, 2007, at 11:10 AM, Greg wrote: It has its drawbacks. = 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... Both the kernel and the user-space app will each have at least two threads (using the pthreads interface, which the kernel seems to support) in them for communication with each other. Each thread in the kernel will be responsible for communicating with its corresponding thread in the user-space app over kernel control sockets (so one socket is for user->kernel communication, and the other for the reverse). This way I can supply the kext with data and listen for notifications at the same time. By using one communication method for supplying data and doing notifications I hope to simplify everything and make it easier to maintain, perhaps as just a simple C-based kext. Does this sound OK? Again, thank you all for your advice! 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. 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. You also haven't talked about what your kext is actually doing, so again it's hard to know which mechanisms would fit most closely. This email sent to site_archiver@lists.apple.com