From: David Scott <dave.scott@eu.citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Rob Hoes <rob.hoes@citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v6 00/11] libxl: ocaml: improve the bindings
Date: Tue, 10 Dec 2013 15:48:16 +0000 [thread overview]
Message-ID: <52A737C0.4010701@eu.citrix.com> (raw)
In-Reply-To: <CAFLBxZZU3J8mKBAtnfzKmGv+j5PkuKRkanQQL_s2RtE-XNNkdw@mail.gmail.com>
On 10/12/13 15:42, George Dunlap wrote:
> On Tue, Dec 10, 2013 at 2:34 PM, David Scott <dave.scott@eu.citrix.com> wrote:
>> On 10/12/13 14:10, George Dunlap wrote:
>>>
>>> On 12/10/2013 01:20 PM, Ian Campbell wrote:
>>>> 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:
>
> Not exactly. ;-)
>
>> 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 ;-)
>
> Right -- so you are arguing that there is in fact a strategic reason
> to get this into 4.4: you want xapi to be able to be easy to package
> and install into distros, and having broken ocaml bindings is a major
> blocker for that. xapi packages for distros are already in a pretty
> dire state, and not having support until 4.5 could be disastrous.
>
> Would you agree with that assessment?
Yes, I think that's fair.
Thanks,
Dave
next prev parent reply other threads:[~2013-12-10 15:48 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-09 15:17 [PATCH v6 00/11] libxl: ocaml: improve the bindings Rob Hoes
2013-12-09 15:17 ` [PATCH v6 01/11] libxl: ocaml: add simple test case for xentoollog Rob Hoes
2013-12-09 15:17 ` [PATCH v6 02/11] libxl: ocaml: implement some simple tests Rob Hoes
2013-12-09 15:17 ` [PATCH v6 03/11] libxl: ocaml: event management Rob Hoes
2013-12-10 13:48 ` Ian Campbell
2013-12-10 15:48 ` Rob Hoes
2013-12-10 16:00 ` Ian Campbell
2013-12-10 16:46 ` Rob Hoes
2013-12-10 16:12 ` David Scott
2013-12-09 15:17 ` [PATCH v6 04/11] libxl: ocaml: allow device operations to be called asynchronously Rob Hoes
2013-12-10 13:25 ` Ian Campbell
2013-12-10 13:28 ` Ian Campbell
2013-12-10 14:47 ` Rob Hoes
2013-12-09 15:17 ` [PATCH v6 05/11] libxl: ocaml: add disk and cdrom helper functions Rob Hoes
2013-12-09 15:17 ` [PATCH v6 06/11] libxl: ocaml: add VM lifecycle operations Rob Hoes
2013-12-10 13:29 ` Ian Campbell
2013-12-10 16:13 ` David Scott
2013-12-09 15:17 ` [PATCH v6 07/11] libxl: ocaml: add console reader functions Rob Hoes
2013-12-09 15:17 ` [PATCH v6 08/11] libxl: ocaml: drop the ocaml heap lock before calling into libxl Rob Hoes
2013-12-10 13:34 ` Ian Campbell
2013-12-10 14:51 ` Rob Hoes
2013-12-10 16:01 ` Ian Campbell
2013-12-10 16:13 ` Rob Hoes
2013-12-09 15:17 ` [PATCH v6 09/11] libxl: ocaml: add some missing CAML macros Rob Hoes
2013-12-09 15:17 ` [PATCH v6 10/11] libxl: ocaml: fix memory corruption when converting string and key/values lists Rob Hoes
2013-12-09 15:17 ` [PATCH v6 11/11] libxl: ocaml: remove dead code in xentoollog bindings Rob Hoes
2013-12-10 11:24 ` [PATCH v6 00/11] libxl: ocaml: improve the bindings Rob Hoes
2013-12-10 13:20 ` Ian Campbell
2013-12-10 13:25 ` Andrew Cooper
2013-12-10 13:42 ` Ian Campbell
2013-12-10 14:10 ` George Dunlap
2013-12-10 14:24 ` George Dunlap
2013-12-10 14:34 ` David Scott
2013-12-10 15:42 ` George Dunlap
2013-12-10 15:48 ` David Scott [this message]
2013-12-10 15:48 ` Ian Campbell
2013-12-10 15:53 ` Ian Jackson
2013-12-10 16:00 ` George Dunlap
2013-12-10 16:57 ` George Dunlap
2013-12-10 17:01 ` Rob Hoes
2013-12-10 15:50 ` Ian Jackson
2013-12-10 15:57 ` George Dunlap
2013-12-10 16:04 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52A737C0.4010701@eu.citrix.com \
--to=dave.scott@eu.citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=rob.hoes@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.