From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: "Xen-Devel (xen-devel@lists.xensource.com)"
<xen-devel@lists.xensource.com>,
Jeremy, tmem-devel@oss.oracle.com, kurt.hackel@oracle.com,
Vasiliy G Tolstov <v.tolstov@selfip.ru>,
stephen.spector@citrix.com, Jan Beulich <JBeulich@novell.com>,
xen-users@lists.xensource.com,
Chris Mason <chris.mason@oracle.com>,
Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: [RFC] tmem ABI change... backwards compatibility unnecessary?
Date: Wed, 01 Sep 2010 09:46:28 -0700 [thread overview]
Message-ID: <4C7E8364.8050107@goop.org> (raw)
In-Reply-To: <1e601c02-1f50-4396-b4d1-e1e21ebf3dc8@default>
On 09/01/2010 07:36 AM, Dan Magenheimer wrote:
> I am inclined to update the Xen tmem implementation
> to only support v1 and gracefully fail v0. This would
> result in only a performance loss (as if tmem were
> disabled) for newly launched tmem-v0-enabled guests,
> but live-migration between old tmem-v0 Xen and new
> tmem-v1 Xen machines would fail, and saved tmem-v0
> guests will not be able to be restored on a tmem-v1
> Xen machine. I would plan to update both pre-4.0.2
> and unstable (future 4.1) to only support v1.
>
> I believe these restrictions are reasonable at this
> point in the tmem lifecycle, though they may not
> be reasonable in the near future; should the tmem
> ABI need to be revised from v1 to v2, I understand
> backwards compatibility will be required.
>
> Comments or questions? (If agreeable, positive public
> acks appreciated.)
Sounds fine to me. Given that pvops doesn't have tmem support in it at
all yet, I don't think the tmem userbase can be all that big. Once its
in pvops/upstream, this kind of decision will take a lot more care...
J
prev parent reply other threads:[~2010-09-01 16:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-01 14:36 [RFC] tmem ABI change... backwards compatibility unnecessary? Dan Magenheimer
2010-09-01 14:44 ` Vasiliy G Tolstov
2010-09-01 15:37 ` Dan Magenheimer
2010-09-01 15:04 ` Jan Beulich
2010-09-02 23:19 ` Dan Magenheimer
2010-09-02 23:39 ` Jeremy Fitzhardinge
2010-09-03 14:47 ` Dan Magenheimer
2010-09-01 16:46 ` Jeremy Fitzhardinge [this message]
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=4C7E8364.8050107@goop.org \
--to=jeremy@goop.org \
--cc=JBeulich@novell.com \
--cc=chris.mason@oracle.com \
--cc=dan.magenheimer@oracle.com \
--cc=keir.fraser@eu.citrix.com \
--cc=kurt.hackel@oracle.com \
--cc=stephen.spector@citrix.com \
--cc=tmem-devel@oss.oracle.com \
--cc=v.tolstov@selfip.ru \
--cc=xen-devel@lists.xensource.com \
--cc=xen-users@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.