On Feb 12, 2006, at 03:51, Alon Bar-Lev wrote:
1. Store state on files
This is not a "feature", it's just something that causes a lot of
downsides (chew up disk space, fragment files, add code complexity,
etc).
this allow you to resume your machine into a different OS.
This is the "feature". On the other hand, I'm going to argue that
this isn't really what we want to be doing for complexity reasons.
We want to implement the container and userspace-freeze code
described in the virtualization thread, then implement software-
suspend-and-resume-into-different-OS as freeze-userspace-container,
shutdown. Then you could trivially have different sets of working
data/processes, load up multiple sets at once, selectively freeze,
etc, with far less kernel complexity.
2. Encrypt state - this allow you to be sure that your data is
stored encrypted. (Yes... You can encrypt the memory... but then
you need a whole initramfs clone in order to allow the user to
specify how he want to encrypt/decrypt).
Why the hell would you even _want_ to encrypt data in RAM? If you
have a secure OS install and a passworded screensaver that starts
before suspend, then there is _nothing_ an attacker could do to the
contents of RAM without hard-booting, which would just completely
erase it, or without extremely specialized hardware and expertise.
Picking up a machine suspended to RAM is just as secure as picking up
one that is on, no more or less.
3. Network resume - this allow you to resume a network machine (Not
implemented yet, but cannot be done if
suspend-to-RAM is the sole implementation).
4. Support desktops/servers - this allow you to suspend/resume
hardware that is not designed to sleep, in order to minimize
downtime on power failure.
This again is covered by the container-freeze stuff being implemented
as described above, and is unrelated to the suspend-to-RAM. When I
want suspend-to-RAM, I want something that will work instantly with
no overhead, so I can close my laptop and have it asleep 2 seconds
later, or open it and be able to use it within 2 seconds. That's an
extremely different use-case than the above two.
And another fact: Suspend-to-RAM implementation can be derived form
suspend-to-disk but not the other way around.
No, the two are _entirely_ independent. Suspend-to-RAM does not need
to copy memory at all, whereas suspend-to-disk requires it. That
very fact means that suspend-to-RAM is orders of magnitude faster
than suspend-to-disk could ever be, especially as RAM gets
exponentially larger.
So let's invert the initial "fact"... Suspend-to-RAM is basically
for people that don't need the full functionality of suspend-to-
disk, after I got suspend-to-disk to work reliably here (suspend2),
I *NEVER* use suspend-to-RAM.
No, suspend-to-ram is for people who need instant response times,
suspend-to-disk should be an extension or simplification of "Freeze a
process tree and all associated system status so we can completely
give up the hardware for a while". IMHO, the fact that both are
called "suspend" is just due to historical quirk as opposed to any
real similarity.
Cheers,
Kyle Moffett
--
There is no way to make Linux robust with unreliable memory
subsystems, sorry. It would be like trying to make a human more
robust with an unreliable O2 supply. Memory just has to work.
-- Andi Kleen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
