Re: User-space to kernel communication
Re: User-space to kernel communication
- Subject: Re: User-space to kernel communication
- From: Greg <email@hidden>
- Date: Tue, 9 Jan 2007 14:47:38 -0500
On Jan 9, 2007, at 2:23 PM, Michael Smith wrote:
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.
- Greg
_______________________________________________
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