Re: Unloading a KEXT with Client still connected
Re: Unloading a KEXT with Client still connected
- Subject: Re: Unloading a KEXT with Client still connected
- From: Josh Graessley <email@hidden>
- Date: Wed, 13 Jul 2005 15:56:13 -0700
On Jul 13, 2005, at 3:47 PM, Allan Hoeltje wrote:
<snip>
So, are you all saying that in my _stop() there is a way to see if
a client
is connected and if so merely return KERN_FAILURE to prevent the
KEXT from
unloading? What api is this? There is no ctl_ call available in
kern_control.h to do this ...
Unless I call ctl_deregister first in my _stop() and return
KERN_FAILURE
immediately if I get EBUSY - is that it?
Yes, that is a good solution. If that succeeds, you can unload the
filters. You should note that unloading the filters may not happen
immediately too. When you register your ip filters, you also specify
a function to be notified when the filter has been disconnected
(ipf_detach). You can't let your kext unload until that callback has
been called for all filters you registered.
As long as your kext is still in use by the kernel (has filters or
anything with a callback, even an open socket with an upcall
function), you must not let your kext unload. Doing so will lead to a
kernel panic when the kernel calls in to your unloaded kext.
Users shouldn't be manually unloading your kext. Even if they try,
your _stop function can prevent it by returning the error.
-josh
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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