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