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

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



 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

_______________________________________________
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®.