Messages in this thread | | | Subject | Re: Dealing with swsusp vs. pmdisk | From | Benjamin Herrenschmidt <> | Date | Tue, 16 Mar 2004 12:40:55 +1100 |
| |
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.
- 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/
| |