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/ )
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
