Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: darwin-kernel digest, Vol 2 #459 - 10 msgs

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.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.