Re: User-space to kernel communication
Re: User-space to kernel communication
- Subject: Re: User-space to kernel communication
- From: Michael Smith <email@hidden>
- Date: Tue, 9 Jan 2007 11:23:03 -0800
On Jan 9, 2007, at 11:10 AM, Greg wrote:
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!
It has its drawbacks.
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.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden