Sure it does. Drivers have to save & resume state don't they ?
How can a driver save a consistent state if that state isn't
saved after blocking IOs and how can that be done if childs
of that device haven't already done their save_state/block
sequence ?
The problem is tricky with things like USB or FireWire. Basically
the host chip state save will not save pending requests state (it
would be way too nasty), so child devices will have to make sure
they stop any pending request before saving a consistent state.
Later on, during the actual "suspend" phase of the process, the
child drivers may eventually re-issue a new request, but that
will not result to a state change in the saved state (as it will
be too late for suspend to disk typically).
The suspending of tasks etc... as done currently by swsusp makes
definitely things easier as far as VM & block IO interactions
are concerned though, I agree. Might be a good idea to keep
that part "simple" for now as there is still enough work
with things like USB & 1394.
>> Then, I volunteer writing a HOWTO explaining clearly what a
>> driver should do for proper PM, and I'm pretty sure that won't
>> be that nasty and race prone as you are afraid of ;)
>
>Good. It'll be nice to have suspend to disk in 2.7
Well, it's mostly driver work, and the hooks are in there already
with the device model, so this will be driver updates going to
2.5/2.6 over time I guess. We just need to get the semantics right.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/