Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Kyle Moffett <mrmacman_g4@mac.com>]

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