[PATCH 1/2] module: remove redundant 'depends on MODULES'

[PATCH 1/2] module: remove redundant 'depends on MODULES'

[Masahiro Yamada]

These are located in the 'if MODULES' ... 'endif' block.

Remove the redundant dependencies.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 init/Kconfig | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index bd7d650d4a99..9e72cc6071f5 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2006,7 +2006,6 @@ config MODULE_SRCVERSION_ALL
 
 config MODULE_SIG
 	bool "Module signature verification"
-	depends on MODULES
 	select SYSTEM_DATA_VERIFICATION
 	help
 	  Check modules for valid signatures upon load: the signature
@@ -2083,7 +2082,6 @@ config MODULE_SIG_HASH
 
 config MODULE_COMPRESS
 	bool "Compress modules on installation"
-	depends on MODULES
 	help
 
 	  Compresses kernel modules when 'make modules_install' is run; gzip or
@@ -2121,7 +2119,7 @@ endchoice
 
 config TRIM_UNUSED_KSYMS
 	bool "Trim unused exported kernel symbols"
-	depends on MODULES && !UNUSED_SYMBOLS
+	depends on !UNUSED_SYMBOLS
 	help
 	  The kernel and some modules make many symbols available for
 	  other modules to use via EXPORT_SYMBOL() and variants. Depending
-- 
2.17.1

[PATCH 2/2] module: move CONFIG_UNUSED_SYMBOLS to the sub-menu of MODULES

[Masahiro Yamada]

When CONFIG_MODULES is disabled, CONFIG_UNUSED_SYMBOLS is pointless,
thus it should be invisible.

Instead of adding "depends on MODULES", I moved it to the sub-menu
"Enable loadable module support", which is a better fit. I put it
close to TRIM_UNUSED_KSYMS because it depends on !UNUSED_SYMBOLS.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 init/Kconfig      | 16 ++++++++++++++++
 lib/Kconfig.debug | 16 ----------------
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 9e72cc6071f5..b3100aa3138f 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2117,6 +2117,22 @@ config MODULE_COMPRESS_XZ
 
 endchoice
 
+config UNUSED_SYMBOLS
+	bool "Enable unused/obsolete exported symbols"
+	default y if X86
+	help
+	  Unused but exported symbols make the kernel needlessly bigger.  For
+	  that reason most of these unused exports will soon be removed.  This
+	  option is provided temporarily to provide a transition period in case
+	  some external kernel module needs one of these symbols anyway. If you
+	  encounter such a case in your module, consider if you are actually
+	  using the right API.  (rationale: since nobody in the kernel is using
+	  this in a module, there is a pretty good chance it's actually the
+	  wrong interface to use).  If you really need the symbol, please send a
+	  mail to the linux kernel mailing list mentioning the symbol and why
+	  you really need it, and what the merge plan to the mainline kernel for
+	  your module is.
+
 config TRIM_UNUSED_KSYMS
 	bool "Trim unused exported kernel symbols"
 	depends on !UNUSED_SYMBOLS
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 5960e2980a8a..e0e14780a13d 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -277,22 +277,6 @@ config READABLE_ASM
           to keep kernel developers who have to stare a lot at assembler listings
           sane.
 
-config UNUSED_SYMBOLS
-	bool "Enable unused/obsolete exported symbols"
-	default y if X86
-	help
-	  Unused but exported symbols make the kernel needlessly bigger.  For
-	  that reason most of these unused exports will soon be removed.  This
-	  option is provided temporarily to provide a transition period in case
-	  some external kernel module needs one of these symbols anyway. If you
-	  encounter such a case in your module, consider if you are actually
-	  using the right API.  (rationale: since nobody in the kernel is using
-	  this in a module, there is a pretty good chance it's actually the
-	  wrong interface to use).  If you really need the symbol, please send a
-	  mail to the linux kernel mailing list mentioning the symbol and why
-	  you really need it, and what the merge plan to the mainline kernel for
-	  your module is.
-
 config DEBUG_FS
 	bool "Debug Filesystem"
 	help
-- 
2.17.1

Re: [PATCH 1/2] module: remove redundant 'depends on MODULES'

[Jessica Yu]

+++ Masahiro Yamada [09/09/19 20:04 +0900]:
>These are located in the 'if MODULES' ... 'endif' block.
>
>Remove the redundant dependencies.
>
>Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Acked-by: Jessica Yu <jeyu@kernel.org>

Re: [PATCH 2/2] module: move CONFIG_UNUSED_SYMBOLS to the sub-menu of MODULES

[Jessica Yu]

+++ Masahiro Yamada [09/09/19 20:04 +0900]:
>When CONFIG_MODULES is disabled, CONFIG_UNUSED_SYMBOLS is pointless,
>thus it should be invisible.
>
>Instead of adding "depends on MODULES", I moved it to the sub-menu
>"Enable loadable module support", which is a better fit. I put it
>close to TRIM_UNUSED_KSYMS because it depends on !UNUSED_SYMBOLS.
>
>Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Acked-by: Jessica Yu <jeyu@kernel.org>

Re: [PATCH 1/2] module: remove redundant 'depends on MODULES'

[Masahiro Yamada]

On Wed, Sep 11, 2019 at 8:46 PM Jessica Yu <jeyu@kernel.org> wrote:
>
> +++ Masahiro Yamada [09/09/19 20:04 +0900]:
> >These are located in the 'if MODULES' ... 'endif' block.
> >
> >Remove the redundant dependencies.
> >
> >Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>
> Acked-by: Jessica Yu <jeyu@kernel.org>
>

Could you queue these two patches to your tree?

Thanks.


--
Best Regards

Masahiro Yamada

Re: [PATCH 1/2] module: remove redundant 'depends on MODULES'

[Jessica Yu]

+++ Masahiro Yamada [11/09/19 21:21 +0900]:
>On Wed, Sep 11, 2019 at 8:46 PM Jessica Yu <jeyu@kernel.org> wrote:
>>
>> +++ Masahiro Yamada [09/09/19 20:04 +0900]:
>> >These are located in the 'if MODULES' ... 'endif' block.
>> >
>> >Remove the redundant dependencies.
>> >
>> >Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>>
>> Acked-by: Jessica Yu <jeyu@kernel.org>
>>
>
>Could you queue these two patches to your tree?
>
>Thanks.

Ah, I thought they were going to the kbuild tree. But yes, I'll take
them through modules-next.

Thanks,

Jessica