Re: in what context does NKE operate?
Re: in what context does NKE operate?
- Subject: Re: in what context does NKE operate?
- From: "Quinn \"The Eskimo!\"" <email@hidden>
- Date: Tue, 14 Dec 2010 09:26:01 +0000
On 13 Dec 2010, at 20:33, eveningnick eveningnick wrote:
> In what context (or rather in whose thread) does the callback code
> (functions like sf_bind_func) operate?
In general calls coming from the 'top' of the kernel (for example, some process calls <x-man-page://2/bind> which results in your sf_bind_func function being called) are run on the thread of the caller. This does not, however, guarantee a user context. In-kernel code can call a sockets KPI to talk to the network, and such calls result in your filter function being called on whatever thread that in-kernel code was running on.
In contrast, calls coming from the 'bottom' of the kernel (from the network) are called on some unspecified thread. A classic example of this is your sf_data_in_func function.
> What if i am waiting there for a usermode process to send me some command via kernel_control? What else will freeze, except my function? the whole networking subsystem?
It's generally safe to block in calls from above. The thing you have to watch out for deadlocks. You have to make sure that you don't block the user space process that's servicing your request. You also have to make sure you don't block any process that process relies on. This can get really hairy, for example, if the machine is paging over NFS (-:
It's generally not safe to block in calls from below.
> In what context myNKE_start() and myNKE_stop() are executed?
These are called by an arbitrary thread coming from the top of the kernel. This is typically the thread that actually started the load or unload of your KEXT, but I don't think the exact identity of the thread is considered to be API.
> What if i perform some lengthy operations in there?
That should be fine.
> What about kernel_control's callback functions? If i am, for example,
> establishing a connection with a remote host (which is not a quick
> action), from "EPHandleGetSockOpt", will only usermode process, which
> called "getsockopt", freeze? Or something else will degrade as well?
In generally it should be OK to block inside a EPHandleGetSockOpt function for a kernel control socket that you're responsible for.
> What is the common rule to perform such operations? Creating my own
> thread and waiting for callbacks from it?
The model that I like is to avoid blocking entirely, but instead have threads that want to do stuff come in to the kernel, queue their work, and then leave. You can then use a separate thread that blocks inside the kernel waiting for events (such as completions) to occur.
However, whether this is the right model really depends on your overall architecture.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
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