From: "Mike D. Day" <ncmike@us.ibm.com>
To: Stefan Berger <stefanb@us.ibm.com>
Cc: xen-devel@lists.xensource.com, "Cihula,
Joseph" <joseph.cihula@intel.com>,
Ronald Perez <ronpz@us.ibm.com>,
"Scarlata, Vincent R" <vincent.r.scarlata@intel.com>
Subject: Re: A migration framework for external devices
Date: Thu, 09 Feb 2006 07:34:35 -0500 [thread overview]
Message-ID: <43EB36DB.7080302@us.ibm.com> (raw)
In-Reply-To: <OFAF40C2ED.9A049C9A-ON8525710F.007C18EC-8525710F.007C8530@us.ibm.com>
Stefan Berger wrote:
>
> It should be possible to do that as long as it is definable what 'good
> state' means.
Yes, good point. In this case the framework should not define policy,
but the plugin should. In other words, the plugin could do whatever it
wants to on the target, the framework only cares about the status
returned by the plugin. If the plugin says "ok to proceed" then the
migration continues.
>
> Another question is whether an extensible protocol exists that could be
> recycled for this purpose or we have to build something from ground up.
Unfortunately the best thing I can think of is a protocol defined using
xml. As you mentioned, this idea includes existing bulk transfer but
adds event and procedural semantics. xml encodings are already defined
for everything we need including bulk data transfers, event semantics,
and remote procedure calls. However, I don't think we should use xml
encodings for bulk data transfer. We could keep that part as it is now.
I don't think xml would dominate the migration protocol. We could use it
for the plugin semantics and to control the important checkpoints in pre
and post -migration phases. But the migration itself should be encoded
in the existing file transfer protocol.
Mike
next prev parent reply other threads:[~2006-02-09 12:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-08 20:16 A migration framework for external devices Stefan Berger
2006-02-08 21:28 ` Muli Ben-Yehuda
2006-02-08 21:30 ` Stefan Berger
2006-02-08 22:32 ` Mike D. Day
2006-02-08 22:40 ` Stefan Berger
2006-02-09 12:34 ` Mike D. Day [this message]
2006-02-09 15:01 ` Daniel Veillard
2006-02-09 16:10 ` Mike D. Day
2006-02-13 10:18 ` Daniel Veillard
2006-02-09 16:20 ` Stefan Berger
2006-02-09 16:37 ` Mike D. Day
2006-02-09 15:05 ` Anthony Liguori
2006-02-09 16:52 ` Stefan Berger
2006-02-09 17:05 ` Anthony Liguori
2006-02-09 17:51 ` Stefan Berger
2006-02-09 18:35 ` Mike D. Day
2006-02-09 18:45 ` Anthony Liguori
2006-02-09 18:58 ` Mike D. Day
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=43EB36DB.7080302@us.ibm.com \
--to=ncmike@us.ibm.com \
--cc=joseph.cihula@intel.com \
--cc=ronpz@us.ibm.com \
--cc=stefanb@us.ibm.com \
--cc=vincent.r.scarlata@intel.com \
--cc=xen-devel@lists.xensource.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.