site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jul 13, 2005, at 3:47 PM, Allan Hoeltje wrote: <snip> -josh _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com 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. smime.p7s