From mboxrd@z Thu Jan 1 00:00:00 1970 From: SF Markus Elfring Date: Sun, 03 Dec 2017 18:20:47 +0000 Subject: Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions Message-Id: <21554e23-e714-3f6f-cd70-4c277823bab3@users.sourceforge.net> List-Id: References: <1511809633.32426.70.camel@perches.com> <1511833514.32426.86.camel@perches.com> <7e7e64cf-dbe5-614a-f1e5-29d7b6cf9297@users.sourceforge.net> <1511856244.19952.14.camel@perches.com> In-Reply-To: <1511856244.19952.14.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Joe Perches , linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org Cc: "Andrew F. Davis" , Arvind Yadav , Bartlomiej Zolnierkiewicz , LKML , kernel-janitors@vger.kernel.org, Ladislav Michl , Tomi Valkeinen > How many times have I told you to include the reason for your patches > in your proposed commit message? Will it be useful to look again at the involved circumstances? > Too often. Did I answer any concerns partly? > Many people do not know that a generic kmalloc does a dump_stack() on OOM. Do you see a need to represent such information better? Is it expected that the function “devm_kzalloc” has got a similar property? > That information should be part of the commit message. How do you think about to share it also from any reference documentation in a clearer way? Do we stumble on a target conflict in this case? I am generally trying to improve the software situation to some degree. I prefer then to work with safe information sources. Unfortunately, I might have not reached a desired confidence level here for a more detailed commit message. I assume that software development efforts could increase in significant ways if something should be improved further in a direction I hope. But this could mean that time frames will grow for corresponding clarifications. * Does such a situation block progress on the deletion of other remaining questionable error messages? * Would you like to increase the software development attention anyhow? By the way: It seems that my update suggestion for the directory “omapfb/dss” could be superseded by the patch “omapfb: dss: Do not duplicate features data” from Ladislav Michl. https://patchwork.kernel.org/patch/10082027/ https://lkml.kernel.org/r/<20171129123308.GA26578@lenoch> Regards, Markus