On Mon, Aug 28, 2006 at 05:32:01PM +0100, Keir Fraser wrote:
> 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
Seriously, which one ? The one about to be deprecated or the one which
doesn't exist yet ? There is in practice no API/ABI here, only the sxp
of xend can be considered a stable ABI so far, but that's slated for removal.
Stable doesn't mean a 6 month time span for us, really.
> 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.
Which I can't use due to Licence issues, they are still GPL if I'm not
mistaken. And anyway they won't even work on 3.0.2 on x86_64 because the
HV ABI broke in the meantime.
> > +#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.
Okay, that mean we will have to work around the changes for the foreseeable
future. You don't care about being stable there, we do, at least now I
complained publicly about it. I have reason why I care for those, we explained
them. I don't know why you don't want to garantee anything at that level.
I know that non stable kernel interfaces can change, that's a fact of life,
but things can be handled gracefully and nicely, it's also possible to be
uncooperative on purpose, I hope it is not the case.
> 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).
Okay
> > 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.
Okay thanks, it's not easy to track down because that was dispatched on
multiple files now.
> > 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.
And the level of CPU consumption used just for monitoring was not
acceptable last we checked, only the hypercalls allowed decent
performances.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home