On Sat, Dec 23, 2017 at 08:12:21AM +0100, SF Markus Elfring wrote: > >> Do you find the Linux allocation failure report insufficient in this case? > > > > Leave those pr_ messages alone, please, > > Have you got special software development concerns? > > > > unless they are really causing some sort of issue (which?). > > Can the code be redundant here? > > > > Doing it just for "compliance" with a doc isn't nearly good enough reason. > > Do you give only a low value to coding style guidelines in this use case? Hi Markus, Thanks for submitting the patch. I understand it can be frustrating to encounter different policies across kernel maintainers. You'll even run in to this with maintainers of the same subsystem from time to time. While we try to be as consistent as possible, and to document policy as we resolve vague areas, this is unfortunately still part of kernel development. I'm supportive of cleaning up old code in general, and we routinely apply such patches as these developed with cocci. We have also had them fail in unexpected ways. Andy and Henrique raised a few reasons why these patches should not be accepted: 1. This is init code )so any space savings is short lived) 2. There is no functional fix, and the change is to code which supports a lot of unique platforms, most of which we have no way to test. We are particularly cautious with drivers such as the thinkpad driver for this reason. So it isn't that we place a low value on coding style guidelines, but rather we place higher value on not perturbing code we can't fully test without a demonstrable functional reasons to do so. Thanks, -- Darren Hart VMware Open Source Technology Center ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
