Re: Sending notifications/events to user land from kext
Re: Sending notifications/events to user land from kext
- Subject: Re: Sending notifications/events to user land from kext
- From: Terry Lambert <email@hidden>
- Date: Thu, 5 Jul 2007 11:25:23 -0700
On Jul 5, 2007, at 6:39 AM, Shailesh Parulekar wrote:
Hi All,
I have developed a kernel extension which needs to communicate
asynchronously with an application (which is also developed by us).
Basically, the kext needs to notify various custom events to the
application and requires to provide little data along with the event
(this data may not exceed say 20 bytes). These events are very much
specific to the kext and the app like:
1. The kext is running out of resources OR
2. The kext is ready and the application can query data. etc.
Read "Device-Interface Development":
<http://developer.apple.com/DOCUMENTATION/DeviceDrivers/Conceptual/AccessingHardware/AH_IOKitLib_API/chapter_5_section_5.html
>
One (real bad) way is that the application invokes IoCtl in an
infinite loop to the device file of my kext and every time a
notification is to be done the kext completes the Ioctl and copies
data to user buffers, but this may also result in lots of race
conditions.
Actually, it won't. The only race would be in how stale your data is,
and as long as you implement an appropriate protocol for the request/
response pattern, you will not have any trouble with this method,
unless the data you want to move is very large.
Any AIO methods would result in same problem. Hence I am looking for
some truly asynchronous way to talk to my application.
Any truly asynchronous method does not have an acknowledgement
mechanism, and therefore cannot make the guarantees you want to make
against race conditions: if you want to use async methods, you need to
implement a finite state automaton, with an ack mechanism, that
doesn't state transition to the next state until the ack propagates,
and has a timeout to resend the ack.
This is a bit like trying to build your own TCP on top of UDP.
You are much better off going with your ioctl(0 method, or using one
of the methods outlined in the "Device-Interface Development"
documentation referenced above.
Another way I felt was to send signal to the application (psignal)
but I will be restricted to a limited set of signals and also I will
not be able to send data with the signals.
You ABSOLUTELY do NOT want to use this approach; signals are
persistent conditions, not events, and there is no guaranteed delivery
of more than a signal outstanding signal at a time. You end up having
to implement polling for conditions after receipt of the signal to get
this right, and most people don't.
kevents too work for standard events (am I right??)
Yes, but you are not going to be able to define your own events, nor
are you going to be able to generate them yourself from a KEXT without
using source code from xnu, and tying yourself to a particular release
of MacOS X; unless you want to have to ship new code each time we
release a software update, DO NOT DO THIS.
Is there a way out for this problem. Does Mac provide some
interface(may be in traditional UNIX ways) to communicate
asynchronously from kernel to user apps?
You want your event source to be able to asynchronously generate
events, but from what you describe in terms of your "race conditions"
being a problem, you don't actually want the event delivery to be
asynchronous. Start with either the referenced documentation or your
ioctl(0 approach, and if you have problems there, come back here and
ask about the specific problem you are having.
-- Terry
_______________________________________________
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