[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |