Pros/Cons of using IOKit for Kernel/User space communication
Pros/Cons of using IOKit for Kernel/User space communication
- Subject: Pros/Cons of using IOKit for Kernel/User space communication
- From: Nick Brandaleone <email@hidden>
- Date: Thu, 10 Apr 2008 08:53:31 -0400
Hello,
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.
Thank you,
Nick Brandaleone
_______________________________________________
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