I'm still cleaning up my kernel "scanning" scripts, and documenting them one by one here: https://crashcourse.ca/doku/doku.php?id=linux_kernel_cleanup so that people looking for Linux kernel janitorial work can peruse the scripts (excuse the bland formatting for now), and can run them, analyze the output, and determine if there is cleanup work that can be submitted as patches. (NOTE: I will add to my wiki page the guidance to not just blindly run the scripts and submit patches. Rather, the output is to be used as a first step to see if the output is meaningful, what it means, then to examine the Git log to understand the history of the output, then identify the maintainers/mailing lists who should receive any appropriate patches.) In any event, one of the major scans I implemented all those many years ago was to find allegedly "unused" header files -- that is, header files in the kernel source tree that appeared to not be "#include"d from anywhere in the source. I'll document that script shortly at the wiki page but let me provide a sample run so people can appreciate what the output represents. The current script accepts an optional argument as a subdirectory to scan (so you can focus on a small part of the source tree); what that does is collect all of the header files in that subdirectory, but still scans the *entire* kernel source to see if anything anywhere includes any of those header files. I ran this script against the drivers/usb directory, and got the following output: ===== phy-mv-usb.h ===== ./drivers/usb/phy/phy-mv-usb.h ===== sisusb_tables.h ===== ./drivers/usb/misc/sisusbvga/sisusb_tables.h What this allegedly tells me is that there are two header files under drivers/usb/ that are not included from anywhere in the entire source tree (for whatever reason). As a manual confirmation, I'll just grep for that header file name from the top of the source: $ grep -r phy-mv-usb.h * $ So does that mean that header file has no value? Not necessarily, as it turns out that a lot of these types of files are lists of enums/macros and corresponding hex strings, so who knows when those values will suddenly become useful again? Same thing with the second header file in that list: $ grep -r sisusb_tables.h $ So nothing includes it but, again, it's chock-full of hex values so who knows who might suddenly need all that information? Running the script on the directory drivers/gpu produces *way* more output (this is just partial output): ===== beige_goby_ip_offset.h ===== ./drivers/gpu/drm/amd/include/beige_goby_ip_offset.h ===== bif_5_0_enum.h ===== ./drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_0_enum.h ===== bif_5_1_enum.h ===== ./drivers/gpu/drm/amd/include/asic_reg/bif/bif_5_1_enum.h ===== cl502d.h ===== ./drivers/gpu/drm/nouveau/include/nvhw/class/cl502d.h ===== cl902d.h ===== ./drivers/gpu/drm/nouveau/include/nvhw/class/cl902d.h ===== dce_11_2_enum.h ===== ./drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_2_enum.h ===== dce_8_0_enum.h ===== ./drivers/gpu/drm/amd/include/asic_reg/dce/dce_8_0_enum.h ===== displayobject.h ===== ./drivers/gpu/drm/amd/include/displayobject.h ===== dmub_trace_buffer.h ===== ./drivers/gpu/drm/amd/display/dmub/inc/dmub_trace_buffer.h ===== gc_9_1_sh_mask.h ===== ./drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_1_sh_mask.h ===== gfx_8_1_d.h ===== ./drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h ===== gfx_8_1_enum.h ===== ./drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_enum.h ===== gfx_8_1_sh_mask.h ===== ./drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_sh_mask.h ===== gmc_8_1_enum.h ===== ./drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_1_enum.h ===== gmc_8_2_enum.h ===== ./drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_2_enum.h ===== hdp_4_4_2_offset.h ===== ./drivers/gpu/drm/amd/include/asic_reg/hdp/hdp_4_4_2_offset.h ... snip ... Again, a lot of that looks like hex string definitions, but no one seems to be including it (or at least not including it in a standard way). Thoughts? rday
