Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of problem and alternate solutions

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: George Dunlap [mailto:george.dunlap@xxxxxxxxxxxxx]
> Sent: Wednesday, December 19, 2012 6:49 AM
> Subject: Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of 
> problem and alternate
> solutions

George --

Your public personal attacks are hurtful and unprofessional, not to mention
inaccurate.  While I have tried to interpret them is if they are simply
banter or even sarcasm, they border on defamatory.  If we worked for the
same company, I would have already filed a complaint with HR and spoken
bluntly to your manager.

So, now, can we please focus on the technical discussion? **

Let me attempt to briefly summarize your position to see if
I understand it from your last email.  Your position is:

1) Certain existing Xen page allocation mechanisms that occur without
   the knowledge of the toolstack should be permanently disabled,
   regardless of backwards compatibility; and
2) All memory allocations for all future Xen functionality should
   be done only with the express permission of the toolstack; and
3) The toolstack should intelligently and dynamically adjust d->max_pages
   for all domains to match current and predict future memory demand for
   each domain; and
4) It is reasonable to expect and demand that ALL Xen implementations
   and toolstacks must conform to (2) and (3)
As a result, the proposed XENMEM_claim_pages hypercall is not needed.

So, George, you believe that (1) through (4) are the proper way forward
for the Xen community and the hypercall should be rejected.

Is that correct?  If not, please briefly clarify.  And, if it is
correct, I have a number of questions.

Now, George, would you like to attempt to briefly summarize my
position?

Dan

** It is clear to me, and hopefully is to others, that this is not
a discussion about how to fix a bug; it is a discussion about a
fundamental Xen architectural principle, namely where in the Xen
stack should memory be managed and controlled.  Two different Xen
vendors have based product decisions on different assumptions and
opinions colored perhaps in part by the demands of differing customer
bases (i.e. open source guests vs proprietary guests).  The resolution
of this discussion needs to be either: (1) one vendor is "right" and the
other must conform, or (2) both are "right" and the assumptions must
be allowed to co-exist.  I've intentionally added Lars to the cc list
in case this issue should be escalated within xen.org.

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