Re: Determine a process that "owns" the socket_t
Re: Determine a process that "owns" the socket_t
- Subject: Re: Determine a process that "owns" the socket_t
- From: Ken Hornstein <email@hidden>
- Date: Sun, 22 May 2011 20:01:22 -0400
>The closest thing i came up with - is to somehow "ask" the process if it is
>"mine", right in "filter_attached_to_socket" NKE's callback.
> I am searching for the way to 'ask' it, it should be some kind of IPC, but
>i am not sure which one. The only thing i was using for kernel-userland
>communication were Control Sockets, but the conversation for these is
>initiated by an application not the kernel extension (while i need a driver
>to ask the application, not vice versa, - of course with all error checking
>and "app not responding/not loaded" correct processing). I am not even sure
>if that is possible to do at all.
The way I've seen this done (using other mechanisms) is to have your
userspace code have a thread that makes a call into the kernel and the
kernel call just blocks. When the kernel wants to ask the userspace code
to do something, it does that by having the blocked userspace call complete.
Seems like that could work here.
The only other option ... well, I'm not sure you can easily do it yourself,
but look at bsd/nfs/nfs_gss.c, specifically nfs_gss_clnt_gssd_upcall().
I would caution you that I'm not sure that you can make use of that yourself,
but it's at least worth looking at.
--Ken
_______________________________________________
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