[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 00/11] libxl: ocaml: improve the bindings
> On Tue, Dec 10, 2013 at 4:00 PM, George Dunlap > <George.Dunlap@xxxxxxxxxxxxx> wrote: > > On Tue, Dec 10, 2013 at 3:48 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> > wrote: > >> On Tue, 2013-12-10 at 14:10 +0000, George Dunlap wrote: > >>> On 12/10/2013 01:20 PM, Ian Campbell wrote: > >>> > On Mon, 2013-12-09 at 15:17 +0000, Rob Hoes wrote: > >>> >> This series contains version 6 of the remaining patches to fix > >>> >> the OCaml bindings to libxl. > >>> >> > >>> >> The main change compared to version 5 is that we now properly > >>> >> register the "user" values (OCaml values that are given to the > >>> >> libxl event system, and returned to OCaml in callbacks) with the > OCaml GC. > >>> > So the release process has moved on sufficiently that I think we > >>> > need to consider whether the previous release-ack still stands: > >>> > http://thread.gmane.org/gmane.comp.emulators.xen.devel/180254/focu > >>> > s=180383 > >>> > > >>> > I think the arguments made there still stand, in short it would be > >>> > awesome if xapi could move to using libxl on top of 4.4 and the > >>> > risks are almost entirely contained within this use case, which > >>> > cannot be satisfied by the code as it stands today. > >>> > >>> Except that that basically calls into question what a "code freeze" > >>> is at all. At some point we just need to say, "No more, this is > >>> what we have; from now on we work on bug fixes." > >>> > >>> We've decided that PVH dom0 and ARM "physical address space leak" > >>> fixes are blockers for strategic reasons. Is there a good reason > >>> that we should consider updated OCaml bindings in the same light? > >> > >> I think strategic reasons is a good way to put it. Our strategy over > >> the last several releases has been to move toolstack consumers of Xen > >> over to the libxl APIs instead of libxc and locally coded stuff. > >> We're doing pretty well on that from with xl/xm and libvirt and xapi > >> is the final major consumer of the old interfaces. > > > > When I say "strategic" in this case, I mean something in the timing > > (why have it in this release rather than 4.5) that will have an impact > > on Xen's place in the open-source ecosystem as a whole. xapi's place > > in distros is certainly time-critical and important to the success of > > an important contributor to Xen; and the potential for negative impact > > is certainly small. > > > > In any case, there seems to be a strong consensus, so: > > > > Release-acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx> > > But I should emphasize, time is of the essence here. I can't imagine us > taking this after Christmas; and it sounds like there may be yet a few > more iterations to go. So if you guys want this in, this needs to be a > priority. Thanks for the ack, George. I think indeed it is important to get this into Xen 4.4, especially for the reasons related to distros that were mentioned. I have just sent out an update containing some minor changes that were discussed today. Cheers, Rob _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |