public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Deepak R Varma <drv@mailo.com>
Cc: James Bottomley <jejb@linux.ibm.com>,
	Khalid Aziz <khalid@gonehiking.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Saurabh Singh Sengar <ssengar@microsoft.com>,
	Praveen Kumar <kumarpraveen@linux.microsoft.com>
Subject: Re: [PATCH] scsi: FlashPoint: Replace arithmetic addition by bitwise OR
Date: Tue, 07 Feb 2023 15:19:52 -0500	[thread overview]
Message-ID: <yq17cwt2s0r.fsf@ca-mkp.ca.oracle.com> (raw)
In-Reply-To: <Y+KOeP0OOiem3lR5@ubun2204.myguest.virtualbox.org> (Deepak R. Varma's message of "Tue, 7 Feb 2023 23:16:32 +0530")


Hi Deepak!

> James, there are a few other patch submissions for the scsi subsystem
> that I submitted in last few weeks. I sent couple of reminder request
> for comments on those submission, but still waiting. Could you please
> also review those and share your feedback?

I only merge cleanup patches if the relevant driver maintainer reviews
and acks them. And there needs to be sufficient justification, of
course.

As an example I will observe that your sysfs patches say:

"According to Documentation/filesystems/sysfs.rst, the show() callback
function of kobject attributes should strictly use sysfs_emit() instead
of sprintf() family functions."

That's a "should", not a "shall". IOW, a recommendation. Also, there is
no "strictly" requirement to be found in sysfs.rst. So the patch
justification is lacking.

We definitely use sysfs_emit() for new code. But it is not clear that
there is any value in changing old code predating sysfs_emit() to comply
with a mere recommendation. It's just additional work and comes with a
substantial risk of introducing regressions since virtually no cleanup
patches have actually been tested on the relevant hardware.

Nobody has access to all the devices required to validate the many, many
drivers we have in SCSI. So unless the driver maintainer (who presumably
has hardware) is willing to test, it is impossible for me to qualify
whether a patch introduces a regression.

One option is demonstrating that the patch does not change the generated
object code as James suggested. But even if the binary is unchanged,
cleanups often involve stylistic changes or switching to a more "modern"
approach. And for those changes I still want the driver maintainer to
ack. It's their driver.

To pick another example from your posted patches, it not immediately
obvious that using min() is superior to an if-else statement. Sometimes
it is clearer to express things as a conditional even though it takes up
more vertical space (or maybe because it does?). In any case that's a
personal preference and the driver maintainer's choice.

Hope that helps!

-- 
Martin K. Petersen	Oracle Linux Engineering

  parent reply	other threads:[~2023-02-07 20:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07 11:21 [PATCH] scsi: FlashPoint: Replace arithmetic addition by bitwise OR Deepak R Varma
2023-02-07 12:26 ` James Bottomley
2023-02-07 15:28   ` Khalid Aziz
2023-02-07 17:48     ` Deepak R Varma
2023-02-07 17:46   ` Deepak R Varma
2023-02-07 19:25     ` James Bottomley
2023-02-07 20:19     ` Martin K. Petersen [this message]
2023-02-09  7:32       ` Deepak R Varma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yq17cwt2s0r.fsf@ca-mkp.ca.oracle.com \
    --to=martin.petersen@oracle.com \
    --cc=drv@mailo.com \
    --cc=jejb@linux.ibm.com \
    --cc=khalid@gonehiking.org \
    --cc=kumarpraveen@linux.microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=ssengar@microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox