Hi Julia On Fri, Oct 25, 2019 at 5:38 PM Julia Lawall <julia.lawall@xxxxxxx> wrote: > > > > On Fri, 25 Oct 2019, Andy Shevchenko wrote: > > > On Fri, Oct 25, 2019 at 12:40:52AM +0900, Masahiro Yamada wrote: > > > On Sun, Oct 20, 2019 at 7:13 AM Joe Perches <joe@xxxxxxxxxxx> wrote: > > > > On Sat, 2019-10-19 at 21:43 +0100, Marc Zyngier wrote: > > > > > Alexandre Belloni used > > > https://lore.kernel.org/lkml/9bbcce19c777583815c92ce3c2ff2586@xxxxxxxxxxx/ > > > as a reference, but this is not the output from coccicheck. > > > The patch author just created a wrong patch by hand. > > > > Exactly. Removal of the script is a mistake. Like I said before is a healing > > (incorrect by the way!) by symptoms. > > > > > The deleted semantic patch supports MODE=patch, > > > which creates a correct patch, and is useful. > > > > Right! > > I ran it on the version of Linux that still has the script: > > fe7d2c23d748e4206f4bef9330d0dff9abed7411 > > and managed to compile 341 of the generated files in the time I had > available, and all compiled successfully. Yeah, this semantic patch did the correct conversion as its header part showed the confidence. // Confidence: High > I can let it run again, and see > how it goes for the rest. Perhaps it would be acceptable if there was no > report, and people would be forced to use the generated patch? I do not think this is the right thing. MODE=report is the default, and it is fine. > > If someone is writing lots of patches on this issue by hand, then perhaps > they don't have make coccicheck to produce patches, and then would > overlook this case completely. > > If it would be helpful, I could group the generated patches by maintainer > or by subdirectory and send them out, if it would be easier to review them > all at once. Yes, please. Subsystem maintainers trust you, so I think it will make things move smoothly. After converting most of files, I want 283ea345934d277e30c841c577e0e2142b4bfcae reverted. > > Anyway, the rule is not in the kernel at the moment. For it's future, I'm > open to whatever people find best. Personally, I prefer when same things > are done in the same way - it makes the code easier to understand and > makes it simpler to address other issues when they arise. We always did the same things in the same way except commit 283ea345934d277e30c841c577e0e2142b4bfcae -- Best Regards Masahiro Yamada
