All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Mukesh Ojha <quic_mojha@quicinc.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	russ.weight@linux.dev, rafael@kernel.org,
	linux-kernel@vger.kernel.org, cocci@systeme.lip6.fr
Subject: Re: [PATCH vRFC 3/8] treewide: rename firmware_request_platform()
Date: Mon, 26 Feb 2024 08:06:12 -0800	[thread overview]
Message-ID: <Zdy29AwHwjne8aq_@bombadil.infradead.org> (raw)
In-Reply-To: <f142baba-619c-940c-9ceb-7c0d9c8ca7dc@quicinc.com>

On Mon, Feb 26, 2024 at 06:52:49PM +0530, Mukesh Ojha wrote:
> 
> 
> On 2/26/2024 6:39 PM, Greg KH wrote:
> > On Mon, Feb 26, 2024 at 04:22:09PM +0530, Mukesh Ojha wrote:
> > > 
> > > 
> > > On 2/24/2024 11:06 AM, Greg KH wrote:
> > > > On Fri, Feb 23, 2024 at 11:42:35AM -0800, Luis Chamberlain wrote:
> > > > > On Fri, Feb 23, 2024 at 04:33:40PM +0100, Greg KH wrote:
> > > > > > On Fri, Feb 23, 2024 at 07:15:45AM -0800, Luis Chamberlain wrote:
> > > > > > > On Fri, Feb 23, 2024 at 07:21:31AM +0100, Greg KH wrote:
> > > > > > > > On Thu, Feb 22, 2024 at 11:30:28PM +0530, Mukesh Ojha wrote:
> > > > > > > > > Rename firmware_request_platform() to request_firmware_platform()
> > > > > > > > > to be more concrete and align with the name of other request
> > > > > > > > > firmware family functions.
> > > > > > > > 
> > > > > > > > Sorry, but no, it should be "noun_verb" for public functions.
> > > > > > > 
> > > > > > > News to me, do we have this documented somewhere?
> > > > > > 
> > > > > > Not really, but searching makes it nicer.
> > > > > > 
> > > > > > And yes, I violated this in the past in places, and have regretted it...
> > > > > 
> > > > > Care to share a few examples of regret?
> > > > 
> > > > 	get_device()
> > > > 	put_device()
> > > > 	kill_device()
> > > > 
> > > > vs. a saner:
> > > > 	kobject_get()
> > > > 	kobject_put()
> > > > 	kobject_del()
> > > > 
> > > > Learn from the mistakes of my youth please :)
> > > 
> > > Thanks for the history.,
> > > In that case, should we fix this verb_noun cases ?
> > > 
> > > request_firmware()
> > > request_firmware_into_buf()
> > > request_firmware_nowarn()
> > > request_firmware_direct()
> > > request_firmware_cache()
> > > request_partial_firmware_into_buf()
> > > release_firmware()
> > 
> > That would provide consistency, right?
> 
> Yes, Below names look better..
> 
> firmware_request()
> firmware_request_into_buf()
> firmware_request_nowarn()
> firmware_request_direct()
> firmware_request_cache()
> firmware_request_partial_into_buf()
> firmware_release()
> 
> @Luis/Others, Can we do this change ?

Go for it. I just also think we might as well document from the learnt
lessons, and our preference, instead of making this just one developer's
personal preference because the moon made them feel a different way than
two years ago. From my part it is best we *strive* to stick to one
convention, whatever it is. As for the *why* to document this, I suspect
it allows easier namespace grep'ing for symbols related to one thing or
another, as to why it shoudl go first, I'll let Greg chime in.

Long term I see value in having anything we decide to stick to, to make it
easier for debugging heuristics.

  Luis

  reply	other threads:[~2024-02-26 16:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-22 18:00 [PATCH vRFC 0/8] Refactor and rename request firmware API Mukesh Ojha
2024-02-22 18:00 ` [PATCH vRFC 1/8] firmware_loader: Refactor request firmware lower level functions Mukesh Ojha
2024-02-22 18:00 ` [PATCH vRFC 2/8] treewide: rename firmware_request_nowarn() Mukesh Ojha
2024-02-22 18:00 ` [PATCH vRFC 3/8] treewide: rename firmware_request_platform() Mukesh Ojha
2024-02-23  6:21   ` Greg KH
2024-02-23 15:15     ` Luis Chamberlain
2024-02-23 15:33       ` Greg KH
2024-02-23 19:42         ` Luis Chamberlain
2024-02-24  5:36           ` Greg KH
2024-02-26 10:52             ` Mukesh Ojha
2024-02-26 13:09               ` Greg KH
2024-02-26 13:22                 ` Mukesh Ojha
2024-02-26 16:06                   ` Luis Chamberlain [this message]
2024-02-22 18:00 ` [PATCH vRFC 4/8] treewide: rename firmware_request_cache() Mukesh Ojha
2024-02-22 18:00 ` [PATCH vRFC 5/8] firmware: Convert minor inline function to macro Mukesh Ojha
2024-02-23  6:22   ` Greg KH
2024-02-22 18:00 ` [PATCH vRFC 6/8] firmware: Move module template to the bottom Mukesh Ojha
2024-02-22 18:00 ` [PATCH vRFC 7/8] firmware: remove prototype of fw_cache_piggyback_on_request() Mukesh Ojha
2024-02-22 18:00 ` [PATCH vRFC 8/8] firmware: FW_OPT_UEVENT for all request_firmware family functions Mukesh Ojha

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=Zdy29AwHwjne8aq_@bombadil.infradead.org \
    --to=mcgrof@kernel.org \
    --cc=cocci@systeme.lip6.fr \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_mojha@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=russ.weight@linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.