Re: sosend, soreceive, soconnect
Re: sosend, soreceive, soconnect
- Subject: Re: sosend, soreceive, soconnect
- From: Mike Smith <email@hidden>
- Date: Tue, 20 Jan 2004 02:57:11 -0800
On Jan 19, 2004, at 9:29 PM, Justin Walker wrote:
On Monday, January 19, 2004, at 09:05 PM, Matt Jaffa wrote:
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.
You can't use the UserClient interface for your project, since it is
designed for IOKit usage, and yours is not an IOKit kext.
It's relatively trivial to become enough of an IOKit kext to get a node
in the IORegistry, at which point attaching a UserClient is
straightforward as per the documentation.
A UserClient isn't a bad way to go about doing this, but you could use
a sysctl node and achieve similar functionality for much less overhead.
Neither is going to be super-performant, but then this doesn't sound
like a performance-intensive application.
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.
If your user-mode component is not running, the kernel-mode component
should exit.
'Exit' is perhaps not quite the right way to describe it.
You would generally do this:
- Start daemon.
- Daemon loads filter module.
- Daemon waits for filter module to initialise, then calls the sysctl
to get work.
- Loop...
- When an exit request is received, the daemon unloads the filter
module.
Don't start the daemon using KUNC, do it the other way around.
And in fact, the above's not actually good enough; you need a simple
and foolproof wrapper that loads and unloads the module, since a crash
in the daemon will leave the filter module loaded.
Please advise me in this area,
I am looking to finish my project quickly.
You will need to adjust your goals. It doesn't appear that you have
much experience with this kind of development, and this is tricky
code.
Amen. Tuning this will take some time, too.
Look at the Darwin sources to see how to implement a SYSCTL_PROC node.
Make use of the CTL_NOLOCK flag (to prevent you locking out other
sysctl consumers).
You can both return work to the kernel and pull work from it in a
single call. In your daemon, use sysctlnametomib() to look your node
up once and then invoke sysctl() directly against the returned mib to
avoid the lookup overhead on every call that you'd get with
sysctlbyname().
One final question; have you considered using a divert(4) socket?
= Mike
_______________________________________________
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.