Two software suspend image writing patches [LWN.net]

The software suspend story seems to repeat itself endlessly. Developers debate multiple implementations while no decision gets made and software suspend in Linux continues to fall short of what it could really be. One place where this discussion might actually come to a head soon is in the storage and retrieval of the suspend image - the copy of system memory which is stored on disk while the system is down. Two approaches are being pushed; they reveal two very different views of the problem.

One approach is the user-space interface, currently being developed by Rafael Wysocki. Rafael's patch is similar in spirit to the user-space patch covered here last September. It no longer uses /dev/kmem, however; instead, it sets up a dedicated device for the software suspend operations. A user-space program can then invoke a set of ioctl() operations to freeze the system, allocate swap space, and move memory pages to their resting place - possibly compressing or encrypting them on the way. The documentation file provided with the patch gives a good introduction to the interface and how it should be used.

In the other corner we have Nigel Cunningham, who has recently broken out the modules mechanism from his Suspend2 patch set. Rather than move image writing and reading support to user space, this patch sets up a complex kernel interface for plugins which take on parts of that task. There are two types of plugins: "filter" plugins which transform the image data (performing encryption, say) and "writer" plugins which handle the actual storage I/O. Parts of the code anticipate "misc" and "checksum" plugins as well, but those are not currently supported.

The plugin API is somewhat complex. Each plugin has eleven methods to provide to the core suspend code; these handle memory allocation, configuration, initialization and cleanup. Filter plugins must define three more methods to handle data passing through for processing. And writer modules have an additional 21 methods to provide for dealing with various parts of that task. There are, it seems, a lot of things that have to be done to get an image written to (and read from) persistent storage.

The two patches are clearly incompatible - there is no point in setting up an elaborate in-kernel interface if the whole process is to be moved out of the kernel altogether, and vice-versa. So, before merging either of these patches, somebody will have to make a decision. Anyone looking for tea leaves to read might take a hint from the fact that the user-space patches are currently in the -mm tree. As the reiser4 folks (among others) know, however, the road from -mm to mainline can be long and perilous.

(Log in to post comments)

Two software suspend image writing patches

Posted Feb 2, 2006 23:35 UTC (Thu) by NCunningham (guest, #6457) [Link]

My intention was actually that it would be the first of a number of sets
of patches in preparation for getting Suspend2 merged.

Given the discussion that has resulted since then, though (see LKML), I
don't currently see any point to spending the time on preparing a git tree
or posting further patchsets. I'm thinking I'll just maintain the patch
out of tree. If people want to use it, they know where to find it.

Of course having said that, I know that perspectives can change, and a few
hours of not thinking about this might do me good :). We'll just have to
wait and see where we go from here.