From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [RFC] tmem ABI change... backwards compatibility unnecessary? Date: Wed, 01 Sep 2010 09:46:28 -0700 Message-ID: <4C7E8364.8050107@goop.org> References: <1e601c02-1f50-4396-b4d1-e1e21ebf3dc8@default> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1e601c02-1f50-4396-b4d1-e1e21ebf3dc8@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: "Xen-Devel (xen-devel@lists.xensource.com)" , Jeremy, tmem-devel@oss.oracle.com, kurt.hackel@oracle.com, Vasiliy G Tolstov , stephen.spector@citrix.com, Jan Beulich , xen-users@lists.xensource.com, Chris Mason , Keir Fraser List-Id: xen-devel@lists.xenproject.org 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