Re: patch suggestion: Kconfig symbols

[Lukas Bulwahn <lukas.bulwahn@gmail.com>]

On Tue, Jul 27, 2021 at 2:21 AM Randy Dunlap <rdunlap@infradead.org> 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/.
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