Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 9月, 2022 1 次提交
  3. 19 4月, 2022 1 次提交
  5. 15 10月, 2021 1 次提交
  7. 13 10月, 2021 1 次提交
  9. 03 6月, 2021 2 次提交
  11. 22 4月, 2021 2 次提交
  13. 19 4月, 2021 1 次提交
  15. 13 4月, 2021 1 次提交
  17. 09 4月, 2021 1 次提交
  19. 09 3月, 2021 2 次提交
  21. 27 1月, 2021 1 次提交
  23. 14 12月, 2020 1 次提交
  25. 07 12月, 2020 1 次提交
  27. 01 12月, 2020 1 次提交
  29. 30 11月, 2020 1 次提交
  31. 25 11月, 2020 2 次提交
  33. 23 11月, 2020 1 次提交
  35. 16 11月, 2020 1 次提交
  37. 09 11月, 2020 1 次提交
  39. 02 11月, 2020 2 次提交
  41. 26 10月, 2020 1 次提交
  43. 20 10月, 2020 1 次提交
  45. 14 10月, 2020 1 次提交
  47. 12 10月, 2020 3 次提交
    • O
      kbuild: enforce -Werror=return-type · 172aad81
      由 Olaf Hering 提交于 
      Catch errors which at least gcc tolerates by default:
 warning: 'return' with no value, in function returning non-void [-Wreturn-type]
Signed-off-by: NOlaf Hering <olaf@aepfle.de>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      172aad81
    • L
      Linux 5.9 · bbf5c979
      由 Linus Torvalds 提交于
      bbf5c979
    • J
      scripts: remove namespace.pl · 7dfbea4c
      由 Jacob Keller 提交于 
      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 [1] and
[2] for further context).

As described by Masahiro Yamada at [2], 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 [1], 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 ([3], and [4])

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 [2], 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.

[1] https://lore.kernel.org/netdev/20200708164812.384ae8ea@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/
[2] https://lore.kernel.org/lkml/20190129204319.15238-1-jacob.e.keller@intel.com/
[3] https://lore.kernel.org/netdev/20190828.154744.2058157956381129672.davem@davemloft.net/
[4] https://lore.kernel.org/netdev/20190827210928.576c5fef@cakuba.netronome.com/Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Acked-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      7dfbea4c
  49. 09 10月, 2020 1 次提交
  51. 05 10月, 2020 1 次提交
  53. 28 9月, 2020 1 次提交
  55. 24 9月, 2020 6 次提交