On Tue, 13 Nov 2012, Dan Magenheimer wrote: > 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. > That's obvious. > 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. > Sorry, I don't think it's unreasonable at all: if you're going to be using a symbol which was always assumed to be internal to the VM for other purposes and then that usage becomes convoluted with additional usage like in KY's patch, then no VM hacker will ever know what a change to that symbol means outside of the VM. There's been a lot of confusion about why this heuristic is needed outside the VM and whether the symbol is actually the correct choice, so verbosity as to the intent of what it is to represent is helpful for a maintainable kernel. Presumably xen is hijacking that symbol for a similar purpose to KY's purpose, but perhaps I was too optimistic that others would help to solidify the semantics in which it is being used and describe it concisely. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>