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:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
This email sent to email@hidden
