* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > It's a sane patch and a helps going further, and a total pain to > > re-do later on. Besides, I may have some use for it on powerpc at > > some point too... > > OK, I'll try to reestablish it. > > Look: I can't fix *everyone's* stuff. This was a consequence of > ongoing unbounded churn in the x86 tree. [...] i've reviewed this patchset and the right model appears to me to do this change upstream right now, atomically. It is supposed to be a pure functional NOP, and any deviation from that is easy to spot. Acked-by: Ingo Molnar <mingo@xxxxxxx> I dont think it's particular wise to maintain a change like this across all the arch churn, for months. This patch is a pure cleanup, it could have been merged two months ago. The author should get agreement that it's fine to do it, and if the timing happens to be unfortunate for immediate merging (we are within say 1 month window before stable release) then delay it and redo the cleanup right when it's about to be merged. The worst thing to do is to prolong this for months - it is only unnecessary work for no particular good reason. It complicates -mm merging, keeps an API fork around for no good reason, etc., etc. there's tons of past examples of much larger transformations than this done right: for example the recent irq_regs changes. (and that one wasnt even a pure NOP like this change.) In general, we can pick up the x86 bits of any tree-wide change into x86.git no problem, and then maintain it against all the nuances of x86.git churn. (That requires them to be shaped in a way so that they can be applied to one architecture at a time - which is obviously a good thing anyway - but not always possible, such as in this case where a common API is extended.) If anyone is feeling _any_ serious effects of x86.git churn then please talk to us maintainers and we can work out some technical solution. The only thing we cannot do is to stop 100 active contributors and the flow of 1000 patches until someone finds the time to get tree-wide changes upstream. Roland was able to shape his utrace-enabler regset patches upstream this way, and it is two or three orders of magnitude more complex of a code transformation than the one we are talking about here. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
