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

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