I was just about to add another janitorial check to my kernel janitors' page when I remembered that it is a bit trickier than I thought, so I'm open to feedback here. (And remember, none of my scripts are meant to be bulletproof; they are a *starting point* for cleanup, nothing more.) I have a script called "find_badif_configs.sh", whose purpose is to identify alleged Kconfig symbols that are *tested* in kernel source or header files (with some variation of #if or #ifdef, that sort of thing), but do not appear to be *defined* in any Kconfig file. That means that while those tests are for the most part meaningless, they are perfectly valid. But they're clearly pointless. Let me start with a simple example or two: >>>>> ACORNSCSI_CONSTANTS drivers/scsi/arm/acornscsi.c:92:#undef CONFIG_ACORNSCSI_CONSTANTS drivers/scsi/arm/acornscsi.c:393:#ifdef CONFIG_ACORNSCSI_CONSTANTS drivers/scsi/arm/acornscsi.c:471:#ifdef CONFIG_ACORNSCSI_CONSTANTS That's the first hit when I run my script on the drivers/ direcxtory, and if I do a simple grep, I can see that the string "ACORNSCSI_CONSTANTS" occurs nowhere else in the source tree. So this would *seem* to be a good candidate for cleanup, after someone checks the Git log to see where that symbol went, and why, and fixes the surrounding code. You get the idea. Here are a few more examples that could be candidates -- CONFIG_* symbols that are tested by the preprocessor but are not defined in any Kconfig file: >>>>> CRYPTO_DEV_ASPEED_HACE_CRYPTO_DEBUG drivers/crypto/aspeed/aspeed-hace-crypto.c:19:#ifdef CONFIG_CRYPTO_DEV_ASPEED_HACE_CRYPTO_DEBUG >>>>> DRM_AMD_DC_DP2_0 drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c:107:#if defined(CONFIG_DRM_AMD_DC_DP2_0) >>>>> DRM_XE_LMTT_2L_128GB drivers/gpu/drm/xe/xe_lmtt_2l.c:57:#if IS_ENABLED(CONFIG_DRM_XE_LMTT_2L_128GB) >>>>> FUSION_MAX_FC_SGE drivers/message/fusion/mptbase.h:180:#ifdef CONFIG_FUSION_MAX_FC_SGE drivers/message/fusion/mptbase.h:181:#if CONFIG_FUSION_MAX_FC_SGE < 16 drivers/message/fusion/mptbase.h:183:#elif CONFIG_FUSION_MAX_FC_SGE > 256 drivers/message/fusion/mptbase.h:186:#define MPT_SCSI_FC_SG_DEPTH CONFIG_FUSION_MAX_FC_SGE And here's the tricky bit, since here's another symbol that initially was misidentified: >>>>> NCR53C8XX_PREFETCH drivers/scsi/ncr53c8xx.c:1779:#ifdef CONFIG_NCR53C8XX_PREFETCH drivers/scsi/Makefile:180: := -DCONFIG_NCR53C8XX_PREFETCH -DSCSI_NCR_BIG_ENDIAN \ Note how a "CONFIG_" prefixed macro is not defined in a Kconfig file, but is defined in the Makefile. Aaaargh. I remember from years back that there was a coding standard that the prefix of "CONFIG_" was to be reserved for Kconfig-defined variables, but there are definitely places like the above in the kernel that break that rule, so my script had to be extended to show just the above -- what *would* have been a potential cleanup except for that hacky setting in the Makefile. Anyway, I'll post that script and people can poke around with it. Stay tuned. rday
