On Tue, Jul 27, 2021 at 2:21 AM Randy Dunlap [off-list ref] wrote:

Hi,

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.

One example:

DSCC4
Referencing files: arch/mips/configs/gpr_defconfig, arch/mips/configs/mtx1_defconfig, drivers/net/wan/Kconfig
Similar symbols: SCC, DMASCC, CRC4, CRC64

There is no longer a Kconfig entry for DSCC4 (it has been deleted, but some
references to it were not deleted) -- and this is not a typo
of one of the "Similar symbols" listed here.

So all of these references to DSCC4 can be (should be) deleted.
And of course, Cc: the GENERIC HDLC (WAN) DRIVERS maintainer on such a patch.


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.


Comment example:

IA32_SUPPORT
Referencing files: arch/x86/include/asm/ia32.h
Similar symbols: MEDIA_SUPPORT, EDAC_SUPPORT, IOMMU_SUPPORT, USB_SUPPORT, I2C_PARPORT, NIOS2_FPU_SUPPORT, NIOS2_CDX_SUPPORT, NIOS2_BMX_SUPPORT, MEDIA_USB_SUPPORT, MEDIA_SDR_SUPPORT

The Referencing file has:
#endif /* !CONFIG_IA32_SUPPORT */

and this #ifdef block was begun with
#ifdef CONFIG_IA32_EMULATION

so the comment on the #endif line is incorrect.
This could be fixed but it's not a big deal just to leave it as is.

So there is lots here that could be done, but there are also lots of
false positives here that don't need to be touched.

Thanks, Randy. Before giving the tasks to potential mentees, I first
had a look for myself and investigated as well. As you have seen, I
could already quickly remove HAVE_IDE, see
https://lore.kernel.org/lkml/20210728182115.4401-1-lukas.bulwahn@gmail.com/ (local).
I am preparing another larger patch set for ./arch/x86 fixes to see
the reception of such a larger clean-up before handing such tasks to a
mentee.

There are a few "real false positives" and a few "just fixing
comments", but it is not too bad...  In the end, there are some issues
that have been 'broken' (= working differently than intended or
fulfilling no purpose) for months or years and not being noticed. So,
the tool does serve some basic purpose of detecting some issues. Of
course, the resulting commits are "trivial patches", which brings back
Greg KH's general concern (on the ksummit mailing list) how to deal
with such work (e.g., verify the effect of the patch) when done by
potentially less trustworthy developers.

At least here on the linux-kernel-mentees, those patches would be
gated by some general mentor review and testing.

Lukas
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees