[Tmem-devel] [RFC] tmem ABI change... backwards compatibility unnecessary?

[Dan Magenheimer]

> From: Jan Beulich [mailto:JBeulich at novell.com]
> Sent: Wednesday, September 01, 2010 9:04 AM
> To: Dan Magenheimer
> Cc: stephen.spector at citrix.com; Keir Fraser; JeremyFitzhardinge; Xen-
> Devel (xen-devel at lists.xensource.com); Chris Mason; Kurt Hackel; tmem-
> devel at oss.oracle.com; Vasiliy G Tolstov
> Subject: Re: [RFC] tmem ABI change... backwards compatibility
> unnecessary?
> 
> >>> On 01.09.10 at 16:36, Dan Magenheimer <dan.magenheimer at oracle.com>
> wrote:
> > I *think* it is still the case that tmem is experimental
> > and is not used anywhere yet in production.  If I am
> > wrong, PLEASE LET ME KNOW ASAP.
> 
> Well, if you call us shipping it (default disabled) in a couple of
> releases "not used in production"...
> 
> > I am inclined to update the Xen tmem implementation
> > to only support v1 and gracefully fail v0.
> 
> If "graceful" really means what it says, this would appear to be
> acceptable irrespective of my note above.

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!

Dan