> From: KY Srinivasan [mailto:kys@xxxxxxxxxxxxx] > Subject: RE: [PATCH 1/1] mm: Export a function to read vm_committed_as > > > From: David Rientjes [mailto:rientjes@xxxxxxxxxx] > > Sent: Monday, November 12, 2012 6:49 PM > > To: Dan Magenheimer > > Cc: KY Srinivasan; Konrad Wilk; gregkh@xxxxxxxxxxxxxxxxxxx; linux- > > kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx; > > apw@xxxxxxxxxxxxx; andi@xxxxxxxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; linux- > > mm@xxxxxxxxx; kamezawa.hiroyuki@xxxxxxxxx; mhocko@xxxxxxx; > > hannes@xxxxxxxxxxx; yinghan@xxxxxxxxxx > > Subject: RE: [PATCH 1/1] mm: Export a function to read vm_committed_as > > > > On Mon, 12 Nov 2012, Dan Magenheimer wrote: > > > > > > > Why? Is xen using it for a different inference? > > > > > > > > I think it is good to separate these patches. Dan (copied here) wrote the code > > for the > > > > Xen self balloon driver. If it is ok with him I can submit the patch for Xen as > > well. > > > > > > Hi KY -- > > > > > > If I understand correctly, this would be only a cosmetic (function renaming) > > change > > > to the Xen selfballooning code. If so, then I will be happy to Ack when I > > > see the patch. However, Konrad (konrad.wilk@xxxxxxxxxx) is the maintainer > > > for all Xen code so you should ask him... and (from previous painful experience) > > > it can be difficult to sync even very simple interdependent changes going > > through > > > different maintainers without breaking linux-next. So I can't offer any > > > help with that process, only commiseration. :-( > > > > > > > I think this should be done in the same patch as the function getting > > introduced with a cc to Konrad and routed through -mm; even better, > > perhaps he'll have some useful comments for how this is used for xen that > > can be included for context. > > > Ok; I will send out a single patch. I am hoping this can be applied soon as Hyper-V balloon > driver is queued behind this. > > Regards, > K. Y David -- Having caught up on the thread now, I'm a bit confused about your requirement for KY to patch the Xen selfballooning code. The data item we are talking about here, committed_as, is defined by a kernel<->userland ABI, visible to userland via /proc/meminfo. The Xen selfballoon driver accesses it within the kernel as a built-in; this driver could potentially be loaded as a module but currently cannot. KY is simply asking that the data item be exported so that he can use it from a new module. No change to the Xen selfballoon driver is necessary right now and requiring one only gets in the way of the patch. At some future time, the Xen selfballoon driver can, at its leisure, switch to use the new exported function but need not unless/until it is capable of being loaded as a module. And, IIUC, you are asking that KY's proposed new function include a comment about how it is used by Xen? How many kernel globals/functions document at their point of declaration the intent of all the in-kernel users that use/call them? That seems a bit unreasonable. There is a very long explanatory comment at the beginning of the Xen selfballoon driver code already. So I will ack KY's patch (I see it was just sent) but will leave it up to Konrad and GregKH and Andrew to decide whether to include the fragment patching the Xen selfballoon driver. Dan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
