Re: Advice on handling sleep with IOKit driver+daemon setup
Re: Advice on handling sleep with IOKit driver+daemon setup
- Subject: Re: Advice on handling sleep with IOKit driver+daemon setup
- From: Ethan Bold <email@hidden>
- Date: Tue, 15 Jul 2008 22:28:55 -0700
Hi Tim-
Sorry for not replying earlier - although you sound like you have
everything figured out pretty well.
I can't speak specifically to the IOBlockStorage case, but you've
outlined a very solid sleep/wake procedure:
1. Block incoming I/O while the system is sleeping
- this can be accomplished by sleeping an IOCommandGate in your
IOService::setPowerState implementation
2. Resume incoming I/O when the system has resumed
- by opening that command gate
It's your drivers responsibility to make sure that any in-flight I/O
has made it to your device before you acknowledge the call to your
setPowerState() method.
Does the OS flush devices before sleeping? I don't know; I don't know
if "flush devices" in this case means something that your
IOBlockStorage superclass would do, or what. I suspect that's a
problem that must to be answered within the mass storage IO family.
But again; out of my expertise.
You mention the "Will Sleep" notification - can you be more specific?
I'd try to do as much work as possible in "setPowerState" - the
setPowerState() call is ordered wrt other power managed devices.
"WillSleep" probably is not.
And, finally, this should have been my first question: is your driver
power managed, e.g. do you call PMinit()/joinPMtree()/
registerPowerDriver() in your start routine?
-Ethan
On Jul 4, 2008, at 9:03 AM, Tim Schooley wrote:
Hi folks!
I'm after a little advice - I see people on the list be told "you
shouldn't be doing it like that", so I thought I'd ask _before_ I go
down the wrong route.
Heres the basic idea:
---
1) I have an IOKit kext that creates IOBlockStorageDriver(s) and
device(s).
2) The I/O of these devices are passed to and handled by a user-space
daemon.
3) The devices require authentication of some form or another from the
user. This is handled in user-space.
---
The requirement is that when the system goes to sleep or the user logs
off, we "prevent" access to these devices (note the ambiguity of
"prevent" at this stage).
The way I see it (and please feel free to correct me if I'm missing
something or off-course), there are 2 different ways for preventing
access to these devices:
---
1.1) In the kext, simply block IO to the devices. This seems the
quickest and most elegant way, since a) it won't remove the device
from
the system, b) it won't run into "Volume Busy" errors that could occur
using an unmount instead, c) Once unlocked, user-space applications
that
may have had files open on the device can continue on their merry way.
BUT! Does the OS flush devices before sleeping? When "WillSleep" is
called, has all flushing finished?
1.2) In user-space, try to eject all the devices before the 30 seconds
are up. But that's not exactly elegant, is it? And what if it takes
longer than 30 seconds? (Side-question: Does DADiskEject _require_
DADiskUnmount beforehand?)
---
Also, there are a few different options for invoking the "prevention"
available:
---
2.1) Use a launchd agent for the logged-in user, register for sleep
events, and initiate "prevention" from there.
2.2) Register for sleep events in the daemon, and initiate
"prevention"
from there.
2.3) Handle "prevention" in the kext.
---
My initial thoughts are to go with 1.1, as it seems simple and clean.
But I don't know whether its "the right thing to do" or not.
Any help/advice/suggestions would be most appreciated,
Kind regards,
Tim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden