From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [RFC] tmem ABI change... backwards compatibility unnecessary? Date: Thu, 02 Sep 2010 16:39:08 -0700 Message-ID: <4C80359C.5050002@goop.org> References: <1e601c02-1f50-4396-b4d1-e1e21ebf3dc8@default 4C7E87970200007800013C2C@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: Vasiliy G Tolstov , "Xen-Devel (xen-devel@lists.xensource.com)" , tmem-devel@oss.oracle.com, Kurt Hackel , Jan Beulich , Keir Fraser , stephen.spector@citrix.com, Chris Mason List-Id: xen-devel@lists.xenproject.org On 09/02/2010 04:19 PM, Dan Magenheimer wrote: > OK, I will submit a patch tomorrow with the following characteristics: > > v0 (current) hypervisor + v0 guest: succeeds > v1 (patched) hypervisor + v1 guest: succeeds > v0 (current) hypervisor + v1 guest: fails > v1 (patched) hypervisor + v0 guest: fails > > where fails is an xm dmesg message that says "unsupported > spec version" when the guest attempts to create a pool. > And pool creation failure ensures that all further tmem > operations also fail (indeed never even result in a > hypercall for most tmem-enabled kernels). > > Thank goodness ABI versioning was built into tmem from > the beginning! Hm, I'm not really a big fan of having a single "ABI version". It always seems better to have individual calls which can be augmented/replaced by new calls, and/or have capability flags to extend the ABI. Versions mean you end up being stuck doing updates in a very coarse-grained way, and the long-term support gets very onerous. (Microsoft ABIs are a good antipattern to avoid, especially DirectX.) J