site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Mar 2, 2008, at 11:30 PM, Greg wrote: Based on this I have two questions: = Mike _______________________________________________ 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... Hi, I'm searching for documentation or examples on how to transfer data from a kernel extension written in C to a user-space program. Currently I am using kernel controls to do this, but I would prefer to do this using memory mapping as I feel it would be more efficient, and I think would also simplify my code. Can you explain why you think it would be more efficient, or that it would simplify your code? I ask because it's possible that it might, but without seeing your reasoning I can't comment on whether it might actually be, and it's common for folks to think that mapping would be cheaper when in fact it's not. I've seen one example that uses IOConnectMapMemory in a user-space C program to connect to an IOKit kernel extension written (obviously) in C++. That kernel extension creates an IODataQueue and uses it as shared memory. 1) Can I convert my C kernel extension (of the Name_start/Name_stop kind) directly to C++ (by simply changing its file-extension) so that I can use the IODataQueue? No; you would need to refactor your extension to some degree to do this. It's possible to be a mostly-C extension but participate in the I/O Kit world, but it takes more than just a file renaming. 2) Since I'm guessing the answer to #1 is probably "no", then are there any examples of how to do something like this in a C-based kernel extension? Or any documentation? I do not want to make my kernel extension an IOKit extension. You have to become an I/O Kit extension to use the IODataQueue. There are other ways to share mapped memory between the kernel and user space however. I'd like to put/copy data into this shared memory, and upon doing so have the user-space program be notified of the new data so that it can be immediately used/copied. Unless your data is large, you'll tend to find that copying it along with the notification (as you are currently doing) will be easier and more efficient than trying to manage a shared memory buffer. Again, it would help to be able to put this in perspective with your current workload. This email sent to site_archiver@lists.apple.com