public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paulo Marques <pmarques@grupopie.com>
To: Chris Lalancette <chris.lalancette@gd-ais.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Memory image save/restore
Date: Tue, 13 Apr 2004 20:23:09 +0100	[thread overview]
Message-ID: <407C3E1D.1080609@grupopie.com> (raw)
In-Reply-To: 407C2FF7.4010500@gd-ais.com

Chris Lalancette wrote:

> Paulo,
>    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.  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.  Then I might want to use that memory image later.


That is not *all* the swsusp2 project does. Probably the biggest challenge in 
the software suspend project is to get all the devices to acknowledge that they 
are being "suspended" and to have them resume properly.

Just as an example, imagine that the usb host controller is currently 
dispatching an urb to a device. The kernel in-memory structures reflect this 
occurrence. The kernel is ready for the interrupt the controller will generate 
to update these structures.

You now interrupt, and save the memory contents. You let everything proceed, and 
after a while try to recover the previous memory contents.

Now the kernel is expecting the interrupt from the controller, regarding an urb 
that the controller has dispatched a long time ago. The state of the controller 
and the kernel in-memory structures is out of sync.

This is just a small example. I could think of this sort of examples for disk 
reads/writes and IDE/SCSI controllers, accelerated graphics adapters, etc., etc. 
Even much simpler examples, like keyboard state (a scancode was just received to 
press a key, and the corresponding release is lost), internal timer/clock, etc. 
will cause you problems just the same.

However, I'm not an expert in this area. Maybe someone like Nigel Cunningham or 
Pavel Machek can explain better the problems that arise from trying to save the 
complete *state* of the system. I just wrote this to try to save these guys the 
trouble, since they can occupy their time better in developing the damn thing :)

-- 
Paulo Marques - www.grupopie.com
"In a world without walls and fences who needs windows and gates?"


  reply	other threads:[~2004-04-13 19:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-13 16:44 Memory image save/restore Chris Lalancette
2004-04-13 17:03 ` Paulo Marques
2004-04-13 18:22   ` Chris Lalancette
2004-04-13 19:23     ` Paulo Marques [this message]
2004-04-13 19:48     ` Adam Kropelin
2004-04-15 14:11       ` Pavel Machek
2004-04-15 14:02 ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=407C3E1D.1080609@grupopie.com \
    --to=pmarques@grupopie.com \
    --cc=chris.lalancette@gd-ais.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox