Hi! > > Okay, so you are saving state, then changing it. Now.. you are right > > that for most devices it is possible to separate state that does not > > change from state that changes; that is okay but lot of work. > > It's ok _by_definition_ for all work, since any changes we do are done by > ourselves, so it's "not important". > > I think that a lot of problems that people look at aren't actually > "device" problems at all, but "memory management" problems. > > The fact is, suspend-to-disk is really nasty from a memory management > standpoint, since the image you save to disk is not the "final" image in > the same sense that the STR image is (or the APM suspend image is). Right. Fortunately, it is only nasty brain-teaser when you try to think about it, code is not that bad. > That means, for example, that if you save-and-restore temporary pointers > in your device status, you need to do something about the > _memory_management_ problems, but that has really nothing to do with > saving and restoring the hardware device state. ? No, I do not think we have any problems with temporary pointers. Memory snapshot is atomic (done on single CPU, with disabled interrupts, no DMAs). Snapshot restore is also atomic (1 CPU, no interrupts, no DMAs). And snapshot just take all the (allocated) memory, so we need absolutely no support for saving state that is not in hardware. > - some drivers might choose to not support suspend-to-disk as well as > they support suspend-to-ram. They might, for example, decide that > if it ? If driver support suspend-to-ram, it automatically supports suspend-to-disk (albeit maybe slowly, like in disks case, which were unneccessarily spun down). > But notice how this is about _memory_, not about the actual hardware > device state? ? I do not see what problems are that with memory. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
