On Mon, Aug 28, 2006 at 05:48:56PM +0100, Ian Pratt 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' ?
>
> We were only thinking in terms of the internal consistency of the tree
> and the public APIs and libraries -- I didn't realise libvirt was going
> directly at the dom0_op ABI rather than using the libxenguest or
> libxenctrl libraries.
The problem is that considering the state of a snapshot at one point in
time is not sufficient. You cannot assume everything will be upgraded as
one shot and restarted clean. There isn't any reason a Dom0 kernel and the
hypervisor should not run for years even if the DomU and userland Dom0
are upgraded independantly to cover bug fixes and so on. We all understand
it is not the kind of garantee that you feel okay to provide, that's
normal and fine, but we need to cooperate to ultimately provide this
level of garantee to users. If I were using a libxenctrl library from
beginning of July libvirt would have stopped working for everybody mid-July
and if linking against a library from 3 weeks ago, with changeset 86d26e6ec89b
this would break again. We really want to get the xen bits tested, we
(especially Juan) are working hard to get early testing, but if the whole
stack breaks down (libvirt failing means the guest installer fails) too
often, this takes a lot of effort from us, and this turns off the early
testers. This is a loosing situation. I do understand your statement of
not willing to guarantee HV call stability, because technically things
will have to evolve for example as part of getting in the upstream Linux
kernel, some things certainly will change, I'm fine with it, but I'm not
happy with unilateral changes which are not discuted or at least announced.
I'm firmly convinced this reduces early testing and generate more error
than we should see if thing were planned and introduced smoothly.
> If your reason for doing this was just the GPL'ness of the libraries
> then I assume you'd support the email I posted a few weeks ago
> suggesting we try to change the library license to LGPL? Would you then
> start using the libraries?
That would be a step in the right direction, I would still need to copy
some of this code instead of rewriting it when there are change, since as
Daniel Berrange pointed out too, we need the stack to work for a longuer
timeframe, which means detecting the HV version and using the right code.
That would reduce the work needed when the hypervisor call changes but
I won't be able to use it as-is.
What is sad is that changeset 86d26e6ec89b is also a step in the right
direction, it's just the way update to this very sensible part happened
which generated troubles, it's also annoying that it won't solve the problem
for people on ppc64, maybe this could have been fixed if that had been
worked on the xen-devel list for some time. Obviously this change is not
new, that 9500 line patch certainly tooks some time to make, is there
anything preventing discussion about it ? Is that just lack of time ?
This kind of changes is not the average addition of a new feature, it
highly affects perceived stability for every testers, and I hope that by
discussing those in advance we could improve the speed of development,
testing and ease deployments.
Yours,
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