On Thu, 28 Apr 2005, Jim Wintermyre wrote:
In the meantime, what other kernel-to-user notification mechanisms
are available? Can a kext signal() to a userland client? If so,
when the kext's user client gets the client died message, is the
userland client already dead (and not able to be signalled)? Is
there a way to do the "reverse" of
IOConnectMethodStructureIStructureO, to call from the kernel back
into the client? Or do I need to use shared memory? Any other ideas?
To answer this question directly ('tho I'm curious to see what this new
method Godfrey is hinting at is :), I can think of two ways of doing the
opposite to IOConnectXX methods. I looked into this a while ago when I
wanted to tell all my other user clients when one of them died / gave up
primary control, but I ended up doing it another way.
The first is in IOKitLib itself, have a look at
IOServiceAddInterestNotification. It uses the same notification port
system that you use to discover new devices - i.e. you get a run loop
source that you can simply add to your run loop. From the kernel side of
things, you use the IOService::message system to send the message to the
user clients - i.e. just call this->messageClients on yourself.
The other way I can think of is probably what the Interest Notification
thing is doing internally - pass a mach port from your user client to your
kext (or around the other way), then just send it an ipc message from the
kernel when you want to tell it something happened. The app would use
NSMachPort or equivalent and add it to its run loop. Hmm... although I
can't think of too good a way of passing the port in the first place right
now...
Thanks,
Jim
{P^/
btw New Zealand at 6pm? The Sydney Apple stores reckoned they had the
'world premiere' at 6pm - what fibbers :) Hmmm... this makes up a bit for
getting all the movies later here... 'tho the weather's pretty alright too
- 27C today and almost May! (= ~80F according to Unit Converter widget :)
