A bit of history

A bit of history

Linus is arguing that the fact that S2ram and S2Disk are being treated the same is a fundamental misdesign.

for S2D you don't need to worry about freezing devices or kernel threads, and needs little, if any driver support. instead all you need to do is atomicly make a snapshot of memory and make it so that devices don't get written to (or any writes can be thrown away, say for example useing the LVM snapshot capability) userspace can then resume, do whatever it wants with the snapshot of memory (compress it, encrypt it, save it to disk, send it over the network, etc) and then do a normal shutdown.

to restart you boot any kernel , load the image into ram, and do something like a kexec to switch back to the old kernel.

performance for this is very much not critical (especially for the suspend)

for for S2Ram you also don't need to do as much as is currently being attempted. instead you just pause userspace, and power devices down in order. then to resume you power the devices back up and resume userspace scheduling.

the ultimate implementation of S2Ram is something like the OLPC, with properly selected hardware it can look seriously at doing a suspend to ram between keystrokes. to do this the performance is critical.

the current process that tries to have one routine do the job for both purposes not only fails to do either job well, but it also manages to confuse people about what the function call is supposed to do which makes it almost impossible for developers to do it well

after a lot of yelling and screaming he has everyone convinced that the two types of suspend need to be seperated (in fact, to avoid confusion S2D is being called 'hibernation' instead of 'suspend')

what happens next is going to be interesting.

one possible approach is to implement what linus is proposing for hibernate, which includes a new API and new userspace tools. if this happens it may end up that the disk snapshotting will literally use the LVM tools. This would require people who want to do hibernation to prepare for it by configuring their drives to support snapshots, but avoids a HUGE amount of hibernation specific code in drivers.

the suspend to ram will need driver support, but since the driver routines will not be nearly as complicated (and for most drivers most of the routines are noops) it should be much easier to get the needed support in place.

one thing I would like to see someone try for the hibernate situation is to take a look at the virtulization work that's being done, especially the work to migrate processes from one system to another. I think the ulimate hibernation would be to grab each set of processes that are entangled with each other (via unix sockets, shared memory, or other IPC mechanisms) and treat each one as seperate entity, storing it to disk. then it would even be possible to 'wake up' on a new kernel that then has the processes continue where they left off.

Note: you can avoid this step in the future by logging into your LWN account.