[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] 3.0.3 freeze
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |