Re: Proper termination of an IOKit driver
Re: Proper termination of an IOKit driver
- Subject: Re: Proper termination of an IOKit driver
- From: Godfrey van der Linden <email@hidden>
- Date: Tue, 30 Mar 2004 16:55:58 -0800
G'day Brad,
I'm going to make a couple of assumptions. One that you have a user
client and the user client has your driver IO
Service::open()ed. This is
by far the easiest way of controlling this. Let the user client
control your driver and refuse to close() it until after all oustanding
I/Os are completed. If you are going to be particularly clean you can
also override your drivers IO
Service::terminate() function. I'd
recommend that your driver would return all outstanding I/Os with a
kIOReturnOffline error.
Your user client should be reference counting outstanding requests and
should close its provider as soon as possible after it receives the
didTerminate() message.
Tear down is very tricky to get right as some very complicated locking
occurs. In general there is no reliable way to guarantee a safe tear
down unless you synchronise with your providers workLoop, though of
course this assumes that your driver is workLoop aware. (This is still
soluble but you need to use slightly different, more complicated
techiques).
Hope this helps.
Godfrey van der Linden
PS. I briefly covered device driver teardown during my WWDC
presentation last year. Do you have access to the DVDs?
On 2004 Mar 30, at 10:10, Brad Post (MACBU) wrote:
I am having problems with the unloading of an IOKit Driver and I need
some guidance as to the correct method to solve it.
The driver is based off the same code, so we only have the standard
functions: init, free, probe, start & stop
The problem we're running into is that the user can call kextunload on
our IOKit, which calls the stop method. Our code recognizes that the
application is still using the driver and fails, and we never call the
super::stop method. Unfortunately the IOServices removes our driver
from the IORegistry, and when the user then tries to reload the driver
with kextload bad things go amuck....
Forget the fact that this is an edge-case senario, and I know the
minute
the user starts using kextunload, we don't really have to play nice,
but
I want to play nice. We don't unload, which I thought was enough, but
now I have to figure out how to stop IOServices from removing us from
the IORegistry.
Is there a routine I need to be calling or some message I need to be
listening for? Sample code?
Thanks.
Brad
=3D=3D=3D=3D< my code snippet >=3D=3D=3D=3D=3D
void mykextclass::stop(IOService *provider)
{
kern_return_t result =3D KERN_SUCCESS;
IOLog("Stopping\n");
result =3D mydriver(provider);
if (result =3D=3D KERN_SUCCESS)
super::stop(provider);
}
_______________________________________________
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.
_______________________________________________
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.