Messages in this thread | | | Date | Tue, 16 Mar 2004 11:09:25 +0100 | From | Pavel Machek <> | Subject | Re: Dealing with swsusp vs. pmdisk |
| |
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?] - 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/
| |