Re: Memory image save/restore

[Pavel Machek]

Hi!

> >     Thanks for responding.  You are right in that the state of memory 
> > isn't the state of the entire machine; however, for instance, the 
> > swsusp2 project can save the contents of memory out to disk, go to 
> > sleep, and then resume to it later.
> 
> You're forgetting an important step. swsusp does not just haul off and
> save the contents of memory. It has to quiesce the entire system first
> by getting all hardware devices into a known state. THAT is the tricky
> bit, with deadlock lurking around every corner.
> 
> > Basically, what I am trying to do 
> > is something like swsusp2, with less restrictions; I know I have another 
> > region the size of physical memory to work with, I know I am executing 
> > from an interrupt handler, and at the end I don't want to go to sleep, 
> > just continue on.
> 
> That's relatively easy.
> 
> > Then I might want to use that memory image later.
> 
> That's hard. REALLY, REALLY hard. Impossibly hard.

Its not impossible. You basically may not write to disk after you save
snapshot... Or you can keep the logs to be able to revert disk state.
Its possible but pretty hard.

Okay, make it impossible if that machine is connected to internet.

> RAM image) and how are you going to suck all those tx'ed network packets
> back off the wire, anyway?


Heh... It would actually make for good april-fools rfc :-).


You could make machine where any action can be undone within five seconds...
...but you'd need mdelay(5000) in send packet path, and that would kind-of suck.

				Pavel

-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

-
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/