[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: [RFC] tmem ABI change... backwards compatibility unnecessary?



> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Sent: Wednesday, September 01, 2010 9:04 AM
> To: Dan Magenheimer
> Cc: stephen.spector@xxxxxxxxxx; Keir Fraser; JeremyFitzhardinge; Xen-
> Devel (xen-devel@xxxxxxxxxxxxxxxxxxx); Chris Mason; Kurt Hackel; tmem-
> devel@xxxxxxxxxxxxxx; Vasiliy G Tolstov
> Subject: Re: [RFC] tmem ABI change... backwards compatibility
> unnecessary?
> 
> >>> On 01.09.10 at 16:36, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.