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. 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. Normally it's hard to not do that using git send-email, so you had to do extra work to prevent this from happening... thanks, greg k-h
