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:10:22 -0500
Wow, thank you all for your replies, they have been very
illuminating. I'm not sure what the proper protocol is for replying
to multiple people but instead of sending several emails I think I'll
try to make a gestalt out of them (I've always wanted to use that
word!).
On Jan 9, 2007, at 11:17 AM, Kevin Elliott wrote:
You haven't mentioned a lot of detail about what your doing (how
fast the data needs to be moved, how often, etc.), but setProperty
is also an option for passing data into the kernel. It's by far
the easiest to implement and if you don't need high performance and
you aren't moving lots of data it's a reasonable option.
You're right I should have given more information. I need to be able
to send data from the user-space program to the kext and it needs to
store this data in memory (cumulatively). The transfer rate of data
into the kernel will likely be minimal on resources, so speed is not
an issue there, however communication in the other direction might be
more intensive. I need the kernel to asynchronously tell the user-
space program when certain events happen in a notification-type
scheme. So for this I will have to somehow manage multiple threads
most likely.
Also, I'm not writing a hardware driver so I'm not bound to using the
IOKit which is why I'm kind of overwhelmed with all of these
implementation possibilities (methods for sending data... methods for
communication... etc)
On Jan 9, 2007, at 11:32 AM, Quinn wrote:
2. You can pack the data into a buffer and pass that in via one of
the "IOConnectMethod*StructureI*" methods. In this case, you just
pass in a pointer to a buffer and its length. Again, this can vary
from request to request.
Are you saying that I could allocate a buffer in user-space and pass
a pointer to that buffer to the kernel? I thought that there were
memory zone restrictions on this type of stuff. This would be very
convenient if it was true as I could simply copy that data out of the
buffer to store it in my kext.
The considerations I usually apply are:
o If you're already knee deep in BSD KPI, there's a general
preference for BSD-based mechanism (sysctl or sockets).
o If you're already knee deep in I/O Kit, there's a general
preference for IOUserClient.
o sysctl is /very/ simple.
o sysctl has a command line tool you can use for basic testing.
That's very convenient. For example, look at my KauthORama sample.
<http://developer.apple.com/samplecode/KauthORama/index.html>
o sysctl has no notification mechanism. If the client needs to
wake up when the value changes, sysctl is inappropriate. Both
sockets and IOUserClient let you notify a user process when things
change.
o If you need low latency or high bandwidth, IOUserClient is
probably your best bet. It has low latency because it's based on
Mach messaging (this is especially true prior to 10.4, where BSD
stuff can get stuck behind the kernel funnel). It supports high
bandwidth because you can pass large blocks out of band (that is,
by memory mapping).
Yes actually I've been going through your KauthORama example, thank
you for writing it! I'm currently just exploring my options so I'm
not knee deep in anything yet (other than various PDFs :-p).
So far it seems that the kern control stuff is what I'm looking for
as it seems like I would be able to just use it for anything I could
possible want (except extremely low latency, high bandwidth stuff),
including notifications. Here is my idea for how my app will work, I
would greatly appreciate any input on it!
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!
- 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