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

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



> From: Keir Fraser [mailto:keir@xxxxxxx]
> Subject: Re: [Xen-devel] Please ack XENMEM_claim_pages hypercall?
> 
> On 27/11/2012 08:48, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
> > 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.
> >
> > 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).
> >
> > 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).
> 
> It's actually not that large a patch, and perhaps we could take a
> domain_adjust_tot_pages() hook which would reduce the size of any private
> patch, while not inflicting a maintenance or bug burden on mainline.

Thanks for your kind words.  That would be very helpful.
Also reserving the subops would be much more valuable.

Thanks,
Dan

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