kernel-janitors.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-kernel-mentees@lists.linuxfoundation.org,
	LKML <linux-kernel@vger.kernel.org>,
	kernel-janitors <kernel-janitors@vger.kernel.org>
Subject: Re: patch suggestion: Kconfig symbols
Date: Wed, 28 Jul 2021 14:30:54 -0700	[thread overview]
Message-ID: <733d2747b67a8a172333b51bacbf77fe@perches.com> (raw)
In-Reply-To: <09db53b9-7edf-44fc-c6b7-7c4e9198a2d4@infradead.org>

On 2021-07-28 12:41, Randy Dunlap wrote:
> On 7/28/21 8:37 AM, Joe Perches wrote:
>> On Mon, 2021-07-26 at 17:21 -0700, Randy Dunlap wrote:
>>> Running scripts/checkkconfigsymbols.py reports several hundred (maybe 
>>> thousand)
>>> Kconfig symbols that are used questionably. Lots of these are false 
>>> positives
>>> but lots of the remainder could use some cleaning up.
>> []
>>> False positive example:
>>> 
>>> XCHOFFLD_MEM
>>> Referencing files: drivers/scsi/qla2xxx/qla_mbx.c
>>> Similar symbols: OF_PMEM, CXL_MEM, CXL_PMEM
>>> 
>>> The Referencing source file does this:
>>> #define CONFIG_XCHOFFLD_MEM	0x3
>>> 
>>> which is legitimate, so no change is needed.
>> 
>> Legitimate is perhaps dubious.
>> 
>> It might be better if Kconfig has exclusive use of CONFIG_<foo> naming 
>> so
>> renaming all the other existing CONFIG_<foo> defines might be 
>> appropriate.
> 
> I would prefer that as well -- maybe 15 years ago.
> But I think it's too invasive to make that change now.

I do not think it's that invasive.

It's something that doesn't have to be done immediately either.

It's not too many macro defines and not too many uses of those defines.

  reply	other threads:[~2021-07-28 21:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <295b8f8c-4264-9f32-6723-9d2d574021ac@infradead.org>
2021-07-28 15:37 ` patch suggestion: Kconfig symbols Joe Perches
2021-07-28 19:41   ` Randy Dunlap
2021-07-28 21:30     ` Joe Perches [this message]
2021-07-28 22:55       ` Randy Dunlap
2021-07-29  9:55   ` Greg KH

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=733d2747b67a8a172333b51bacbf77fe@perches.com \
    --to=joe@perches.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).