[haiku-3rdparty-dev] Re: How does a driver detect shut-downs
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-3rdparty-dev@xxxxxxxxxxxxx
- Date: Fri, 1 Aug 2014 10:03:37 +0200 (CEST)
> On July 31, 2014 at 10:45 PM Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> On 31.07.2014 22:21, Axel Dörfler wrote:
> > Suspend to disk could be done without any driver support AFAICT,
> Not really. One doesn't need the callbacks to put the devices to sleep
> and wake them up again, but one still has to store and restore the state
> associated with a device, which requires explicit support by the
> concerned driver.
Indeed, you're right, I mixed that up (you don't need to support any power
management features, "only" state storing/restoring).
Still, it would be the first step on the road.
> > But adding a shutdown call would be a good start :-)
> Yeah. Unfortunately it isn't as trivial as it may sound, either. The
> order of FS sync and driver shutdown calls is a bit tricky. In case of
> the RAM disk driver, we first want to sync the FSs mounted on top of the
> RAM disk, then shut down the RAM disk (e.g. flushing it to an image
> file), then sync the underlying FS, and finally shut down the regular
> disk drivers.
That would probably best done with a number of states like this:
enum shutdown_phase {
// All user applications have been quit
B_PREPARE_SHUTDOWN = 1,
// All file systems have been synchronized, last call before actual
shutdown
B_FINALIZE_SHUTDOWN = 2,
}
A RAM disk driver would need to sync all disks (or find out which mounts belong
to its device, and only sync those) in 1), and forbid any further write access
after this point, and flush itself to its target disk (if any).
The disks could then be flushed, and parked in 2).
If needed we could add more states to the shutdown process at any time.
Bye,
Axel.
Other related posts:
