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

[David Scott <dave.scott@eu.citrix.com>]

On 10/12/13 14:10, 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?
>
> At this point, the fact that there is only one downstream user
> (XenServer) is an argument *against* its inclusion: there is very little
> benefit, as XS can simply carry the patches if they want to.

A nit-pick: the downstream user is really 'xenopsd', part of the xapi 
project. The xapi/xenopsd code is in XenServer and, increasingly, 
available for other Linux distros (we're trying to do the right thing 
and make the code easy to package). XenServer could easily carry some 
patches, but the other distros probably won't. The only workarounds to 
keep xapi/xenopsd working on non-XenServer distros that I can think of 
are (i) not using libxl at all [a shame, obviously]; or (ii) depending 
on a fresh package, 'libxl-ocaml-bindings-fixed' which would be a fork 
of the in-tree code with the fixes applied and named 'xenlight2' [ugly, 
not totally sure if it's even possible]. It seems odd to me to decide to 
ship code which the only user can't actually use ;-)

Cheers,
Dave

>
> The timeframe in which we did this kind of "cost/benefits" analysis for
> new features was meant to have passed already -- the "grace period" has
> already been three weeks; the schedule for the code freeze has been
> published and hasn't changed in 6 weeks.
>
> While I can certainly understand the feeling of "just having missed"
> when it might have been accepted, given the number of people working on
> Xen now, I think we are almost always going to be in that situation.  We
> can either keep slipping the window until we happen to get lucky enough
> not to have any "really nice" features to add in, or we can set a hard
> deadline and say, "Sorry, that will have to wait."  Feel free to make a
> case for the first, but at the moment the second seems like the only way
> to proceed to me.
>
>   -George