[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.