[Yaird-devel] Bug#329319: yaird: swsusp not all that hard

C. Scott Ananian cscott at cscott.net
Mon Dec 12 23:19:12 UTC 2005


On Mon, 12 Dec 2005, Erik van Konijnenburg wrote:

> Two points to consider:
> * what do other tools do?  We would not want people that convert to or from
>  initrd-tools or mkinitramfs to have to change their grub of fstab configuration
>  to keep their swsusp working.  Only be incompatible if it can't be avoided.
>  Ideally, avoid incompatibility even among distros.

I don't know what other tools do -- swsusp seems to be an "experimenters 
only" option right now, as far as I can tell.  My goal was to make Debian 
Do The Right Thing By Default and make it easier for people to try this 
stuff out.

> * Could we avoid configuration altogether?  We could simply always do the resume
>  code for all swap devices, if swsusp or swsusp2 is enabled in the kernel config.
>  If the distro has swsusp in the kernel, this would mean users could start
>  using swsusp without having to regenerate the initramfs; downside is they would
>  have to edit the grub/lilo menu.

Well, swsusp needs to be told what partition to suspend *to*.  The current 
swsusp code sets the 'to' directory as a side-effect of attempting the 
suspend 'from'.  Trying to resume from *all* the swap partitions wouldn't 
be terrible, but it still requires parsing the /etc/fstab to find out 
which partitions those are.  But maybe the default should be "resume from 
all, *unless* one is marked with a 'resume' tag".  That way (those few) 
people with multiple swap partitions can still specify which they want.

And resuming from all will cause us to suspend to the last partition 
tested, by default.  It would be nice to use the 'largest' by default --
but this can always be overriden in the actual suspend code (not the 
resume code) which is perhaps where such policy decisions belong.

I can turn the crank on another patch if something like this sounds like 
what you'd want.

> Attached some notes on swsusp I made earlier; untested so far.

Your characterisation of software suspend seems a little off. "[D]epending 
on how long the system has been idle, you may want to bring devices to a 
less active state, with reduced noise and reduced power consumption."  I 
think the primary use of software suspend, rather, is by *laptop users*, 
who could care less about "reduced noise" but rather need to save their 
working state without draining their batteries.  Detecting "how long the 
system has been idle" is not really a big concern; most suspends are 
triggered by explicit user action (ie, by closing the lid or by using a 
special key sequence).

In your notes on suspending with swsusp, you don't need the kernel option, 
as long as you do the echo to /sys/power/resume (before the suspend, too).

> I've started testing dmraid, and have only a limited supply of boxes to play
> with (and limited time to play in ...) so it will be a while before I can test
> the swsusp.

My philosophy here is to get *something* (non-harmful!) in yaird ASAP, 
which will then (hopefully) provoke comments and perhaps revisions.
I don't think the features are well-known enough to do a "perfect" design 
ex nihilo.

For example, if you roll out very basic support for swsusp2 (which my 
patch provides) with somewhat more complete support for swsusp, I expect 
that some swsusp2 user will be motivated to complete the swsusp2 support.
But at the moment, since the stock debian kernel supports swsusp (but not 
swsusp2), it seems that yaird should (at least) support swsusp.
  --scott

arrangements Morwenstow TASS SGUAT LICOZY Marxist ammunition ODYOKE 
COBRA JANE SHERWOOD DC counter-intelligence BATF radar Kojarena assassinate
                          ( http://cscott.net/ )




More information about the Yaird-devel mailing list