[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] 3.0.3 freeze
On 28/8/06 4:49 pm, "Daniel Veillard" <veillard@xxxxxxxxxx> wrote: >> All bug fixing is going on in the unstable tree: there has been no fork. I'm >> now done with major refactorings (domctl/sysctl on Friday; shadow2->shadow >> today). I wanted those in before 3.0.3 because, although large, they are >> unlikely to break anything, > > Huh ? libvirt uses dom0 syscalls. And libvirt uses its own code to do it > since the existing libraries for dom0 calls are GPL'ed which would not be > compatible with libvirt own licencing (LGPL). The headers used by libvirt > are simply removed, the ioctl entry points are changed, etc ... You really > expected that to 'not break anything' ? API/ABI compatibility is not guaranteed at the low-level control-plane interfaces: that is instead provided at the XML-RPC level (and, practically speaking, the libxenctrl/libxenguest interface is pretty stable too). By 'no breakage' I mean that the new interfaces work fine with a matching set of the supported libraries libxenctrl and libxenguest. > +#define XEN_DOMCTL_getdomaininfo 5 > > +#define XEN_SYSCTL_getdomaininfolist 6 > > Can you explain why listing one domain info is a control operation (subject > to changes) and listing multiple domain info in a nearly identical way is a > system operation (and supposedly slightly more stable from now on). Neither of the above interfaces (sysctl/domctl) has guaranteed ongoing API or ABI compatibility. The new platform_op interface, used by dom0 kernel, is the only new hypercall for which we will guarantee ongoing stability. The two commands you refer to are in different hypercalls because one is specific to a particular domain (hence domctl) while the other is a request for 'system-wide' info about all domains (hence sysctl). > Was any HV call removed, or did they were all split between the 3 new sets ? None were removed. They've simply been reassigned as sysctls or domctls to rationalise the API. > The proper way in my opinion is to not break the hypercalls, if you need > changes in extensions and semantic, create new calls ! It is possible to > make graceful evolution of APIs, otherwise none of the software you are > using right now to read this mail would simply be possible. We guarantee compatibility for *all* our other interfaces. The Xen management API is also being stabilised, but at the XML-RPC level. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |