On Tuesday 20 June 2006 9:36 pm, Linus Torvalds wrote: > > > For example, the _real_ suspend case (ie non-snapshotting case) has no > reason what-so-ever (apart from debuggability) to really stop any queues Not quite true, as you touch on below ... > etc. So if you want to do _real_ suspend, what you should do is exactly > what you propose: make it built up around the device model. Except you > don't actually need to empty or stop any queues, you just stop the devices > from handling them. > > See? There's absolutely zero overlap in functionality. The two approaches > literally do totally different things. > > Linus > > PS. The real reason to make queues be quiescent when doign suspend-to-RAM > is different: if you never come back from the suspend, you should try to > have what approaches a clean "dirty shutdown". Actually, even when you _do_ resume correctly you want the I/O queues to have been shut down cleanly. You need to think about intermediate cases like removable media (partially covered in your "sync" case) and the fact that there are other removable stateful peripherals than media. - Dave > So you actually do want to > do "sync" and wait, not because you technically need to, but because it's > a whole lot safer if you end up disconnecting your machine from a power > source and forget about it. > > PPS. And debugging. Suspend/resume is hard enough and error-prone enough > even without having to worry about the machine doing tons of stuff. >
