Re: Dealing with swsusp vs. pmdisk

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > > > - Freezer hooks (I can easily get suspend2 working with the old freezer
> > > > until people are convinced it's not up to the task). This accounts for
> > > > the vast majority of those file changes.
> > > 
> > > It would be nice if you did that as a first step indeed. I'm personally
> > > not convinced of the usefullness of having a freezer at all ;)
> > 
> > Without a freezer, how would you ensure that other processes don't mess
> > up your memory state while you're saving/reloading the image?
> 
> Hrm, you are not protecting about "asynchronous" (interrupt based)
> activity anyway... I'm not sure how the IO sceduler may kill us
> and whatever doing things based on a timer that doesn't have a
> device-driver underneath getting the PM callbacks.
> 
> As far as suspend-to-disk is concerned, I agree we need a state
> snapshot, then we need to be able to play with drivers to save that
> state without having userland get in the way, so yup, we need a
> freezer. I think we don't need it for suspend-to-ram though.

You are right, freezer should not be needed for s-to-ram. I wanted to
keep it consistent with s-to-disk, and maybe make locking a bit easier
for drivers.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]