site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Thunderbird 2.0.0.14 (X11/20080505) 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com