site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi All, Read "Device-Interface Development": This is a bit like trying to build your own TCP on top of UDP. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Jul 5, 2007, at 6:39 AM, Shailesh Parulekar wrote: 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. <http://developer.apple.com/DOCUMENTATION/DeviceDrivers/Conceptual/AccessingH...

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. 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. This email sent to site_archiver@lists.apple.com