Hi, On Wednesday 16 March 2005 1:44 pm, Nigel Cunningham wrote: > On Thu, 2005-03-17 at 08:05, David Brownell wrote: > > For the record, I've recently observed that all the swsusp issues > > start making sense to me when I start thinking of swsusp as being > > completely unrelated to suspend states. (S4bios aside...) And if > > I don't think of it that way, I keep tripping over complications > > where it's fighting against "real" suspend states. > > > > The thing is, swsusp in normal usage does not involve system > > suspend states like S1/S2/S3, or their analogues in non-ACPI > > embedded systems. Neither does it involve wakeup from those > > states ... in fact, it fights against addressing all those. > > Both swsusp and suspend2 can enter S4 as their method of powering down, > and do use the prepare, enter and finish methods when doing so. As I said, S4 aside. The history I recall is that swsusp came out a fair degree of frustration with getting Linux to work with the BIOS support ... and lack of firmware init for video, etc. And certainly S4 modes don't seem to be the default, or widely used/tested. > > If swsusp were called a system checkpoint/restore mechanism, it'd > > have a much clearer relationship to power management: enabling > > system power-off is a useful side effect, but it's not exactly > > the point of a checkpoint mechanism. I suspect that if it were > > packaged as halt-after-checkpoint, plus resume-from-checkpoint, > > a lot of technical issues would start shaking out better. Also > > maybe some political/funding ones ... checkpointing has much > > value for enterprise server operations. > > Checkpointing and restoring is very different from what swsusp and > suspend2 do. I've been asked a number of times if I could make Suspend2 > do checkpointing as well as suspending, and it's simply not possible. That is, other folk have noticed that it's essentially the same problem... > The reason is that we really are suspending to disk. We're writing the > entire contents of memory, and those contents are only valid while the > disk is in exactly the state it is in when we suspend. As soon as you > change a file on the disk (as you would after checkpointing), the image > is invalid and will create corruption if restored. To do checkpointing, > we'd at least have to modify the implementations to be able to reverse > on disk changes back to the point where the checkpoint was taken, and > probably also add a mechanism for tracking in-memory changes and > updating the image to reflect them. It's not impossible, but it's not > what swsusp and Suspend2 do now. True, not what they do now. I didn't intend to imply they did. A checkpoint package would have key differences, including those. That wasn't my point: that swsusp, in normal usage, is more of a checkpoint/restore than a suspend/resume. Which is why some of what it wants is different from suspend/resume. In particular, since the devices are goin to be powered off, the resume paths are VERY different. They are in fact reset paths, not resume paths. > I realise you're writing in the context of freezing drivers, and may > simply be thinking in terms of the action being the same as would be > required if you were checkpointing. From that point of view I'd probably > agree. But in the first instance, I'm reacting to you speaking of > calling swsusp a system checkpoint/restore mechanism. I'm trying to articulate why so much of the swsusp stuff seems (to me) to be fighting against "normal" suspend/resume and wakeup mechanisms, which can more naturally be built piecemeal from selective suspend. (And why there's any pushback on selective suspend, given that it's so basic to "normal" suspend/resume/wakeup.) So yes, that's from the driver perspective. - Dave > Hope that helps. > > Nigel > > > OK, that's enough of a radical perspective for the moment. > > I'm not sure I'll throw any more monkey wrenches today. ;) > > > > - Dave > -- > Nigel Cunningham > Software Engineer, Canberra, Australia > http://www.cyclades.com > Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 > > Maintainer of Suspend2 Kernel Patches http://suspend2.net > >
