From: Dan Shearer <dan@shearer.org>
To: Michael Snyder <msnyder@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: [discuss] going back: reverse-execution vs. checkpoint/restart
Date: Mon, 23 May 2005 19:32:00 -0000 [thread overview]
Message-ID: <20050523193155.GF19663@erizo.shearer.org> (raw)
In-Reply-To: <42922617.3050805@redhat.com>
On Mon, May 23, 2005 at 11:51:03AM -0700, Michael Snyder wrote:
> As Frank points out, the "rs/bs" and "rc/bc" primatives
> are useful only for a really clever target -- one that
> not only has a means of backing up to a previous state,
> but can do it at single-instruction granularity, fast
> and efficiently, and has worked out a lot of the 'kinks'
> that a lot of us haven't even thought about yet. And
> as Paul points out, there is currently only one such
> target that we know of.
True. One of the interesting things here is that while the limiting case
above is just the same as checkpointing before in terms of the technical
concept, the end result is quite different. I charaterise the above as
reversible hardware and the below as timeshifting.
> The bookmark (or checkpoint/restart) model is a considerably
> smaller and less daunting "chunk" for the target-side
> implementer to take on at one go -- and is not necessarily
> limited to simulators. If gdb implemented an interface for
> checkpoint/restart, there's a good chance that a number of
> targets would soon take advantage of it.
I agree.
http://sbuml.sourceforge.net/ (32-bit intel User Mode Linux instances)
probably could use it straight away.
Xen (which runs Linux, BSD and other targets on x86 only for now)
currently can save and restore memory state but doesn't do disk state.
But presumably if the developers decided it was interesting they could
quickly do it. See http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
QEMU (which runs numerous OSs on PPC, x86, Sparc and others to varying
degrees of completeness) already implements savevm and loadvm commands
for memory and a snapshot command for disk images. QEMU would not be far
from being able to incorporate a stub supporting this level of
functionality. See http://fabrice.bellard.free.fr/qemu/
DragonflyBSD and a number of other OSs offer checkpointing at the
process level and are working to expand the scope.
In commercial space, Solaris for example has had full-system
checkpointing for nearly ten years done by Aurema, who also did
implementations for other companies.
--
Dan Shearer
dan@shearer.org
next prev parent reply other threads:[~2005-05-23 19:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-23 18:51 Michael Snyder
2005-05-23 19:01 ` Daniel Jacobowitz
2005-05-23 19:15 ` Michael Snyder
2005-05-23 19:32 ` Dan Shearer [this message]
2005-05-23 19:37 ` Dan Shearer
2005-05-24 4:47 Paul Schlie
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=20050523193155.GF19663@erizo.shearer.org \
--to=dan@shearer.org \
--cc=gdb@sources.redhat.com \
--cc=msnyder@redhat.com \
/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