On Tue, Nov 18, 2014 at 8:32 AM, Jan Beulich <jbeul...@suse.com> wrote:
> >>> On 17.11.14 at 18:06, <tamas.leng...@zentific.com> wrote: > > On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich <jbeul...@suse.com> wrote: > > > >> >>> On 12.11.14 at 16:48, <andrew.coop...@citrix.com> wrote: > >> > On 12/11/14 15:31, Tamas K Lengyel wrote: > >> >> xen/include/public/domctl.h | 44 +-- > >> >> xen/include/public/hvm/params.h | 2 +- > >> >> xen/include/public/mem_event.h | 134 ------- > >> >> xen/include/public/memory.h | 6 +- > >> >> xen/include/public/vm_event.h | 179 +++++++++ > >> > > >> > While in principle I think this series is a very good thing, there is > a > >> > problem with editing the pubic header files. > >> > > >> > The contents of mem_event.h is not currently hidden behind #ifdef > >> > __XEN_TOOLS__ > >> > > >> > As a result, it is strictly speaking part of the VM-visible public > >> > API/ABI and not permitted to change in a backwards incompatible manor. > >> > > >> > Having said that, it is currently only usable by privileged domains, > so > >> > there is an argument to be made for declaring that it should have been > >> > hidden behind __XEN_TOOLS__ in the first place, making it permittable > to > >> > change. > >> > >> I'm not sure I agree - the meaning of "tools" here would seem quite a > >> bit different than e.g. in domctl.h. Looking at patch 1, I can't see how > >> an old consumer (remember that for many of these we have at best > >> fake consumers in the tree) would deal with the now differently > >> arranged data. I don't see any versioning of the interface, and hence > >> I can't see how tools would know which of the formats to expect. > > > > The lack of versioning is a real concern which I have aired during the > 4.5 > > development process. For example, when we switched from HVMEM_access_* to > > XENMEM_access_* a customer had to do a bunch of manual configure checks > to > > determine what is supported and what isn't. Furthermore, many of the > > related APIs have changed quite radically between Xen 4.1-4.5, some being > > abandoned midway just to resurface later in a different context. Going > > forward having a clear VM_EVENT_VERSION definition would be very helpful > > and would be the cleanest solution IMHO. > > That's a concern different from mine - source compatibility may be > acceptable to get broken. Undetectable binary incompatibilities are > what worry me more. > > Jan > To be fair, I don't think there ever was backwards compatibility established with the usage of that struct in source or binary form. A quick glance at git log shows that it had been shuffled around and extended quite a bit over the years. Going forward it would be best to start with something that's clean before backwards compatibility is enforced IMHO. Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
