site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hello, Thank you, Nick Brandaleone _______________________________________________ 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... This is an open-ended question, instead of code specific. However, let me give a little background. I am working on a primitive anti-virus security (non-BSD) kernel extension. I am therefore touching "kauth" quite a bit. I also want to pass information about files in my kauth scope over to a user-space daemon for logging and processing (ie, kicking off other programs to scan for viruses, etc...). After investigating the numerous methods to open a communication channel between kernel/user boundary (mach messages/RPC, IOKit, BSD calls, SYS V calls, memory mapping, notify, etc...), it seems that the most flexible (and well documented) is using IOKit (IOUserClient, IODataQueue) which maps memory between the two processes, sets up a mach-based notification port, and then allows data to be queued up for transport. I may need other methods if I need to do two way information passing, but for now this seems sufficient. Now for my question. As I did not originally see that I would be putting my code into the IOKit section of the kernel (ie device interface), is there any downside to doing this, besides putting my code at the whim of the IOKit driver life cycle? Also, is there a method I am overlooking for flexible, arbitrary communication across the K/U boundary? It seems that Mach RPC is probably the next most flexible manner, although it is obviously more a standard functional paradigm, instead of one for flexible data passing/communication. I know that there is probably no one right answer to this question, but I am curious what other, more experienced developers, might have to say. This email sent to site_archiver@lists.apple.com