Re: [Xen-devel] [PATCH v6 00/11] libxl: ocaml: improve the bindings

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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/focus=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.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel