linux_kernel_cleanup

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
linux_kernel_cleanup [2025/07/01 13:05] – [The (working) cleanup scripts] rpjdaylinux_kernel_cleanup [2025/07/02 13:03] (current) – [5. Finding allegedly "unused" header files] rpjday
Line 10: Line 10:
   * identifying "bad" select directives in Kconfig files   * identifying "bad" select directives in Kconfig files
   * identifying "bad #if" preprocessor checks for non-existent Kconfig variables   * identifying "bad #if" preprocessor checks for non-existent Kconfig variables
 +  * identifying allegedly "unused" header files
  
 NOTE: Don't try to submit a mega-patch with as many similar patches as you possibly can; rather, submit patches on a subsystem by subsystem basis, to make the patches manageable so that they can be reviewed and approved by just the maintainers of that subsystem. NOTE: Don't try to submit a mega-patch with as many similar patches as you possibly can; rather, submit patches on a subsystem by subsystem basis, to make the patches manageable so that they can be reviewed and approved by just the maintainers of that subsystem.
Line 15: Line 16:
 **//IMPORTANT//**: Do not accept the output from any of these or upcoming scripts verbatim. There is no question that these scripts cannot possibly take into account every conceivable variation being searched for, so treat the results with skepticism and do extra sanity checking to make sure your submitted improvements make sense. If you're unsure, check the Git log to see if there are previous commits that back up your interpretation of what you're seeing. **//IMPORTANT//**: Do not accept the output from any of these or upcoming scripts verbatim. There is no question that these scripts cannot possibly take into account every conceivable variation being searched for, so treat the results with skepticism and do extra sanity checking to make sure your submitted improvements make sense. If you're unsure, check the Git log to see if there are previous commits that back up your interpretation of what you're seeing.
  
-==== The (working) cleanup scripts ==== +==== 1. Calculating the length of an array ====
- +
-=== 1. Calculating the length of an array ===+
  
 A lot of kernel code needs to calculate the length of an array, frequently to iterate through all of its elements. There are two standard ways to do this in C language: A lot of kernel code needs to calculate the length of an array, frequently to iterate through all of its elements. There are two standard ways to do this in C language:
Line 71: Line 70:
 Note that there some obvious examples of what the script is looking for, as well as some false positives. Note also how various files insist on re-inventing the test in defining a macro that does what is already in that Linux header file. Note that there some obvious examples of what the script is looking for, as well as some false positives. Note also how various files insist on re-inventing the test in defining a macro that does what is already in that Linux header file.
  
-=== 2. Check if something is a power of two ===+==== 2. Check if something is a power of two ====
  
 Quite a lot of kernel code needs to check if an integer value is an exact power of two -- the general test for that is already defined in the header file ''include/linux/log2.h'' as follows: Quite a lot of kernel code needs to check if an integer value is an exact power of two -- the general test for that is already defined in the header file ''include/linux/log2.h'' as follows:
Line 136: Line 135:
 so you need to be careful as to what you think any of that simplifies to. so you need to be careful as to what you think any of that simplifies to.
  
-=== 3. Finding "bad" select directives in Kconfig files ===+==== 3. Finding "bad" select directives in Kconfig files ====
  
 Many kernel Kconfig files contain "select" directives, some of which are no longer relevant since the config entry they refer to was deleted previously, but the associated "select" directives were never removed. This is clearly not fatal, but it's still something that can be cleaned up. Many kernel Kconfig files contain "select" directives, some of which are no longer relevant since the config entry they refer to was deleted previously, but the associated "select" directives were never removed. This is clearly not fatal, but it's still something that can be cleaned up.
Line 204: Line 203:
 In other words, the above "select" directives look like they can be removed, but it's your responsibility to verify that. In other words, the above "select" directives look like they can be removed, but it's your responsibility to verify that.
  
-=== 4. Find "badif" CONFIG symbols ===+==== 4. Find "badif" CONFIG symbols ====
  
 This check refers to "CONFIG_"-prefixed preprocessor symbols that are tested in the kernel source somewhere, but are not defined in any Kconfig file; that usually means that the symbol was once dropped from a Kconfig file, but the (now pointless) preprocessor tests are still being done. This check refers to "CONFIG_"-prefixed preprocessor symbols that are tested in the kernel source somewhere, but are not defined in any Kconfig file; that usually means that the symbol was once dropped from a Kconfig file, but the (now pointless) preprocessor tests are still being done.
Line 217: Line 216:
 </code> </code>
  
-The standard approach here would be to check carefully that there are no references to that string anywhere in the source tree, and check the Git log to see if/when that symbol was removed, and why.+The standard approach here would be to check carefully that there are no references to that string anywhere in the source tree, and check the Git log to see if/when that symbol was removed, and why, and clean it up.
  
 Additional examples from the drivers/ directory: Additional examples from the drivers/ directory:
Line 282: Line 281:
 done done
 </code> </code>
 +
 +==== 5. Finding allegedly "unused" header files ====
 +
 +"Unused" Linux kernel header files simply means header files that don't appear to be #included from anywhere in the kernel source tree. There could be all sorts of reasons for that.
 +
 +One reason is that a source file was removed, but its associated supporting header file was overlooked and is still sitting there, now having no purpose in life. Another (quite common) reason is that many of those header files contain enums or macros for hex offsets for particular devices, so that even if nothing is including them at the moment, they still need to be preserved in case something needs all that content.
 +
 +As a basic example of the current ''find_unused_headers.sh'' script, let's have it check under the directory ''drivers/usb'':
 +
 +<code>
 +===== phy-mv-usb.h =====
 +./drivers/usb/phy/phy-mv-usb.h
 +===== sisusb_tables.h =====
 +./drivers/usb/misc/sisusbvga/sisusb_tables.h
 +</code>
 +
 +The above tells us simply that there are two header files under that directory that appear to not be included from //anywhere// in the Linux kernel source tree. Why that is would require taking a closer look, possibly checking the Git log regarding that header file, and so on; it does **not** mean you can simply submit a patch to delete that file.
 +
 +Here is the admittedly brute force script ''find_unused_headers.sh'':
 +
 +<code>
 +#!/bin/sh
 +
 +DIR=${1-*}
 +
 +LONGHDRS=$(find ${DIR} -name "*.h")
 +
 +HDRS=""
 +
 +for h in ${LONGHDRS} ; do
 +        HDRS="${HDRS} $(basename ${h})"
 +done
 +
 +HDRS=$(for h in ${HDRS} ; do echo $h ; done | sort -u)
 +
 +#  Test that each header file is included from *somewhere*.
 +
 +for h in ${HDRS} ; do
 +        # echo "Testing $h ..."
 +        egrep -rq ".*#.*include.*${h}" * || {
 +                echo "===== ${h} ====="
 +                find . -name "${h}"
 +                grep -rwH ${h} *
 +        }
 +done
 +</code>
 +
 +**EXERCISE**: Run the script on the ''drivers/gpu'' directory to get far more output.
  • linux_kernel_cleanup.1751375143.txt.gz
  • Last modified: 2025/07/01 13:05
  • by rpjday