[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |