Re: darwin-kernel digest, Vol 2 #459 - 10 msgs
Re: darwin-kernel digest, Vol 2 #459 - 10 msgs
- Subject: Re: darwin-kernel digest, Vol 2 #459 - 10 msgs
- From: ollie <email@hidden>
- Date: Tue, 20 Jan 2004 10:27:01 +0000
On 20 Jan 2004, at 06:00, email@hidden wrote:
From: Matt Jaffa <email@hidden>
Subject: Re: sosend, soreceive, soconnect
Date: Mon, 19 Jan 2004 22:05:56 -0700
To: Amanda Walker <email@hidden>
Amanda and others:
I would love to implement what SimpleUserClient is doing but with my
application, instead of the KERNEL socket AF_UNIX implementation, I
don't know exactly how to do it.
So I have a KEXT that is a socket/Protocol filter. And I insert my code
to do all the checking within the send function that is within my
filter.
How am i supposed to do this, my daemon will keep checking with the
KEXT to see if it has work to do? And within my send function i block
it with a semaphore??? Until the daemon picks it up, signals then does
work and then the daemon goes back to checking for work to do????
And what if the daemon is not running, it won't be polling for work to
do, so the stuff that is sitting in semaphore_wait mode will always
wait and nothing will work.
A number of points here Matt..
As pointed out already you can't use the IOKit user client as your not
an IOKit kext, unless you want to do a lot of changing to you overall
design.
I'd recommend that you use the kern control mechanism for communicating
with your kext in this instance. It's more than adequate for small
simple control like communications and it quite easy to use. Check out
the header /sys/sys_domain.h. You can see it in use somewhere ? in the
darwin sources.. I remember finding it once upon a time.
You could have your kext either launch the daemon using KUNCExecute or
else have it send a kernel event when ever it requires action from
your daemon. This will remove all polling from your current design.
Lastly, you could create a new thread in your kext to handle the comms
from user space.
e.g.
thread_t mattsCommThread = kernel_thread(kernel_task, comms_handler);
In this way, you can block the main thread, have the daemon connect to
your kext and give it's instructions etc., and then unblock your main
thread. Be sure to put a timer on this block in case your daemon does
not respond correctly and you block the main thread indefinitely. Your
comms thread will really do very little, except register with the
controller, then loop around a block. Any incoming comms will wake your
thread, be processed by your write function, as entered in the
kern_ctl_reg struct, and then it'll block again, after it has unblocked
your main thread of course.
Please advise me in this area,
I am looking to finish my project quickly.
Good Luck,
-Ollie.
Thanks,
Matt
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.