Thursday, December 28, 2006

Upcoming changes to Suspend2.

Support for building suspend as modules will return in the next release. It was originally removed because I was seeking to get the code merged into the vanilla kernel. Since I don't reckon that's going to happen any time soon, I've decided to re-introduce the code. Building Suspend support as modules is primarily useful to embedded users, but it's also good for me - it means I can work on some changes without having to reboot to test.

I'm also beginning to add cluster support. The idea is that you can synchronise the suspending and resuming of a group of computers, controlling everything from a central node (the master). As I plan it at the moment, the master will have a kernel thread running that will open a socket for slaves to connect to. It will then send them commands, telling them to freeze processes, write the image, power down, report whether they have an image and so on as appropriate. The functionality should be particularly useful in a power outage, but could perhaps also be used to switch tasks (with the usual caveats about mounting filesystems).

The last new function is the ability to resume another image instead of powering down. This could be used in a lab environment. Imagine, for example, that users' home drives are mounted from a server with a file system that's well suited to breaking and resuming connections, such that the user could suspend to disk from one workstation and then log in from another and resume their previous image. (I'll ignore issues of ip addresses and so on, for the moment).
Wouldn't it be good if, when suspending, the system resumed another image that put you back at the log in screen, rather than rebooting or such like? The simplest scenario might be an individual computer, with completely separate installations of Linux, but a shared kernel image. (Cross-distro testing?). Of course I say completely separate installations because we still have the can't-mount-a-filesystem-mounted-in-another-image-unless-all-are-mounted-read-only problem.

Interestingly, in the history of Suspend2, this is the first time I've added features without being explicitly asked for them. (I asked on the cluster mailing list whether they'd find cluster support useful, though).

2 Comments:

Blogger Unknown said...

I'm using suspend2 built as a module, but it doesn't quite work -- as you can expect, it suspends fine, but doesn't resume. :) I know it's my fault--have to do some tricks in the initrd file, but I don't know exactly what (Debian, initramfs-tools).

Are there any HOWTO-s on how to use suspend2 as a module? (googled a lot, couldn't find one...)

Thanks for your great work! ;-)

1:59 am  
Anonymous Anonymous said...

Sorry for the glacially slow reply!

There is an issue on SMP machines with building the core as a module. I've been working on diagnosing the cause but for now, if you ensure the core is built in (not modular), it should work... assuming I'm right in guessing your machine is SMP.

9:35 pm  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home