Re: Communicating from a KEXT to a userland process
Re: Communicating from a KEXT to a userland process
- Subject: Re: Communicating from a KEXT to a userland process
- From: Michael Cashwell <email@hidden>
- Date: Sun, 28 May 2006 12:10:10 -0400
On May 28, 2006, at 11:33 AM, Bruce Fancher wrote:
This document:
<http://developer.apple.com/documentation/Darwin/Conceptual/
KernelProgramming/boundaries/chapter_14_section_1.html>
describes a number of mechanisms for communication between the
kernel and userland, but is oriented towards calling from userland
into the kernel, which is exactly the opposite of what I'm trying
to do.
Perhaps not. Keep in mind that the kernel is supposed to be passive.
It's supposed to only respond to userland requests (and to handle the
hardware).
This means that it's a but no-no to try to coax the kernel (eg: a
kernal thread) to "call out" to userland. The approved way to handle
this is to have a userland app call into the kernel (via whatever
means you want, but a User Client sounds appropriate) and have that
thread block until such time as it has something useful to return to
the app.
The key here is that you never have kernel threads running code that
is not part of the kernel.
If having your userland thread block, just create a thread for this
purpose. It then feels like the kernel calls out to you when really
it's just a thread the app has loaned to the kernel coming back to it.
Here's one good example doc I found a while back. It covers these
ideas pretty well.
<http://developer.apple.com/documentation/DeviceDrivers/Conceptual/
WritingDeviceDriver/MakingHWAccessible/chapter_5_section_3.html>
Good luck!
-Mike
_______________________________________________
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