On 7/13/18 10:48 PM, Greg KH wrote: > On Sat, Jul 14, 2018 at 07:27:55AM +0200, Willy Tarreau wrote: >> Hi Srivatsa, >> >> just a small personal comment below since I'm not the 4.4 maintainer :-) >> >> On Fri, Jul 13, 2018 at 02:49:14PM -0700, Srivatsa S. Bhat wrote: >>> You'll notice that the initial few patches in this series include >>> cleanups etc., that are non-critical to IBPB/IBRS/SSBD. Most of these >>> patches are aimed at getting the cpufeature.h vs cpufeatures.h split >>> into 4.4, since a lot of the subsequent patches update these headers. >>> On my first attempt to backport these patches to 4.4.y, I had actually >>> tried to do all the updates on the cpufeature.h file itself, but it >>> started getting very cumbersome, so I resorted to backporting the >>> cpufeature.h vs cpufeatures.h split and their dependencies as well. >> >> When I used to maintain 2.6.32, initially I tried to backport the minimal >> amount of changes. It quickly resulted in certain files (mostly includes) >> diverging a lot from more recent versions, making it a real pain to later >> backport other fixes. Worse, sometimes I would even not be 100% confident >> in my backports (eg: macros being declared very differently or at multiple >> places which I could easily miss). For 3.10, I stopped doing that and >> instead preferred to pick a bit more "noise" to prepare and adapt the >> files to be patched so that overall the code looked more similar to more >> recent versions. I found that not only it helped with backports, but it >> also reduced the amount of breakage introduced for later backports, and >> it helped with reviews, since what matters is not that the old kernel >> is correct but that the recent one is, and if the code is the same then >> the old one is correct. >> >> Thus based on my experiences with two different methods I guess that I >> had the best approach here. Thank you very much Willy for your feedback and for confirming that backporting a bit more than the minimal changes (when it helps) is the better approach in the long run! > > Yes, taking the "noise" has been found to be better over time. But, for > these patches, I haven't taken that change to 4.9 just yet, and it is > causing a headache for people. Perhaps we should do it there too? I > don't want 4.9 to be the odd-ball kernel where we didn't do it, that > will just cause more problems over time. > >>> I would appreciate if you could kindly consider these patches for >>> review and inclusion in a future 4.4.y release. >> >> However here I notice that your patches were not CCed to their respective >> authors nor to the list of participants, I predict that Greg will ask you >> for this as they're almost the only ones understanding their own tricks ;-) > > Ah, you beat me to it :) > > Yes, you should resend and cc: all of the authors and reviewers, I want > their feedback if at all possible. > Sure, will do! > Normally it's hard to not do that using git send-email, so you had to do > extra work to prevent this from happening... > Well, I used stgit to send these patches, which requires that I specify '--auto' (which I had skipped earlier) in order to CC the patches to the patch signers. Regards, Srivatsa VMware Photon OS
