|author||Jacob Keller <firstname.lastname@example.org>||2020-10-09 17:18:44 -0700|
|committer||Masahiro Yamada <email@example.com>||2020-10-12 01:58:53 +0900|
scripts: remove namespace.pl
namespace.pl is intended to help locate symbols which are defined but are not used externally. The goal is to avoid bloat of the namespace in the resulting kernel image. The script relies on object data, and only finds unused symbols for the configuration used to generate that object data. This results in a lot of false positive warnings such as symbols only used by a single architecture, or symbols which are used externally only under certain configurations. Running namespace.pl using allyesconfig, allmodconfig, and x86_64_defconfig yields the following results: * allmodconfig * 11122 unique symbol names with no external reference * 1194 symbols listed as multiply defined * 214 symbols it can't resolve * allyesconfig * 10997 unique symbol names with no external reference * 1194 symbols listed as multiply defined * 214 symbols it can't resolve * x86_64_defconfig * 5757 unique symbol names with no external reference * 528 symbols listed as multiply defined * 154 symbols it can't resolve The script also has no way to easily limit the scope of the checks to a given subset of the kernel, such as only checking for symbols defined within a module or subsystem. Discussion on public mailing lists seems to indicate that many view the tool output as suspect or not very useful (see discussions at  and  for further context). As described by Masahiro Yamada at , namespace.pl provides 3 types of checks: listing multiply defined symbols, resolving external symbols, and warnings about symbols with no reference. The first category of issues is easily caught by the linker as any set of multiply defined symbols should fail to link. The second category of issues is also caught by linking, as undefined symbols would cause issues. Even with modules, these types of issues where a module relies on an external symbol are caught by modpost. The remaining category of issues reported is the list of symbols with no external reference, and is the primary motivation of this script. However, it ought to be clear from the above examples that the output is difficult to sort through. Even allyesconfig has ~10000 entries. The current submit-checklist indicates that patches ought to go through namespacecheck and fix any new issues arising. But that itself presents problems. As described at , many cases of reports are due to configuration where a function is used externally by some configuration settings. Prominent maintainers appear to dislike changes modify code such that symbols become static based on CONFIG_* flags (, and ) One possible solution is to adjust the advice and indicate that we only care about the output of namespacecheck on allyesconfig or allmodconfig builds... However, given the discussion at , I suspect that few people are actively using this tool. It doesn't have a maintainer in the MAINTAINERS flie, and it produces so many warnings for unused symbols that it is difficult to use effectively. Thus, I propose we simply remove it.  https://firstname.lastname@example.org/  https://email@example.com/  https://firstname.lastname@example.org/  https://email@example.com/ Signed-off-by: Jacob Keller <firstname.lastname@example.org> Acked-by: Randy Dunlap <email@example.com> Acked-by: Jakub Kicinski <firstname.lastname@example.org> Signed-off-by: Masahiro Yamada <email@example.com>
Diffstat (limited to 'Documentation/process')
1 files changed, 1 insertions, 2 deletions
diff --git a/Documentation/process/submit-checklist.rst b/Documentation/process/submit-checklist.rst
index 3f8e9d5d95c2..e201a6033469 100644
@@ -49,8 +49,7 @@ and elsewhere regarding submitting Linux kernel patches.
9) Check cleanly with sparse.
-10) Use ``make checkstack`` and ``make namespacecheck`` and fix any problems
- that they find.
+10) Use ``make checkstack`` and fix any problems that it finds.