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: "Shailesh Parulekar" <email@hidden>
- Date: Fri, 06 Jul 2007 06:33:13 +0000
Hi Terry,
Firstly, thanks a ton for your prompt response. Actually you got me a little
wrong. I was looking for an asynchronous method to deliver events(and info)
to the application but in a reliable way. I was not expecting a ACK but was
expecting a reliable asynchronous delivery. In your words, 'was just
expecting a TCP layer itself and not really trying to implement TCP over
UDP.
So looks like I've got the answer.. will most likely go with the IoCtl
approach. Thanks a lot for the link you provided... it will be a good
starting point.
--shailesh
From: Terry Lambert <email@hidden>
To: Shailesh Parulekar <email@hidden>
CC: email@hidden
Subject: Re: Sending notifications/events to user land from kext
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
_________________________________________________________________
http://newlivehotmail.com
_______________________________________________
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