Re: Dealing with swsusp vs. pmdisk

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Tue, 2004-03-16 at 10:31, Nigel Cunningham wrote:
> Hi.
> 
> On Tue, 2004-03-16 at 13:01, Benjamin Herrenschmidt wrote:
> > > - 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.

> > Some of the "guard" code you added to the filesystem is scary too..
> 
> It's really just paranoia, particularly for where swapfiles are in use.
> While developing the swapfile support, I had a couple of occasions where
> I messed up my superblock because of a bug. I'm very confident now that
> the suspend code itself is stable and mature, but since the device
> drivers aren't there, I'd rather not remove the safety nets just yet.

Ok.

Ben.