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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

> 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.

I think this argument could be made either way. At the moment we might
as well git rm tools/ocaml/libs/xl for 4.4 because it is of basically no
use as it stands.

As Dave says there are also users of xapi/xenopsd outside of XenServer. 

It's unfortunate that the ocaml namespacing rules don't allow you to
easily ship a library of functions which extend an existing interface in
a compatible way (like e.g. libnih or the BSD linux compat lib), such
that you can just cut in the real functionality once it hits. 

> 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.

For this specific series I don't think we need to slip the window for
it, either it works, good, or it doesn't work, bad, but effectively no
worse than where we are today.

Ian.


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