On Fri, 27 Apr 2007, Johannes Berg wrote:
> Look at it now:
>
> * FREEZE Quiesce operations so that a consistent image can be saved;
> * but do NOT otherwise enter a low power device state, and do
> * NOT emit system wakeup events.
> *
> * PRETHAW Quiesce as if for FREEZE; additionally, prepare for restoring
> * the system from a snapshot taken after an earlier FREEZE.
> * Some drivers will need to reset their hardware state instead
> * of preserving it, to ensure that it's never mistaken for the
> * state which that earlier snapshot had set up.
>
> Why is prethaw even necessary? As far as I can tell it's only necessary
> because resume() can't tell you whether you just want to thaw or need to
> reset since it doesn't tell you at what point it's invoked.
I think you're wrong here. It's a little hard to say because the
terminology is confusing and not yet standardized.
For the sake of argument, let's call the stages of STD and STR by these
names (also noted are the current PSMG values):
Suspend to disk:
"prepare to create snapshot" (= FREEZE)
"continue after snapshot" (= RESUME)
Resume from disk:
"prepare to restore snapshot" (= PRETHAW)
"continue after restore" (= RESUME)
Suspend to RAM:
"suspend" (= SUSPEND)
"resume" (= RESUME)
The real reason for adding PRETHAW was that drivers couldn't distinguish
between "continue after restore" and "resume", other than by examining the
device's state -- since the PM core doesn't pass any information to the
resume() method.
I suppose we could have modified the "prepare to create snapshot" code
instead, but doing so would mean that "continue after snapshot" and
"continue after restore" would always do the same thing, which is not
necessarily a good idea.
Anyway, based on this analysis it seems reasonable to have Six (6) method
pointers. Suggested names (in the same order as above):
pre_snaphot()
post_snapshot()
pre_restore()
post_restore()
suspend()
resume()
People apparently assume that pre_snapshot() and pre_restore() would
always do the same thing and hence be redundant. I'm not so sure; time
will tell. Doing it this way certainly is more clear.
Then there's the question of having early_ and late_ versions of some of
these things (i.e., one called with interrupts enabled, the other with
interrupts disabled). I don't know to what extent that would be
necessary; perhaps the each method call should occur in two phases with
the interrupt-enable status changed in between. Then the interrupt-enable
setting could be passed as an argument.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
