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

[Jeremy Fitzhardinge <jeremy@goop.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