Re: [Xen-devel] Please ack XENMEM_claim_pages hypercall?

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Subject: Re: Please ack XENMEM_claim_pages hypercall?

Hi Jan --

> >>> On 26.11.12 at 20:07, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
> > While it has always been my understanding that the
> > hypervisor is intended to be toolstack-independent,
> > Jan would like your Ack before committing the hypervisor
> > changes.
> >
> > So if you still object, please state your objections.
> > Otherwise, please ack, so Jan can commit it and Oracle
> > can move forward with toolstack development built
> > on the hypercall.
> 
> Sorry, there must have been some misunderstanding here: First
> of all, without a maintainer's ack (Keir's in this case) I can't commit
> anything to code that I'm not explicitly listed for as maintainer.

Oops, sorry.  Since you contribute so widely to the hypervisor,
the maintainership division between you and Keir is not particularly 
clear.
 
> Second, while I said the code itself looks acceptable, I also pointed
> out that in the shape it is right now it is dead code, as there's no
> user for it. So all we would get would be the risk of new bugs (and
> the one I just pointed out worries me in so far as how much testing
> this code really has seen).

The proposed hypercall is dead code to the _xl_ toolstack.
As I said, I personally can write an xm/xend patch that uses it
(which will undoubtedly launch another firestorm, so I was
trying to avoid that).

But most importantly, many of the code changes _will_ be
tested without any toolstack changes at all, as the existing
toolstack (with no claim hypercalls) exercises the changes.
Perhaps this is the most important testing of all and,
as I understand it, is a primary purpose of xen-unstable.

I do agree though that it is difficult to get adequate testing
without a toolstack user.  I, too, would like to see that fixed. :-(

> Third, deferral (or denial) of the patch going in is certainly not a
> blocking factor for tools side development at Oracle. In the worst
> case, you'd have to maintain the patch in your own tree(s); I do
> realize that you want to avoid that (as I would, but there are
> examples of patches that we carry in our trees that didn't get
> accepted into the community one - luckily they're of smaller size).

I guess I've failed to make a very important point because
I thought it was obvious... Because of the addition of the
hypercall subops, this is an ABI change.  I think you would
agree that maintaining an ABI change out-of-tree is much
more difficult than maintaining non-ABI changes out-of-tree.

If the hypercall subops are reserved, whether the remainder
of the patch is accepted now or not, that might be a
reasonable compromise to Oracle.

Thanks,
Dan

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