On Sun, Feb 25, 2018 at 11:56:17AM +0000, Dibyendu Majumdar wrote: > Hi Luc, > > On 25 February 2018 at 09:25, Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: > > The right and wise thing would have to: > > 1) take the 2 patches that Jason is waiting for since 5 months > > (if you agree with). > > 2) take Randy's patch with the early return NULL > > 3) take Randy's patch to silence the indirect_branch attribute > > 4) take my patch to disable the default -Wunknown-attribute > > 5) inc the version number > > 6) push a release so that people stop seeing the current > > 148K+ warnings about the unknown indirect_branch attribute. > > > > But people are still waiting and seeing these 148K+ useless > > warnings and you have forced in a patch which: > > I am not sure why above is the 'right thing'. There does not appear to > be a definition or process to identify fixes or changes that people > need urgently - and if I recall correctly you previously objected to > having such a process when I suggested it. I don't remember we ever had a discussion about this. It's true though, that I don't believe in very strict procedures (though, I'm sure they are very good things in a lot of situations). I think we must adapt our decisions to the reality with all its complexity and unpredictability. > > 1) I explained to you why it was wrong > > Is it wrong because you disagree with it? I don't see a problem with > the approach. I tested your approach of OP_PUSH as well - and in my > view after comparing the two, this is more correct as it avoids > creating a pseudo IR instruction. It's true that the OP_PUSH solution adds more IR instructions. This doesn't make it incorrect. More importantly, it doesn't make the pseudo-size solution automatically correct. It's orthogonal to the correctness aspect. The technical aspects have been discussed endlessly between March and November, at which point I said that I was quite tired about it all and that I won't discuss about it anymore. During these months I explained several times: 1) that I tried the pseudo-size approach, even before Linus suggested the OP_ARG/OP_PUSH approach, and that I abandoned it because I saw several problems with it. 2) I explained (some of) the cause(s) of these problems 3) I said that I still think that *at term* the pseudo-size approach will probably be the right one but that *currently* it wasn't acceptable because of 2) 4) I also said that, even discarding the points here above, I was worried about how invasive Chris patch was and I warned him about its testing. In my tree, I didn't opted for the OP_PUSH solution but something totally different, maybe not ideal, admittingly a bit ugly but very direct, with very limited impact. Of course, the OP_PUSH solution and my current solution were both well tested and their impact well understood. This is definitively not something that can be said about what Chris put in the official tree. So, no, it's definitively not because 'I don't like' the pseudo-size solution and that I 'prefer' the OP_PUSH one. It's about making appropriate engineering choices. The elements are there, the code can be compared, the code can be tested. People can read the code and understand it, they can think by themselves and make their own choices. -- Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
