lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 23 Feb 2024 11:42:35 -0800
From: Luis Chamberlain <mcgrof@...nel.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Mukesh Ojha <quic_mojha@...cinc.com>, russ.weight@...ux.dev,
	rafael@...nel.org, linux-kernel@...r.kernel.org,
	cocci@...teme.lip6.fr
Subject: Re: [PATCH vRFC 3/8] treewide: rename firmware_request_platform()

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?

> > > Yes, we mess this up a lot, but keeping the namespace this way works out
> > > better for global symbols, so "firmware_*" is best please.
> > 
> > We should certainly stick to *one* pattern, for the better, and it
> > occurs to me we could further review this with a coccinelle python
> > script for public functions, checking the first two elements of a public
> > function for noun and verb.
> 
> Changing the existing function names for no real reason isn't probably a
> good idea, nor worth it.  The firmware_* function prefix is good, let's
> keep it please.
> 
> If you really wanted to be picky, we should make them part of a module
> namespace too :)

Sticking to *any* convention is good, so longa as we decide on one, it
used to be hard to have tidy rules to do this sort of stuff but with
coccinelle we should be able to grow these rules and ensure we stick
to it for the good for new stuff.

  Luis

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ