From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752079AbdEFRAr (ORCPT ); Sat, 6 May 2017 13:00:47 -0400 Received: from mout.web.de ([212.227.17.11]:61615 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750967AbdEFRAh (ORCPT ); Sat, 6 May 2017 13:00:37 -0400 Subject: Re: GPU-DRM-STI: Fine-tuning for some function implementations To: Sean Paul Cc: dri-devel@lists.freedesktop.org, Benjamin Gaignard , David Airlie , Fabien Dessenne , Vincent Abriou , kernel-janitors@vger.kernel.org, LKML References: <20170505140916.zoe4sxe3xjtvdlag@art_vandelay> <20170506123304.2scgonpvt7kjf4cz@art_vandelay> <77d74ffc-c833-f7ad-b1e2-5e07ac9d23a7@users.sourceforge.net> <20170506152529.7i5zveiob2aaygyl@art_vandelay> From: SF Markus Elfring Message-ID: Date: Sat, 6 May 2017 19:00:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <20170506152529.7i5zveiob2aaygyl@art_vandelay> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:4w3oc9unMSONf1ng3KUB+wsZz76GeI+YqoURPKAHyA4OTsHBgAy soo7I3K+lKtJ0BGo4sS3YxFQ8Xn+IgdvhCxLb+uE+pkn9XhrMGueriEqeVPmus8n8Je6WzD k7mb9tHhlKov4KygcgHsc5U/8njekR2ZZKdv1P3cigmS2yxnX5q51ldNJ+kNFv3Sx4i5sQ9 AqkS4foxx2bcwlcgiaysQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:FRDBBP+XuzE=:cD/ltBnenorm/SxVNYEnFA KCqQ0I/QYGsRO/ukhHfLEfD+sHzE9E2g5oR0b3yPCxY6VB7rh7VSLxpDi/zoo7YB+OFkwxZaS R0EFWm9laIXWZQL/w4tsS0JhHU+sZX6a92xiwkEhM8SLTyQQHtdxNBYG9ouW+zmrM5+lrwUTm kwcaT+748JBpfcsxJVTebj+VIan438jKRRhz8hQAOb5sjAjKFMwWqVDKHsqHqtM3HyJfBYdsP r6svVtCqGAZt2f9lQyMalLE7PzV8o+infkgnMWCzpCZz104bBwKkirIIVQpwlGfsScnqiqxFb goaPa3UlKatjZq2MjOD0DbKZBjYgsli1Cf+1u07TS0X3sJKO6cgusTz6JP6fSlnIlOKllRcay zk/NYxpLnF231TcoCHCBMrwcG7+3K9lzTplRcAEimzmCTfT6uyYGZSiy/ckntrwOv4Jb5jkJr +p2nQizqiUN8i6xr26wm45wDP/wRj0XrwyfyyVaW1rZ3TjK7wg2xVvO/gz31hv9X0veIOjdvX 0H1V8/jCsFZsZesmxDoKCEf2Bqs+FIVmxzXIoNieibVOo9F+Yyc76AmEfKyyOay1cnCuqdWUj gMZC7arQLyxSsIUd4iX52rd+G657LFpk6hjreosCDBVwqEiXZtPgUe0DvFDPi6rOwUcobbHQz r8APGVS6ZMDM7z7If6miVWJqUI6PaJtmsVcaH30MwzGUL9XB/2jOqLAEh+yTB6+WNQBXwL89R s3Yn1Ze2C5rI3YB3hGgt48L4ohvaNpj8cGvAH3bKoVhXPPy61gEtOlipVFSLlmKxzz4iJPZFZ 1Y7PgC3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> 1. I suggest to combine a few functions into fewer ones. >> * Do you spot any programming mistakes in these concrete cases? > > Not in the patches I skimmed. Thanks for such feedback. > However, your history of breaking code tells me that there have been mistakes > missed in the past. I admit that I had my own share of software development hiccups. I would also like to reduce them. But a probability remains that I will stumble on various glitches as usual. > As such, I'm not willing to take untested code from you that does not change > functionality at the risk of breaking something that is currently working. I imagine that the shown software refactoring will improve the affected sequence outputs in useful ways, won't it? > This is non-negotiable. It seems that we have got different views around the ways to get to acceptable final system test results. > As I said before, if you test it, I'll consider it. I got a few doubts for this information. If you find my software development reputation so questionable, I assume that you would not trust any tests that I would try out on my own. > If you are unwilling to test your changes, I'm unwilling to apply them. I guess that the desired willingness will depend on a test environment which will be trusted by all involved parties. Other incentives might also matter. > I'm not interested in double checking all of your work, and fixing your bugs > for no functional benefit. Do you care for improvements in the implementation of logging functions? > I find less value in these patches if they're from someone seemingly > trying to rack up patch count. I am picking special source code search patterns up. The evolving development tools can point then hundreds of source files out which contain similar update candidates. I found also a few spelling weaknesses while I was looking around in affected source code. These tools can also increase the awareness for such change possibilities, can't they? Regards, Markus