Re: Suspend-to-disk woes
From: Stefan Seyfried
Date: Mon Mar 21 2005 - 08:17:50 EST
Nigel Cunningham wrote:
> On Mon, 2005-03-21 at 11:17, Matthew Garrett wrote:
>> It's trivial to do this in userspace - just have an app in initramfs
> It's not that trivial.
> - Your image might not be stored in a swap partition. For Suspend2, it
> can potentially in a swap file or (soon) an ordinary file;
> - Finding which partition to look in for the signature might be non
> trivial (labels in fstab). You'd want to hard code it or (perferably)
> copy a config file from the root (or other) partition;
> - Having addressed the above issues, you still need to add code to read
> the swap header, parse it to find the header, read the header from the
> image, parse it and obtain the kernel version of the saved image.
Well, and you want to compile all this into the kernel? Just to hold the
hands of users who have not read the fine manual?
And you'd need to compile this into all kernels, especially those that
_don't_ support suspend to disk. Or you are back at the place where the
> If your image is not stored in a swap partition, you probably can't
> mount the fs the image is stored on, because doing so will replay the
> image and make resuming unsafe, so this approach is less trivial without
> knowing exactly which disk blocks and device IDs to use (and using dd to
> access them).
GRUB reads kernel and initramfs from a dirty reiserfs partition on
resume (although this is a bad idea if you want a fast resume, but
that's another problem). It is possible.
> On top of these, we have two implementations, so you'll want to check
> for the signatures of both.
This is the final argument for doing it in userspace :-).
> That said, I am considering making something like what you're saying:
> exposing methods of testing whether an image exists and an entry through
> which you can get Suspend to erase an image via a proc (eventually
> sysfs) entry. This will allow something like what you're saying to be
> controlled from userspace.
It does not help if the next kernel i boot is not suspend2 patched. This
work should rather go into a library that exports this functions to
userspace programs, for all known suspend implementations.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/