[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Tue, 2012-11-27 at 08:48 +0000, Jan Beulich wrote:
> 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).

I agree with this.

> 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 think Oracle carrying this patch in their tree is probably the best
approach for now.

I'm also a little surprised that this patch is being so aggressively
pushed upstream when the toolstack work which would use it is seemingly
not fully formed yet.

Anyway, it seems to me that this argument seems to me to be starting
from the wrong end, it starts from the hypercall and tries to justify it
based on requirements imposed by an toolstack which is presented as
something of a fixed black box from the xen-devel point of view, which
is not something I find particularly convincing.

So a possible alternative to Oracle carrying this patch long term is
that someone who understands Oracle's toolstack's requirements and
constraints takes over from Dan (who I think has said several times that
he is not familiar with all the details of the Oracle toolstack) as
advocate for finding a solution to the underlying issue here and can
engage xen-devel in a discussion about the design decisions involved
from the toolstack downwards. Either this leads to the proposed solution
in the hypervisor (or something similar) or it results in a completely
different solution which everyone is happy with (or I suppose it might
still end up with Oracle carrying this patch long term).

I also feel I should also point out that contrary to the claims in
http://lists.xen.org/archives/html/xen-devel/2012-11/msg01427.html and
elsewhere the acceptance or otherwise of this patch has nothing to do
with Citrix. Although some of the folks involved in the discussion are
employed by Citrix they are all members of the "platform team" which
operates independently, is concerned with the state of Xen.org provided
Xen bits and is not tied to any product team (Citrix or otherwise). So
this has nothing whatsoever to do with Citrix's plans to use this
mechanism (and such conspiracy theories IMHO add nothing to the
discussion). AFAIK no one who is involved with any of Citrix's products
has said anything at all in any thread on the matter one way or the


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.