On Mon, Aug 28, 2006 at 04:08:00PM +0100, Keir Fraser wrote:
>
>
>
> On 28/8/06 3:58 pm, "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote:
>
> > Is this change going into 3.0.3, or is xen-unstable now reflecting the
> > development for 3.0.4 ? We've got the means to support this new format
> > for hypercalls in libvirt, while keeping compatability for old API
> > (detectable at runtime), but if its not going to 3.0.3 we can postpone
> > this dev work...
>
> 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' ?
> and it is a pain to move patches across branches
> after a fork when only one branch has a major code reorg applied to it. I
> hope you'll agree that the hypercall refactoring has resulted in a cleaner
> interface than the old dom0_ops,
+#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).
This patch is close to 9500 lines long, I am trying to understand what
it contains, some of the HV calls reuse the same ioctl numbers, some have
been moved to two other calls. The structures have changed, some probably
have different size and content but it's hard to tell just by looking at
the patch. It seems that some calls have the same entry point but not the
same data to be passed down, which makes autodetection of the underlying
HV version especially tricky.
Was any HV call removed, or did they were all split between the 3 new sets ?
I will have a lot of work digesting this and making sure libvirt work
with both old and new hypervisors.
> and that it is a useful goal to allow the
> dom0 kernel and tools interfaces to evolve separately from each other.
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.
Yes I guess the change is useful, maybe this was neededi now, but an advance
warning would be nice before commiting something which break binary
compatibility, or at least a mail on xen-devel stating the fact that this
was changed if you really don't want any prior discussion to your commit.
Thanks in advance,
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