linux-modules.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 00/17] MODULE_LICENSE removals, sixth tranche
@ 2023-03-02 21:17 Nick Alcock
  2023-03-02 21:17 ` [PATCH 01/17] irqchip: remove MODULE_LICENSE in non-modules Nick Alcock
                   ` (17 more replies)
  0 siblings, 18 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof
  Cc: dri-devel, linux-fsdevel, linux-kernel, linux-media, linux-mm,
	linux-modules, x86

This series, based on current modules-next, is part of a treewide cleanup
suggested by Luis Chamberlain, to remove the LICENSE_MODULE usage from
files/objects that are not tristate.  Due to recent changes to kbuild, these
uses are now problematic.  See the commit logs for more details.

(The commit log prefixes and Cc lists are automatically determined.  I've
eyeballed them, and they seem reasonable: my apologies if they are not.)

This is the last tranche of patches in this series. (In total, there are 121
patches in this series.)


The series at a whole can be found here:
  https://github.com/nickalcock/linux module-license

(This is a respin with kbuild: prefixes dropped.  The previous series,
used in the mailouts of tranche 3 and earlier, is in the
module-license-kbuild-prefix branch.)

Cc: dri-devel@lists.freedesktop.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: linux-modules@vger.kernel.org
Cc: x86@kernel.org

Nick Alcock (17):
  irqchip: remove MODULE_LICENSE in non-modules
  bus: remove MODULE_LICENSE in non-modules
  braille_console: remove MODULE_LICENSE in non-modules
  arm-cci: remove MODULE_LICENSE in non-modules
  drivers: bus: simple-pm-bus: remove MODULE_LICENSE in non-modules
  watch_queue: remove MODULE_LICENSE in non-modules
  btree: remove MODULE_LICENSE in non-modules
  lib: remove MODULE_LICENSE in non-modules
  fprobe: remove MODULE_LICENSE in non-modules
  tty: remove MODULE_LICENSE in non-modules
  unicode: remove MODULE_LICENSE in non-modules
  udmabuf: remove MODULE_LICENSE in non-modules
  regulator: stm32-pwr: remove MODULE_LICENSE in non-modules
  mm: remove MODULE_LICENSE in non-modules
  xen: remove MODULE_LICENSE in non-modules
  zpool: remove MODULE_LICENSE in non-modules
  zswap: remove MODULE_LICENSE in non-modules

 arch/x86/mm/debug_pagetables.c                  | 1 -
 drivers/accessibility/braille/braille_console.c | 1 -
 drivers/bus/arm-cci.c                           | 1 -
 drivers/bus/bt1-apb.c                           | 1 -
 drivers/bus/bt1-axi.c                           | 1 -
 drivers/bus/simple-pm-bus.c                     | 1 -
 drivers/dma-buf/udmabuf.c                       | 1 -
 drivers/irqchip/irq-ti-sci-inta.c               | 1 -
 drivers/irqchip/irq-ti-sci-intr.c               | 1 -
 drivers/regulator/stm32-pwr.c                   | 1 -
 drivers/tty/n_null.c                            | 1 -
 drivers/xen/grant-dma-ops.c                     | 1 -
 drivers/xen/xenbus/xenbus_probe.c               | 1 -
 fs/unicode/utf8-core.c                          | 1 -
 kernel/watch_queue.c                            | 1 -
 lib/btree.c                                     | 1 -
 lib/glob.c                                      | 1 -
 lib/test_fprobe.c                               | 1 -
 mm/zpool.c                                      | 1 -
 mm/zswap.c                                      | 1 -
 20 files changed, 20 deletions(-)

-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply	[flat|nested] 47+ messages in thread

* [PATCH 01/17] irqchip: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-02 21:17 ` [PATCH 02/17] bus: " Nick Alcock
                   ` (16 subsequent siblings)
  17 siblings, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof
  Cc: linux-modules, linux-kernel, Hitomi Hasegawa, Nishanth Menon,
	Tero Kristo, Santosh Shilimkar, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Tero Kristo <kristo@kernel.org>
Cc: Santosh Shilimkar <ssantosh@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
---
 drivers/irqchip/irq-ti-sci-inta.c | 1 -
 drivers/irqchip/irq-ti-sci-intr.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/irqchip/irq-ti-sci-inta.c b/drivers/irqchip/irq-ti-sci-inta.c
index a6ecc53d055cd..7133f9fa6fd9e 100644
--- a/drivers/irqchip/irq-ti-sci-inta.c
+++ b/drivers/irqchip/irq-ti-sci-inta.c
@@ -743,4 +743,3 @@ module_platform_driver(ti_sci_inta_irq_domain_driver);
 
 MODULE_AUTHOR("Lokesh Vutla <lokeshvutla@ti.com>");
 MODULE_DESCRIPTION("K3 Interrupt Aggregator driver over TI SCI protocol");
-MODULE_LICENSE("GPL v2");
diff --git a/drivers/irqchip/irq-ti-sci-intr.c b/drivers/irqchip/irq-ti-sci-intr.c
index fe8fad22bcf96..939201b2c871a 100644
--- a/drivers/irqchip/irq-ti-sci-intr.c
+++ b/drivers/irqchip/irq-ti-sci-intr.c
@@ -302,4 +302,3 @@ module_platform_driver(ti_sci_intr_irq_domain_driver);
 
 MODULE_AUTHOR("Lokesh Vutla <lokeshvutla@ticom>");
 MODULE_DESCRIPTION("K3 Interrupt Router driver over TI SCI protocol");
-MODULE_LICENSE("GPL v2");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 02/17] bus: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
  2023-03-02 21:17 ` [PATCH 01/17] irqchip: remove MODULE_LICENSE in non-modules Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-02 21:17 ` [PATCH 03/17] braille_console: " Nick Alcock
                   ` (15 subsequent siblings)
  17 siblings, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof; +Cc: linux-modules, linux-kernel, Hitomi Hasegawa, Philipp Zabel

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
---
 drivers/bus/bt1-apb.c | 1 -
 drivers/bus/bt1-axi.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/bus/bt1-apb.c b/drivers/bus/bt1-apb.c
index 63b1b4a76671d..e97c1d1c7578b 100644
--- a/drivers/bus/bt1-apb.c
+++ b/drivers/bus/bt1-apb.c
@@ -416,4 +416,3 @@ module_platform_driver(bt1_apb_driver);
 
 MODULE_AUTHOR("Serge Semin <Sergey.Semin@baikalelectronics.ru>");
 MODULE_DESCRIPTION("Baikal-T1 APB-bus driver");
-MODULE_LICENSE("GPL v2");
diff --git a/drivers/bus/bt1-axi.c b/drivers/bus/bt1-axi.c
index 70e49a6e53746..4007e7322cf21 100644
--- a/drivers/bus/bt1-axi.c
+++ b/drivers/bus/bt1-axi.c
@@ -309,4 +309,3 @@ module_platform_driver(bt1_axi_driver);
 
 MODULE_AUTHOR("Serge Semin <Sergey.Semin@baikalelectronics.ru>");
 MODULE_DESCRIPTION("Baikal-T1 AXI-bus driver");
-MODULE_LICENSE("GPL v2");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 03/17] braille_console: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
  2023-03-02 21:17 ` [PATCH 01/17] irqchip: remove MODULE_LICENSE in non-modules Nick Alcock
  2023-03-02 21:17 ` [PATCH 02/17] bus: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-02 21:17 ` [PATCH 04/17] arm-cci: " Nick Alcock
                   ` (14 subsequent siblings)
  17 siblings, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof; +Cc: linux-modules, linux-kernel, Hitomi Hasegawa

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
---
 drivers/accessibility/braille/braille_console.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/accessibility/braille/braille_console.c b/drivers/accessibility/braille/braille_console.c
index c4d54a5326b11..06b43b678d6ea 100644
--- a/drivers/accessibility/braille/braille_console.c
+++ b/drivers/accessibility/braille/braille_console.c
@@ -24,7 +24,6 @@
 
 MODULE_AUTHOR("samuel.thibault@ens-lyon.org");
 MODULE_DESCRIPTION("braille device");
-MODULE_LICENSE("GPL");
 
 /*
  * Braille device support part.
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 04/17] arm-cci: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (2 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 03/17] braille_console: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-02 21:17 ` [PATCH 05/17] drivers: bus: simple-pm-bus: " Nick Alcock
                   ` (13 subsequent siblings)
  17 siblings, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof; +Cc: linux-modules, linux-kernel, Hitomi Hasegawa

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
---
 drivers/bus/arm-cci.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index b8184a9035837..e231e9c05da16 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -583,5 +583,4 @@ EXPORT_SYMBOL_GPL(cci_probed);
 
 early_initcall(cci_init);
 core_initcall(cci_platform_init);
-MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("ARM CCI support");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 05/17] drivers: bus: simple-pm-bus: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (3 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 04/17] arm-cci: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-03  7:52   ` Geert Uytterhoeven
  2023-03-02 21:17 ` [PATCH 06/17] watch_queue: " Nick Alcock
                   ` (12 subsequent siblings)
  17 siblings, 1 reply; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof; +Cc: linux-modules, linux-kernel, Hitomi Hasegawa

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
---
 drivers/bus/simple-pm-bus.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
index 6b8d6257ed8a4..32e6e960f1676 100644
--- a/drivers/bus/simple-pm-bus.c
+++ b/drivers/bus/simple-pm-bus.c
@@ -92,4 +92,3 @@ module_platform_driver(simple_pm_bus_driver);
 
 MODULE_DESCRIPTION("Simple Power-Managed Bus Driver");
 MODULE_AUTHOR("Geert Uytterhoeven <geert+renesas@glider.be>");
-MODULE_LICENSE("GPL v2");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 06/17] watch_queue: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (4 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 05/17] drivers: bus: simple-pm-bus: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-02 21:17 ` [PATCH 07/17] btree: " Nick Alcock
                   ` (11 subsequent siblings)
  17 siblings, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof; +Cc: linux-modules, linux-kernel, Hitomi Hasegawa

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
---
 kernel/watch_queue.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/watch_queue.c b/kernel/watch_queue.c
index a6f9bdd956c39..5deed017bef42 100644
--- a/kernel/watch_queue.c
+++ b/kernel/watch_queue.c
@@ -29,7 +29,6 @@
 
 MODULE_DESCRIPTION("Watch queue");
 MODULE_AUTHOR("Red Hat, Inc.");
-MODULE_LICENSE("GPL");
 
 #define WATCH_QUEUE_NOTE_SIZE 128
 #define WATCH_QUEUE_NOTES_PER_PAGE (PAGE_SIZE / WATCH_QUEUE_NOTE_SIZE)
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 07/17] btree: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (5 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 06/17] watch_queue: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-02 21:17 ` [PATCH 08/17] lib: " Nick Alcock
                   ` (10 subsequent siblings)
  17 siblings, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof; +Cc: linux-modules, linux-kernel, Hitomi Hasegawa

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
---
 lib/btree.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/btree.c b/lib/btree.c
index a82100c73b559..49420cae3a833 100644
--- a/lib/btree.c
+++ b/lib/btree.c
@@ -794,4 +794,3 @@ module_exit(btree_module_exit);
 
 MODULE_AUTHOR("Joern Engel <joern@logfs.org>");
 MODULE_AUTHOR("Johannes Berg <johannes@sipsolutions.net>");
-MODULE_LICENSE("GPL");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 08/17] lib: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (6 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 07/17] btree: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-02 21:17 ` [PATCH 09/17] fprobe: " Nick Alcock
                   ` (9 subsequent siblings)
  17 siblings, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof; +Cc: linux-modules, linux-kernel, Hitomi Hasegawa

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
---
 lib/glob.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/glob.c b/lib/glob.c
index 15b73f490720c..5c30606a1b92e 100644
--- a/lib/glob.c
+++ b/lib/glob.c
@@ -7,7 +7,6 @@
  * both usually compiled in and the module overhead goes away.
  */
 MODULE_DESCRIPTION("glob(7) matching");
-MODULE_LICENSE("Dual MIT/GPL");
 
 /**
  * glob_match - Shell-style pattern matching, like !fnmatch(pat, str, 0)
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 09/17] fprobe: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (7 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 08/17] lib: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-02 21:17 ` [PATCH 10/17] tty: " Nick Alcock
                   ` (8 subsequent siblings)
  17 siblings, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof; +Cc: linux-modules, linux-kernel, Hitomi Hasegawa

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
---
 lib/test_fprobe.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/test_fprobe.c b/lib/test_fprobe.c
index 1fb56cf5e5ce6..fd6153800e56a 100644
--- a/lib/test_fprobe.c
+++ b/lib/test_fprobe.c
@@ -168,4 +168,3 @@ static struct kunit_suite fprobe_test_suite = {
 
 kunit_test_suites(&fprobe_test_suite);
 
-MODULE_LICENSE("GPL");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (8 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 09/17] fprobe: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-09 16:15   ` Greg Kroah-Hartman
  2023-03-02 21:17 ` [PATCH 11/17] unicode: " Nick Alcock
                   ` (7 subsequent siblings)
  17 siblings, 1 reply; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof
  Cc: linux-modules, linux-kernel, Hitomi Hasegawa, Greg Kroah-Hartman,
	Jiri Slaby

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
---
 drivers/tty/n_null.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c
index f913b665af725..c24f75942c49d 100644
--- a/drivers/tty/n_null.c
+++ b/drivers/tty/n_null.c
@@ -63,7 +63,6 @@ static void __exit n_null_exit(void)
 module_init(n_null_init);
 module_exit(n_null_exit);
 
-MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Alan Cox");
 MODULE_ALIAS_LDISC(N_NULL);
 MODULE_DESCRIPTION("Null ldisc driver");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 11/17] unicode: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (9 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 10/17] tty: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-06 15:32   ` Gabriel Krisman Bertazi
  2023-03-02 21:17 ` [PATCH 12/17] udmabuf: " Nick Alcock
                   ` (6 subsequent siblings)
  17 siblings, 1 reply; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof
  Cc: linux-modules, linux-kernel, Hitomi Hasegawa,
	Gabriel Krisman Bertazi, linux-fsdevel

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
Cc: Gabriel Krisman Bertazi <krisman@collabora.com>
Cc: linux-fsdevel@vger.kernel.org
---
 fs/unicode/utf8-core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/unicode/utf8-core.c b/fs/unicode/utf8-core.c
index 67aaadc3ab072..8395066341a43 100644
--- a/fs/unicode/utf8-core.c
+++ b/fs/unicode/utf8-core.c
@@ -214,4 +214,3 @@ void utf8_unload(struct unicode_map *um)
 }
 EXPORT_SYMBOL(utf8_unload);
 
-MODULE_LICENSE("GPL v2");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 12/17] udmabuf: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (10 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 11/17] unicode: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-02 21:17 ` [PATCH 13/17] regulator: stm32-pwr: " Nick Alcock
                   ` (5 subsequent siblings)
  17 siblings, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof
  Cc: linux-modules, linux-kernel, Hitomi Hasegawa, Gerd Hoffmann,
	Sumit Semwal, Christian König, dri-devel, linux-media,
	linaro-mm-sig

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
---
 drivers/dma-buf/udmabuf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 283816fbd72fc..d5c09a86df6c1 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -402,4 +402,3 @@ module_init(udmabuf_dev_init)
 module_exit(udmabuf_dev_exit)
 
 MODULE_AUTHOR("Gerd Hoffmann <kraxel@redhat.com>");
-MODULE_LICENSE("GPL v2");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 13/17] regulator: stm32-pwr: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (11 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 12/17] udmabuf: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-03  0:31   ` Mark Brown
  2023-03-02 21:17 ` [PATCH 14/17] mm: " Nick Alcock
                   ` (4 subsequent siblings)
  17 siblings, 1 reply; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof
  Cc: linux-modules, linux-kernel, Hitomi Hasegawa, Liam Girdwood,
	Mark Brown, Maxime Coquelin, Alexandre Torgue, linux-stm32,
	linux-arm-kernel

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
---
 drivers/regulator/stm32-pwr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/regulator/stm32-pwr.c b/drivers/regulator/stm32-pwr.c
index 2a42acb7c24e9..8711afd60ade6 100644
--- a/drivers/regulator/stm32-pwr.c
+++ b/drivers/regulator/stm32-pwr.c
@@ -183,4 +183,3 @@ module_platform_driver(stm32_pwr_driver);
 
 MODULE_DESCRIPTION("STM32MP1 PWR voltage regulator driver");
 MODULE_AUTHOR("Pascal Paillet <p.paillet@st.com>");
-MODULE_LICENSE("GPL v2");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 14/17] mm: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (12 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 13/17] regulator: stm32-pwr: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-02 21:17 ` [PATCH 15/17] xen: " Nick Alcock
                   ` (3 subsequent siblings)
  17 siblings, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof
  Cc: linux-modules, linux-kernel, Hitomi Hasegawa, Dave Hansen,
	Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
	Borislav Petkov, x86

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org
---
 arch/x86/mm/debug_pagetables.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/mm/debug_pagetables.c b/arch/x86/mm/debug_pagetables.c
index 092ea436c7e62..b43301cb2a80c 100644
--- a/arch/x86/mm/debug_pagetables.c
+++ b/arch/x86/mm/debug_pagetables.c
@@ -71,6 +71,5 @@ static void __exit pt_dump_debug_exit(void)
 
 module_init(pt_dump_debug_init);
 module_exit(pt_dump_debug_exit);
-MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Arjan van de Ven <arjan@linux.intel.com>");
 MODULE_DESCRIPTION("Kernel debugging helper that dumps pagetables");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 15/17] xen: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (13 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 14/17] mm: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-06  7:45   ` Juergen Gross
  2023-03-02 21:17 ` [PATCH 16/17] zpool: " Nick Alcock
                   ` (2 subsequent siblings)
  17 siblings, 1 reply; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof
  Cc: linux-modules, linux-kernel, Hitomi Hasegawa, Juergen Gross,
	Stefano Stabellini, xen-devel

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org
---
 drivers/xen/grant-dma-ops.c       | 1 -
 drivers/xen/xenbus/xenbus_probe.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 9784a77fa3c99..ca0249fc4d18f 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -413,4 +413,3 @@ bool xen_virtio_restricted_mem_acc(struct virtio_device *dev)
 
 MODULE_DESCRIPTION("Xen grant DMA-mapping layer");
 MODULE_AUTHOR("Juergen Gross <jgross@suse.com>");
-MODULE_LICENSE("GPL");
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 58b732dcbfb83..86c04f239e873 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -1066,4 +1066,3 @@ static int __init xenbus_init(void)
 
 postcore_initcall(xenbus_init);
 
-MODULE_LICENSE("GPL");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 16/17] zpool: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (14 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 15/17] xen: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-02 21:17 ` [PATCH 17/17] zswap: " Nick Alcock
  2023-03-03 22:22 ` [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Luis Chamberlain
  17 siblings, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof
  Cc: linux-modules, linux-kernel, Hitomi Hasegawa, Dan Streetman,
	Andrew Morton, linux-mm

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
---
 mm/zpool.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/mm/zpool.c b/mm/zpool.c
index 571f5c5031dda..6a19c4a58f77b 100644
--- a/mm/zpool.c
+++ b/mm/zpool.c
@@ -395,6 +395,5 @@ bool zpool_can_sleep_mapped(struct zpool *zpool)
 	return zpool->driver->sleep_mapped;
 }
 
-MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Dan Streetman <ddstreet@ieee.org>");
 MODULE_DESCRIPTION("Common API for compressed memory storage");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 17/17] zswap: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (15 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 16/17] zpool: " Nick Alcock
@ 2023-03-02 21:17 ` Nick Alcock
  2023-03-03 22:22 ` [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Luis Chamberlain
  17 siblings, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw)
  To: mcgrof
  Cc: linux-modules, linux-kernel, Hitomi Hasegawa, Seth Jennings,
	Dan Streetman, Vitaly Wool, Andrew Morton, linux-mm

Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
Cc: Seth Jennings <sjenning@redhat.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Vitaly Wool <vitaly.wool@konsulko.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
---
 mm/zswap.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/mm/zswap.c b/mm/zswap.c
index f6c89049cf700..f2fc0373b9677 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -1540,6 +1540,5 @@ static int __init init_zswap(void)
 /* must be late so crypto has time to come up */
 late_initcall(init_zswap);
 
-MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Seth Jennings <sjennings@variantweb.net>");
 MODULE_DESCRIPTION("Compressed cache for swap pages");
-- 
2.39.1.268.g9de2f9a303


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* Re: [PATCH 13/17] regulator: stm32-pwr: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 ` [PATCH 13/17] regulator: stm32-pwr: " Nick Alcock
@ 2023-03-03  0:31   ` Mark Brown
  2023-03-03 18:30     ` Nick Alcock
  0 siblings, 1 reply; 47+ messages in thread
From: Mark Brown @ 2023-03-03  0:31 UTC (permalink / raw)
  To: Nick Alcock
  Cc: mcgrof, linux-modules, linux-kernel, Hitomi Hasegawa,
	Liam Girdwood, Maxime Coquelin, Alexandre Torgue, linux-stm32,
	linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

On Thu, Mar 02, 2023 at 09:17:55PM +0000, Nick Alcock wrote:
> Since commit 8b41fc4454e ("kbuild: create modules.builtin without
> Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
> are used to identify modules. As a consequence, uses of the macro

You've not copied me on the rest of the series so I'm not sure
what's going on with dependencies.  What's the story here?

When sending a patch series it is important to ensure that all
the various maintainers understand what the relationship between
the patches as the expecation is that there will be
interdependencies.  Either copy everyone on the whole series or
at least copy them on the cover letter and explain what's going
on.  If there are no strong interdependencies then it's generally
simplest to just send the patches separately to avoid any
possible confusion.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 05/17] drivers: bus: simple-pm-bus: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 ` [PATCH 05/17] drivers: bus: simple-pm-bus: " Nick Alcock
@ 2023-03-03  7:52   ` Geert Uytterhoeven
  2023-03-03 18:32     ` Nick Alcock
  2023-03-20 10:58     ` Nick Alcock
  0 siblings, 2 replies; 47+ messages in thread
From: Geert Uytterhoeven @ 2023-03-03  7:52 UTC (permalink / raw)
  To: Nick Alcock; +Cc: mcgrof, linux-modules, linux-kernel, Hitomi Hasegawa

Hi Nick,

On Thu, Mar 2, 2023 at 11:25 PM Nick Alcock <nick.alcock@oracle.com> wrote:
> Since commit 8b41fc4454e ("kbuild: create modules.builtin without
> Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
> are used to identify modules. As a consequence, uses of the macro
> in non-modules will cause modprobe to misidentify their containing
> object file as a module when it is not (false positives), and modprobe
> might succeed rather than failing with a suitable error message.
>
> So remove it in the files in this commit, none of which can be built as
> modules.
>
> Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> Suggested-by: Luis Chamberlain <mcgrof@kernel.org>

Thanks for your patch!

> --- a/drivers/bus/simple-pm-bus.c
> +++ b/drivers/bus/simple-pm-bus.c
> @@ -92,4 +92,3 @@ module_platform_driver(simple_pm_bus_driver);
>
>  MODULE_DESCRIPTION("Simple Power-Managed Bus Driver");
>  MODULE_AUTHOR("Geert Uytterhoeven <geert+renesas@glider.be>");
> -MODULE_LICENSE("GPL v2");

Please do not remove this line as long as the file has no SPDX-License
tag.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 13/17] regulator: stm32-pwr: remove MODULE_LICENSE in non-modules
  2023-03-03  0:31   ` Mark Brown
@ 2023-03-03 18:30     ` Nick Alcock
  2023-03-04 20:12       ` Mark Brown
  0 siblings, 1 reply; 47+ messages in thread
From: Nick Alcock @ 2023-03-03 18:30 UTC (permalink / raw)
  To: Mark Brown
  Cc: mcgrof, linux-modules, linux-kernel, Hitomi Hasegawa,
	Liam Girdwood, Maxime Coquelin, Alexandre Torgue, linux-stm32,
	linux-arm-kernel

On 3 Mar 2023, Mark Brown outgrape:

> On Thu, Mar 02, 2023 at 09:17:55PM +0000, Nick Alcock wrote:
>> Since commit 8b41fc4454e ("kbuild: create modules.builtin without
>> Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
>> are used to identify modules. As a consequence, uses of the macro
>
> You've not copied me on the rest of the series so I'm not sure
> what's going on with dependencies.  What's the story here?

There are no interdependencies in this monster: it's just a pile of
individual tiny machine-generated patches, all doing the exact same
thing, and if and when they all make it in the invariant will finally
hold that all modules shown as 'tristate' in Kconfig will have .modinfo
in the resulting vmlinux when built in to the kernel, and
modules.builtin will report them as built-in; and nothing which is *not*
tristate will be reported in modules.builtin as a built-in module.
That's it.

(I don't expect them to all make it in in the first attempt, but I have
a checker which I'll run to figure out which ones didn't make it in and
try to deal with them, and run later at intervals to figure out if we
regress and fix any regressions. The only likely type of regression is
MODULE_LICENSE creeping into non-modules, because things that *can* be
built as modules that don't have a MODULE_LICENSE cause more fallout and
are spotted much faster.)

(This is clearing the way for a later patch which will have
interdependencies, but which is thankfully confined to a single
subsystem so everyone else can ignore it. It happens to need accurate
builtin module info at kallsyms-generation time, and this is the way
Luis wants that done.)

> When sending a patch series it is important to ensure that all
> the various maintainers understand what the relationship between
> the patches as the expecation is that there will be
> interdependencies.  Either copy everyone on the whole series or
> at least copy them on the cover letter and explain what's going
> on.  If there are no strong interdependencies then it's generally
> simplest to just send the patches separately to avoid any
> possible confusion.

The cover letter was sent to every related mailing list (or at least it
was for patch series 2 and 5+: scripting problems blocked 3 and 4,
sorry), which is what the LWN article on big patch series which I'm
following recommended: <https://lwn.net/Articles/585782/>. I didn't want
to spam actual maintainers with more info than that, since presumably
they follow related-according-to-maintainer.pl lists anyway.

As for copying everyone on a 121-patch monster like this... well, I
think everyone would have wanted to throttle me, and I'm not sure they'd
have been wrong.


Originally I did this whole thing as one massive patch, but I was asked
to split it up by subsystem. This yielded 121 tiny patches with distinct
subsystems and Cc: sets. Sending a 121-patch series was my original plan
but we talked to people first and they all said rough equivalents of
'god, no' and suggested splitting it up into a bunch of shorter
mini-series to reduce the load on people's mailboxes and brains.

I don't think anyone has previously suggested making it 121 individual
patches with no cover letter whatsoever. As it is, those series that
accidentally went out without cover letters properly Cc:ed confused some
maintainers because of the lack of the cover letter. My apologies.

It does seem this is an area where I can't please everyone. Some people
don't want to be Cc:ed, others want everyone Cc:ed on all of them: some
people want series, others want individual patches for everyone. I can't
do both. Sorry about that.

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 05/17] drivers: bus: simple-pm-bus: remove MODULE_LICENSE in non-modules
  2023-03-03  7:52   ` Geert Uytterhoeven
@ 2023-03-03 18:32     ` Nick Alcock
  2023-03-03 18:43       ` Geert Uytterhoeven
  2023-03-20 10:58     ` Nick Alcock
  1 sibling, 1 reply; 47+ messages in thread
From: Nick Alcock @ 2023-03-03 18:32 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: mcgrof, linux-modules, linux-kernel, Hitomi Hasegawa

On 3 Mar 2023, Geert Uytterhoeven told this:

> On Thu, Mar 2, 2023 at 11:25 PM Nick Alcock <nick.alcock@oracle.com> wrote:
>> --- a/drivers/bus/simple-pm-bus.c
>> +++ b/drivers/bus/simple-pm-bus.c
>> @@ -92,4 +92,3 @@ module_platform_driver(simple_pm_bus_driver);
>>
>>  MODULE_DESCRIPTION("Simple Power-Managed Bus Driver");
>>  MODULE_AUTHOR("Geert Uytterhoeven <geert+renesas@glider.be>");
>> -MODULE_LICENSE("GPL v2");
>
> Please do not remove this line as long as the file has no SPDX-License
> tag.

I'll augment this patch with an SPDX addition, if you think that's OK,
which it sounds like you do. (MODULE_LICENSE has side effects these days
which a SPDX header does not, and those side effects are wrong for
things that cannot be modules.)

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 05/17] drivers: bus: simple-pm-bus: remove MODULE_LICENSE in non-modules
  2023-03-03 18:32     ` Nick Alcock
@ 2023-03-03 18:43       ` Geert Uytterhoeven
  0 siblings, 0 replies; 47+ messages in thread
From: Geert Uytterhoeven @ 2023-03-03 18:43 UTC (permalink / raw)
  To: Nick Alcock; +Cc: mcgrof, linux-modules, linux-kernel, Hitomi Hasegawa

Hi Nick,

On Fri, Mar 3, 2023 at 7:32 PM Nick Alcock <nick.alcock@oracle.com> wrote:
> On 3 Mar 2023, Geert Uytterhoeven told this:
> > On Thu, Mar 2, 2023 at 11:25 PM Nick Alcock <nick.alcock@oracle.com> wrote:
> >> --- a/drivers/bus/simple-pm-bus.c
> >> +++ b/drivers/bus/simple-pm-bus.c
> >> @@ -92,4 +92,3 @@ module_platform_driver(simple_pm_bus_driver);
> >>
> >>  MODULE_DESCRIPTION("Simple Power-Managed Bus Driver");
> >>  MODULE_AUTHOR("Geert Uytterhoeven <geert+renesas@glider.be>");
> >> -MODULE_LICENSE("GPL v2");
> >
> > Please do not remove this line as long as the file has no SPDX-License
> > tag.
>
> I'll augment this patch with an SPDX addition, if you think that's OK,
> which it sounds like you do. (MODULE_LICENSE has side effects these days
> which a SPDX header does not, and those side effects are wrong for
> things that cannot be modules.)

Yeah, simple-pm-bus should not be a module.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 00/17] MODULE_LICENSE removals, sixth tranche
  2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
                   ` (16 preceding siblings ...)
  2023-03-02 21:17 ` [PATCH 17/17] zswap: " Nick Alcock
@ 2023-03-03 22:22 ` Luis Chamberlain
  2023-03-20 11:00   ` Nick Alcock
  17 siblings, 1 reply; 47+ messages in thread
From: Luis Chamberlain @ 2023-03-03 22:22 UTC (permalink / raw)
  To: Nick Alcock
  Cc: dri-devel, linux-fsdevel, linux-kernel, linux-media, linux-mm,
	linux-modules, x86

Stupid question, if you're removing MODULE_LICENSE() than why keep the
other stupid MODULE_*() crap too? If its of no use, be gone!

  Luis

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 13/17] regulator: stm32-pwr: remove MODULE_LICENSE in non-modules
  2023-03-03 18:30     ` Nick Alcock
@ 2023-03-04 20:12       ` Mark Brown
  0 siblings, 0 replies; 47+ messages in thread
From: Mark Brown @ 2023-03-04 20:12 UTC (permalink / raw)
  To: Nick Alcock
  Cc: mcgrof, linux-modules, linux-kernel, Hitomi Hasegawa,
	Liam Girdwood, Maxime Coquelin, Alexandre Torgue, linux-stm32,
	linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

On Fri, Mar 03, 2023 at 06:30:02PM +0000, Nick Alcock wrote:
> On 3 Mar 2023, Mark Brown outgrape:

> > on.  If there are no strong interdependencies then it's generally
> > simplest to just send the patches separately to avoid any
> > possible confusion.

> The cover letter was sent to every related mailing list (or at least it
> was for patch series 2 and 5+: scripting problems blocked 3 and 4,
> sorry), which is what the LWN article on big patch series which I'm
> following recommended: <https://lwn.net/Articles/585782/>. I didn't want
> to spam actual maintainers with more info than that, since presumably
> they follow related-according-to-maintainer.pl lists anyway.

> As for copying everyone on a 121-patch monster like this... well, I
> think everyone would have wanted to throttle me, and I'm not sure they'd
> have been wrong.

So given that there's no depenencies between the patches this
seems like a good candidate for not sending as a series in the
first place.

> I don't think anyone has previously suggested making it 121 individual
> patches with no cover letter whatsoever. As it is, those series that
> accidentally went out without cover letters properly Cc:ed confused some
> maintainers because of the lack of the cover letter. My apologies.

It's really quite common for people to just send lots of
individual patches when there's no interdependencies - a lot of
the generated cleanups do that.

> It does seem this is an area where I can't please everyone. Some people
> don't want to be Cc:ed, others want everyone Cc:ed on all of them: some
> people want series, others want individual patches for everyone. I can't
> do both. Sorry about that.

The important thing isn't so much the specific thing as making it
clear what's going on - if you send a series with no information
about the how the series should be handled it's unclear what's
going on.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 15/17] xen: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 ` [PATCH 15/17] xen: " Nick Alcock
@ 2023-03-06  7:45   ` Juergen Gross
  0 siblings, 0 replies; 47+ messages in thread
From: Juergen Gross @ 2023-03-06  7:45 UTC (permalink / raw)
  To: Nick Alcock, mcgrof
  Cc: linux-modules, linux-kernel, Hitomi Hasegawa, Stefano Stabellini,
	xen-devel


[-- Attachment #1.1.1: Type: text/plain, Size: 1025 bytes --]

On 02.03.23 22:17, Nick Alcock wrote:
> Since commit 8b41fc4454e ("kbuild: create modules.builtin without
> Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
> are used to identify modules. As a consequence, uses of the macro
> in non-modules will cause modprobe to misidentify their containing
> object file as a module when it is not (false positives), and modprobe
> might succeed rather than failing with a suitable error message.
> 
> So remove it in the files in this commit, none of which can be built as
> modules.
> 
> Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
> Cc: Luis Chamberlain <mcgrof@kernel.org>
> Cc: linux-modules@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: xen-devel@lists.xenproject.org

Reviewed-by: Juergen Gross <jgross@suse.com>


Juergen


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 11/17] unicode: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 ` [PATCH 11/17] unicode: " Nick Alcock
@ 2023-03-06 15:32   ` Gabriel Krisman Bertazi
  0 siblings, 0 replies; 47+ messages in thread
From: Gabriel Krisman Bertazi @ 2023-03-06 15:32 UTC (permalink / raw)
  To: Nick Alcock
  Cc: mcgrof, linux-modules, linux-kernel, Hitomi Hasegawa,
	Gabriel Krisman Bertazi, linux-fsdevel

Nick Alcock <nick.alcock@oracle.com> writes:

> Since commit 8b41fc4454e ("kbuild: create modules.builtin without
> Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
> are used to identify modules. As a consequence, uses of the macro
> in non-modules will cause modprobe to misidentify their containing
> object file as a module when it is not (false positives), and modprobe
> might succeed rather than failing with a suitable error message.
>
> So remove it in the files in this commit, none of which can be built as
> modules.
>
> Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
> Cc: Luis Chamberlain <mcgrof@kernel.org>
> Cc: linux-modules@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
> Cc: Gabriel Krisman Bertazi <krisman@collabora.com>
> Cc: linux-fsdevel@vger.kernel.org
> ---

Acked-by: Gabriel Krisman Bertazi <krisman@suse.de>

Thanks,

-- 
Gabriel Krisman Bertazi

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-02 21:17 ` [PATCH 10/17] tty: " Nick Alcock
@ 2023-03-09 16:15   ` Greg Kroah-Hartman
  2023-03-09 22:38     ` Luis Chamberlain
  0 siblings, 1 reply; 47+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-09 16:15 UTC (permalink / raw)
  To: Nick Alcock
  Cc: mcgrof, linux-modules, linux-kernel, Hitomi Hasegawa, Jiri Slaby

On Thu, Mar 02, 2023 at 09:17:52PM +0000, Nick Alcock wrote:
> Since commit 8b41fc4454e ("kbuild: create modules.builtin without
> Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
> are used to identify modules. As a consequence, uses of the macro
> in non-modules will cause modprobe to misidentify their containing
> object file as a module when it is not (false positives), and modprobe
> might succeed rather than failing with a suitable error message.
> 
> So remove it in the files in this commit, none of which can be built as
> modules.
> 
> Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
> Cc: Luis Chamberlain <mcgrof@kernel.org>
> Cc: linux-modules@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jiri Slaby <jirislaby@kernel.org>
> ---
>  drivers/tty/n_null.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c
> index f913b665af725..c24f75942c49d 100644
> --- a/drivers/tty/n_null.c
> +++ b/drivers/tty/n_null.c
> @@ -63,7 +63,6 @@ static void __exit n_null_exit(void)
>  module_init(n_null_init);
>  module_exit(n_null_exit);
>  
> -MODULE_LICENSE("GPL");
>  MODULE_AUTHOR("Alan Cox");
>  MODULE_ALIAS_LDISC(N_NULL);
>  MODULE_DESCRIPTION("Null ldisc driver");
> -- 
> 2.39.1.268.g9de2f9a303
> 

Nope, sorry, this is not good to do, please fix kbuild instead of
forcing a tree-wide change like this.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-09 16:15   ` Greg Kroah-Hartman
@ 2023-03-09 22:38     ` Luis Chamberlain
  2023-03-10  7:31       ` Greg Kroah-Hartman
  0 siblings, 1 reply; 47+ messages in thread
From: Luis Chamberlain @ 2023-03-09 22:38 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Masahiro Yamada, Thomas Gleixner, Christoph Hellwig
  Cc: Nick Alcock, linux-modules, linux-kernel, Hitomi Hasegawa, Jiri Slaby

On Thu, Mar 09, 2023 at 05:15:42PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Mar 02, 2023 at 09:17:52PM +0000, Nick Alcock wrote:
> > Since commit 8b41fc4454e ("kbuild: create modules.builtin without
> > Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
> > are used to identify modules. As a consequence, uses of the macro
> > in non-modules will cause modprobe to misidentify their containing
> > object file as a module when it is not (false positives), and modprobe
> > might succeed rather than failing with a suitable error message.
> > 
> > So remove it in the files in this commit, none of which can be built as
> > modules.
> > 
> > Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> > Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
> > Cc: Luis Chamberlain <mcgrof@kernel.org>
> > Cc: linux-modules@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Jiri Slaby <jirislaby@kernel.org>
> > ---
> >  drivers/tty/n_null.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c
> > index f913b665af725..c24f75942c49d 100644
> > --- a/drivers/tty/n_null.c
> > +++ b/drivers/tty/n_null.c
> > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void)
> >  module_init(n_null_init);
> >  module_exit(n_null_exit);
> >  
> > -MODULE_LICENSE("GPL");
> >  MODULE_AUTHOR("Alan Cox");
> >  MODULE_ALIAS_LDISC(N_NULL);
> >  MODULE_DESCRIPTION("Null ldisc driver");
> > -- 
> > 2.39.1.268.g9de2f9a303
> > 
> 
> Nope, sorry, this is not good to do, please fix kbuild instead of
> forcing a tree-wide change like this.

Masahiro Yamada already NACK'd it such effort:

https://lkml.kernel.org/r/CAK7LNAQLttPD=Ae==e0CYeQtS78=o_JZFK+zxa29JnUYio52Ug@mail.gmail.com

And his descriptiuon of the reasoning and logic is explained here:              

https://lore.kernel.org/all/CAK7LNASL7_RgfASstBvN6AzhR=nMU=HsQvODf5q13Xud8tBWRQ@mail.gmail.com/

Let me summarize it though with a few quotes from him:

"Having false-positives in modules.builtin should be OK"
"In this sense, having always-builtin entries in module.builtin is OK."

The reason Nick wants to do this work is that his future patches
(which have been under review for years and I'm starting to chew on
it and provide guidance on now) extend our ability to have more
elaborate symbol to address mapping with more metdata, which does
include information such as if something came from a module. So
long term *I* certainly am interested in a deterministic way to
determine if something could be a module.

For a more elaborate attempt on my part to try to describe the problem
and some side ideas I had if we wanted an alternative:

https://lore.kernel.org/all/Y/kXDqW+7d71C4wz@bombadil.infradead.org/

I should also mention Christoph has also suggested we eventually move
towards automatically generating the module license tag from the SPDX
tag:

https://lore.kernel.org/all/Y5BNCbFyvNA1Xp%2FX@infradead.org

I agree with Christoph and I think we should get there. For now we want
1-1 mapping of real modules to the tag for both reasons of us not going
to revert 8b41fc4454e and of later us wanting to do the full swoop
automation of the module license tag.

Although having modprobe not fail even if your module listed cannot be
a module is non-fatal, the long term goal of cleaning this up is
desirable anyway.

If you have constructive ways to provide an alternative for this in kbuild,
and help with the long term goals Nick has, patches or suggestions to
are greatly welcomed.

The simplest alternative I've come up with is the -DMODULE_POSSIBLE I
mentioned in the thread above. But as I mentioned in that same thread
the difficulty is in gathering the possible-obj-m without incurring a
slow down on the build.

  Luis

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-09 22:38     ` Luis Chamberlain
@ 2023-03-10  7:31       ` Greg Kroah-Hartman
  2023-03-10 19:33         ` Luis Chamberlain
  0 siblings, 1 reply; 47+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-10  7:31 UTC (permalink / raw)
  To: Luis Chamberlain
  Cc: Masahiro Yamada, Thomas Gleixner, Christoph Hellwig, Nick Alcock,
	linux-modules, linux-kernel, Hitomi Hasegawa, Jiri Slaby

On Thu, Mar 09, 2023 at 02:38:10PM -0800, Luis Chamberlain wrote:
> On Thu, Mar 09, 2023 at 05:15:42PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Mar 02, 2023 at 09:17:52PM +0000, Nick Alcock wrote:
> > > Since commit 8b41fc4454e ("kbuild: create modules.builtin without
> > > Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
> > > are used to identify modules. As a consequence, uses of the macro
> > > in non-modules will cause modprobe to misidentify their containing
> > > object file as a module when it is not (false positives), and modprobe
> > > might succeed rather than failing with a suitable error message.
> > > 
> > > So remove it in the files in this commit, none of which can be built as
> > > modules.
> > > 
> > > Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> > > Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
> > > Cc: Luis Chamberlain <mcgrof@kernel.org>
> > > Cc: linux-modules@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Jiri Slaby <jirislaby@kernel.org>
> > > ---
> > >  drivers/tty/n_null.c | 1 -
> > >  1 file changed, 1 deletion(-)
> > > 
> > > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c
> > > index f913b665af725..c24f75942c49d 100644
> > > --- a/drivers/tty/n_null.c
> > > +++ b/drivers/tty/n_null.c
> > > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void)
> > >  module_init(n_null_init);
> > >  module_exit(n_null_exit);
> > >  
> > > -MODULE_LICENSE("GPL");
> > >  MODULE_AUTHOR("Alan Cox");
> > >  MODULE_ALIAS_LDISC(N_NULL);
> > >  MODULE_DESCRIPTION("Null ldisc driver");
> > > -- 
> > > 2.39.1.268.g9de2f9a303
> > > 
> > 
> > Nope, sorry, this is not good to do, please fix kbuild instead of
> > forcing a tree-wide change like this.
> 
> Masahiro Yamada already NACK'd it such effort:
> 
> https://lkml.kernel.org/r/CAK7LNAQLttPD=Ae==e0CYeQtS78=o_JZFK+zxa29JnUYio52Ug@mail.gmail.com
> 
> And his descriptiuon of the reasoning and logic is explained here:              
> 
> https://lore.kernel.org/all/CAK7LNASL7_RgfASstBvN6AzhR=nMU=HsQvODf5q13Xud8tBWRQ@mail.gmail.com/
> 
> Let me summarize it though with a few quotes from him:
> 
> "Having false-positives in modules.builtin should be OK"
> "In this sense, having always-builtin entries in module.builtin is OK."

None of that matters, sorry.

Again, all I am saying is that you can not have some MODULE_() macros
that are ok for code that is built in, and some that are not, for
"reasons" that have to do how you all are treating the build system
infrastructure as you are now putting arbritrary requirements for all
driver authors (of which there are thousands) to know this.

Just change the macros to work properly in both cases, I can't believe
this is all that hard as obviously all of the other macros work both
ways, right?  That should not require any kbuild changes.

> The reason Nick wants to do this work is that his future patches
> (which have been under review for years and I'm starting to chew on
> it and provide guidance on now) extend our ability to have more
> elaborate symbol to address mapping with more metdata, which does
> include information such as if something came from a module. So
> long term *I* certainly am interested in a deterministic way to
> determine if something could be a module.
> 
> For a more elaborate attempt on my part to try to describe the problem
> and some side ideas I had if we wanted an alternative:
> 
> https://lore.kernel.org/all/Y/kXDqW+7d71C4wz@bombadil.infradead.org/
> 
> I should also mention Christoph has also suggested we eventually move
> towards automatically generating the module license tag from the SPDX
> tag:
> 
> https://lore.kernel.org/all/Y5BNCbFyvNA1Xp%2FX@infradead.org

That too would be wonderful, and I would love to see that, but it does
not remove the base problem here that you are somehow forcing all driver
authors to change their code for the build system changes which should
not be affecting them at all at this point in time.

If you all do trigger off of the SPDX tags, then the removal of all
MODULE_LICENSE() instances would be great too, but I don't think you are
there yet (and it also wouldn't require removal all at once as you could
just stub out that macro to be nothing.)  But this is not the real issue
here...

Maybe the solution is to stop triggering on MODULE_LICENSE() as
something magic for the build, as obviously that is the root problem
here.  Or something else, I don't know, but what you all are doing here
does not seem correct at all, sorry, and is only going to cause more
long-term problems with maintenance and headaches for driver authors.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-10  7:31       ` Greg Kroah-Hartman
@ 2023-03-10 19:33         ` Luis Chamberlain
  2023-03-24  9:08           ` Geert Uytterhoeven
  0 siblings, 1 reply; 47+ messages in thread
From: Luis Chamberlain @ 2023-03-10 19:33 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Masahiro Yamada, Thomas Gleixner, Christoph Hellwig, Nick Alcock,
	linux-modules, linux-kernel, Hitomi Hasegawa, Jiri Slaby

On Fri, Mar 10, 2023 at 08:31:30AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Mar 09, 2023 at 02:38:10PM -0800, Luis Chamberlain wrote:
> > On Thu, Mar 09, 2023 at 05:15:42PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Mar 02, 2023 at 09:17:52PM +0000, Nick Alcock wrote:
> > > > Since commit 8b41fc4454e ("kbuild: create modules.builtin without
> > > > Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
> > > > are used to identify modules. As a consequence, uses of the macro
> > > > in non-modules will cause modprobe to misidentify their containing
> > > > object file as a module when it is not (false positives), and modprobe
> > > > might succeed rather than failing with a suitable error message.
> > > > 
> > > > So remove it in the files in this commit, none of which can be built as
> > > > modules.
> > > > 
> > > > Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> > > > Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
> > > > Cc: Luis Chamberlain <mcgrof@kernel.org>
> > > > Cc: linux-modules@vger.kernel.org
> > > > Cc: linux-kernel@vger.kernel.org
> > > > Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > Cc: Jiri Slaby <jirislaby@kernel.org>
> > > > ---
> > > >  drivers/tty/n_null.c | 1 -
> > > >  1 file changed, 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c
> > > > index f913b665af725..c24f75942c49d 100644
> > > > --- a/drivers/tty/n_null.c
> > > > +++ b/drivers/tty/n_null.c
> > > > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void)
> > > >  module_init(n_null_init);
> > > >  module_exit(n_null_exit);
> > > >  
> > > > -MODULE_LICENSE("GPL");
> > > >  MODULE_AUTHOR("Alan Cox");
> > > >  MODULE_ALIAS_LDISC(N_NULL);
> > > >  MODULE_DESCRIPTION("Null ldisc driver");
> > > > -- 
> > > > 2.39.1.268.g9de2f9a303
> > > > 
> > > 
> > > Nope, sorry, this is not good to do, please fix kbuild instead of
> > > forcing a tree-wide change like this.
> > 
> > Masahiro Yamada already NACK'd it such effort:
> > 
> > https://lkml.kernel.org/r/CAK7LNAQLttPD=Ae==e0CYeQtS78=o_JZFK+zxa29JnUYio52Ug@mail.gmail.com
> > 
> > And his descriptiuon of the reasoning and logic is explained here:              
> > 
> > https://lore.kernel.org/all/CAK7LNASL7_RgfASstBvN6AzhR=nMU=HsQvODf5q13Xud8tBWRQ@mail.gmail.com/
> > 
> > Let me summarize it though with a few quotes from him:
> > 
> > "Having false-positives in modules.builtin should be OK"
> > "In this sense, having always-builtin entries in module.builtin is OK."
> 
> None of that matters, sorry.
> 
> Again, all I am saying is that you can not have some MODULE_() macros
> that are ok for code that is built in, and some that are not, for
> "reasons" that have to do how you all are treating the build system
> infrastructure as you are now putting arbritrary requirements for all
> driver authors (of which there are thousands) to know this.

As noted once again, it is not putting hard requirement. Future tooling
not yet added would just not benefit from distinguishing symbols for
your modules.

I'm happy to live with module authors not wanting to remove the module
license tag from their modules if they can never actually be modules
from not benefitting from the above tooling gains as its just cherry
on top tooling gains.

Solving this in way that does not impeed on current build system
improvements is a challenge and I'm happy to punt that out to future
work.

> Just change the macros to work properly in both cases, I can't believe
> this is all that hard as obviously all of the other macros work both
> ways, right?  That should not require any kbuild changes.

Patches are welcomed.

> > The reason Nick wants to do this work is that his future patches
> > (which have been under review for years and I'm starting to chew on
> > it and provide guidance on now) extend our ability to have more
> > elaborate symbol to address mapping with more metdata, which does
> > include information such as if something came from a module. So
> > long term *I* certainly am interested in a deterministic way to
> > determine if something could be a module.
> > 
> > For a more elaborate attempt on my part to try to describe the problem
> > and some side ideas I had if we wanted an alternative:
> > 
> > https://lore.kernel.org/all/Y/kXDqW+7d71C4wz@bombadil.infradead.org/
> > 
> > I should also mention Christoph has also suggested we eventually move
> > towards automatically generating the module license tag from the SPDX
> > tag:
> > 
> > https://lore.kernel.org/all/Y5BNCbFyvNA1Xp%2FX@infradead.org
> 
> That too would be wonderful, and I would love to see that, but it does
> not remove the base problem here that you are somehow forcing all driver
> authors to change their code for the build system changes which should
> not be affecting them at all at this point in time.

By you, you mean Masahiro Yamada's patch. That is just collateral for
tooling being built upon by Nick.  And as Masahiro has pointed out
more than once already, this is not a regression / fatal issue.

> If you all do trigger off of the SPDX tags, then the removal of all
> MODULE_LICENSE() instances would be great too, but I don't think you are
> there yet (and it also wouldn't require removal all at once as you could
> just stub out that macro to be nothing.)  But this is not the real issue
> here...

That's future work.

> Maybe the solution is to stop triggering on MODULE_LICENSE() as
> something magic for the build, as obviously that is the root problem
> here.  Or something else, I don't know, but what you all are doing here
> does not seem correct at all, sorry, and is only going to cause more
> long-term problems with maintenance and headaches for driver authors.

I already suggested what I think *could* be done as an alternative and
the problem is not easy to resolve.

Feel free to ignore the patches for your drivers which remove the module
macros even if they are not modules. In lieu of alternative suggestions,
that's what we have now, and it is much better than what Nick was suggesting
before which Masahiro NACK'd.

Most other module developers seem happy with the change, and this has also
helped fix SPDX tags where there wasn't some too.

So if you don't take the patches it is not the end of the world and Nick
can move on with that effort for folks who do want to clarify this.

  Luis

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 05/17] drivers: bus: simple-pm-bus: remove MODULE_LICENSE in non-modules
  2023-03-03  7:52   ` Geert Uytterhoeven
  2023-03-03 18:32     ` Nick Alcock
@ 2023-03-20 10:58     ` Nick Alcock
  1 sibling, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-20 10:58 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: mcgrof, linux-modules, linux-kernel, Hitomi Hasegawa

On 3 Mar 2023, Geert Uytterhoeven told this:

>> --- a/drivers/bus/simple-pm-bus.c
>> +++ b/drivers/bus/simple-pm-bus.c
>> @@ -92,4 +92,3 @@ module_platform_driver(simple_pm_bus_driver);
>>
>>  MODULE_DESCRIPTION("Simple Power-Managed Bus Driver");
>>  MODULE_AUTHOR("Geert Uytterhoeven <geert+renesas@glider.be>");
>> -MODULE_LICENSE("GPL v2");
>
> Please do not remove this line as long as the file has no SPDX-License
> tag.

OK, in the next (final?) round this patch will have what I think is the
right SPDX:

diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
index 7afe1947e1c08..4da77ca7b75aa 100644
--- a/drivers/bus/simple-pm-bus.c
+++ b/drivers/bus/simple-pm-bus.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Simple Power-Managed Bus Driver
  *
@@ -138,4 +139,3 @@ module_platform_driver(simple_pm_bus_driver);
 
 MODULE_DESCRIPTION("Simple Power-Managed Bus Driver");
 MODULE_AUTHOR("Geert Uytterhoeven <geert+renesas@glider.be>");
-MODULE_LICENSE("GPL v2");
-- 
2.39.1.268.g9de2f9a303

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* Re: [PATCH 00/17] MODULE_LICENSE removals, sixth tranche
  2023-03-03 22:22 ` [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Luis Chamberlain
@ 2023-03-20 11:00   ` Nick Alcock
  0 siblings, 0 replies; 47+ messages in thread
From: Nick Alcock @ 2023-03-20 11:00 UTC (permalink / raw)
  To: Luis Chamberlain
  Cc: Nick Alcock, dri-devel, linux-fsdevel, linux-kernel, linux-media,
	linux-mm, linux-modules, x86

(Sorry about this, MTA delivered a bunch of stuff very late.)

On 3 Mar 2023, Luis Chamberlain verbalised:

> Stupid question, if you're removing MODULE_LICENSE() than why keep the
> other stupid MODULE_*() crap too? If its of no use, be gone!

I wish, but when I tried it it broke stuff. At least some MODULE_ things
have side effects -- MODULE_DEVICE_TABLE, maybe MODULE_ALIAS etc...

... and also I was getting complaints when I sent a tree out that did
that, along the lines of "if MODULE_LICENSE is the problem why not just
remove that". It seems one cannot win here, both options elicit
complaints.

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-10 19:33         ` Luis Chamberlain
@ 2023-03-24  9:08           ` Geert Uytterhoeven
  2023-03-24  9:12             ` Geert Uytterhoeven
  2023-03-24  9:14             ` Greg Kroah-Hartman
  0 siblings, 2 replies; 47+ messages in thread
From: Geert Uytterhoeven @ 2023-03-24  9:08 UTC (permalink / raw)
  To: Luis Chamberlain
  Cc: Greg Kroah-Hartman, Masahiro Yamada, Thomas Gleixner,
	Christoph Hellwig, Nick Alcock, linux-modules, linux-kernel,
	Hitomi Hasegawa, Jiri Slaby

On Fri, Mar 10, 2023 at 8:42 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> On Fri, Mar 10, 2023 at 08:31:30AM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Mar 09, 2023 at 02:38:10PM -0800, Luis Chamberlain wrote:
> > > On Thu, Mar 09, 2023 at 05:15:42PM +0100, Greg Kroah-Hartman wrote:
> > > > On Thu, Mar 02, 2023 at 09:17:52PM +0000, Nick Alcock wrote:
> > > > > Since commit 8b41fc4454e ("kbuild: create modules.builtin without
> > > > > Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
> > > > > are used to identify modules. As a consequence, uses of the macro
> > > > > in non-modules will cause modprobe to misidentify their containing
> > > > > object file as a module when it is not (false positives), and modprobe
> > > > > might succeed rather than failing with a suitable error message.
> > > > >
> > > > > So remove it in the files in this commit, none of which can be built as
> > > > > modules.
> > > > >
> > > > > Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> > > > > Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
> > > > > Cc: Luis Chamberlain <mcgrof@kernel.org>
> > > > > Cc: linux-modules@vger.kernel.org
> > > > > Cc: linux-kernel@vger.kernel.org
> > > > > Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
> > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > Cc: Jiri Slaby <jirislaby@kernel.org>
> > > > > ---
> > > > >  drivers/tty/n_null.c | 1 -
> > > > >  1 file changed, 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c
> > > > > index f913b665af725..c24f75942c49d 100644
> > > > > --- a/drivers/tty/n_null.c
> > > > > +++ b/drivers/tty/n_null.c
> > > > > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void)
> > > > >  module_init(n_null_init);
> > > > >  module_exit(n_null_exit);
> > > > >
> > > > > -MODULE_LICENSE("GPL");
> > > > >  MODULE_AUTHOR("Alan Cox");
> > > > >  MODULE_ALIAS_LDISC(N_NULL);
> > > > >  MODULE_DESCRIPTION("Null ldisc driver");
> > > > > --
> > > > > 2.39.1.268.g9de2f9a303
> > > > >
> > > >
> > > > Nope, sorry, this is not good to do, please fix kbuild instead of
> > > > forcing a tree-wide change like this.
> > >
> > > Masahiro Yamada already NACK'd it such effort:
> > >
> > > https://lkml.kernel.org/r/CAK7LNAQLttPD=Ae==e0CYeQtS78=o_JZFK+zxa29JnUYio52Ug@mail.gmail.com
> > >
> > > And his descriptiuon of the reasoning and logic is explained here:
> > >
> > > https://lore.kernel.org/all/CAK7LNASL7_RgfASstBvN6AzhR=nMU=HsQvODf5q13Xud8tBWRQ@mail.gmail.com/
> > >
> > > Let me summarize it though with a few quotes from him:
> > >
> > > "Having false-positives in modules.builtin should be OK"
> > > "In this sense, having always-builtin entries in module.builtin is OK."
> >
> > None of that matters, sorry.
> >
> > Again, all I am saying is that you can not have some MODULE_() macros
> > that are ok for code that is built in, and some that are not, for
> > "reasons" that have to do how you all are treating the build system
> > infrastructure as you are now putting arbritrary requirements for all
> > driver authors (of which there are thousands) to know this.
>
> As noted once again, it is not putting hard requirement. Future tooling
> not yet added would just not benefit from distinguishing symbols for
> your modules.
>
> I'm happy to live with module authors not wanting to remove the module
> license tag from their modules if they can never actually be modules
> from not benefitting from the above tooling gains as its just cherry
> on top tooling gains.

Apparently lots of these patches have not arrived in linux-next
without Acks (we're still discussing about this, right???).

And some of the modified files have no SPDX-License-Identifier
lines yet, so we are losing important licensing information:

$ git grep -L SPDX-License-Identifier -- $(git show $(git log
--oneline v6.3-rc1..linux-next/master | grep "remove MODULE_LICENSE in
non-modules" | cut -d " " -f 1) | lsdiff --strip=1)
drivers/bus/arm-cci.c
drivers/bus/imx-weim.c
drivers/bus/simple-pm-bus.c
drivers/gpu/drm/drm_mipi_dsi.c
drivers/irqchip/irq-mvebu-pic.c
drivers/reset/reset-axs10x.c
drivers/reset/reset-hsdk.c
drivers/soc/sunxi/sunxi_sram.c
drivers/video/fbdev/asiliantfb.c
drivers/video/fbdev/gbefb.c
drivers/video/fbdev/imsttfb.c
drivers/xen/xenbus/xenbus_probe.c
lib/glob.c

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-24  9:08           ` Geert Uytterhoeven
@ 2023-03-24  9:12             ` Geert Uytterhoeven
  2023-03-24  9:14             ` Greg Kroah-Hartman
  1 sibling, 0 replies; 47+ messages in thread
From: Geert Uytterhoeven @ 2023-03-24  9:12 UTC (permalink / raw)
  To: Luis Chamberlain
  Cc: Greg Kroah-Hartman, Masahiro Yamada, Thomas Gleixner,
	Christoph Hellwig, Nick Alcock, linux-modules, linux-kernel,
	Hitomi Hasegawa, Jiri Slaby

On Fri, Mar 24, 2023 at 10:08 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> And some of the modified files have no SPDX-License-Identifier
> lines yet, so we are losing important licensing information:
>
> $ git grep -L SPDX-License-Identifier -- $(git show $(git log
> --oneline v6.3-rc1..linux-next/master | grep "remove MODULE_LICENSE in
> non-modules" | cut -d " " -f 1) | lsdiff --strip=1)
> drivers/bus/arm-cci.c
> drivers/bus/imx-weim.c
> drivers/bus/simple-pm-bus.c
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is a false-positive, as I grepped against my current tree.
> drivers/gpu/drm/drm_mipi_dsi.c
> drivers/irqchip/irq-mvebu-pic.c
> drivers/reset/reset-axs10x.c
> drivers/reset/reset-hsdk.c
> drivers/soc/sunxi/sunxi_sram.c
> drivers/video/fbdev/asiliantfb.c
> drivers/video/fbdev/gbefb.c
> drivers/video/fbdev/imsttfb.c
> drivers/xen/xenbus/xenbus_probe.c
> lib/glob.c

You want to use instead:
git grep -L SPDX-License-Identifier linux-next/master  -- $(git show
$(git log --oneline v6.3-rc1..linux-next/master | grep "remove
MODULE_LICENSE in non-modules" | cut -d " " -f 1) | lsdiff --strip=1)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-24  9:08           ` Geert Uytterhoeven
  2023-03-24  9:12             ` Geert Uytterhoeven
@ 2023-03-24  9:14             ` Greg Kroah-Hartman
  2023-03-24  9:16               ` Geert Uytterhoeven
  2023-03-26  4:52               ` Christoph Hellwig
  1 sibling, 2 replies; 47+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-24  9:14 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Luis Chamberlain, Masahiro Yamada, Thomas Gleixner,
	Christoph Hellwig, Nick Alcock, linux-modules, linux-kernel,
	Hitomi Hasegawa, Jiri Slaby

On Fri, Mar 24, 2023 at 10:08:17AM +0100, Geert Uytterhoeven wrote:
> On Fri, Mar 10, 2023 at 8:42 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > On Fri, Mar 10, 2023 at 08:31:30AM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Mar 09, 2023 at 02:38:10PM -0800, Luis Chamberlain wrote:
> > > > On Thu, Mar 09, 2023 at 05:15:42PM +0100, Greg Kroah-Hartman wrote:
> > > > > On Thu, Mar 02, 2023 at 09:17:52PM +0000, Nick Alcock wrote:
> > > > > > Since commit 8b41fc4454e ("kbuild: create modules.builtin without
> > > > > > Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
> > > > > > are used to identify modules. As a consequence, uses of the macro
> > > > > > in non-modules will cause modprobe to misidentify their containing
> > > > > > object file as a module when it is not (false positives), and modprobe
> > > > > > might succeed rather than failing with a suitable error message.
> > > > > >
> > > > > > So remove it in the files in this commit, none of which can be built as
> > > > > > modules.
> > > > > >
> > > > > > Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> > > > > > Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
> > > > > > Cc: Luis Chamberlain <mcgrof@kernel.org>
> > > > > > Cc: linux-modules@vger.kernel.org
> > > > > > Cc: linux-kernel@vger.kernel.org
> > > > > > Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
> > > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > > Cc: Jiri Slaby <jirislaby@kernel.org>
> > > > > > ---
> > > > > >  drivers/tty/n_null.c | 1 -
> > > > > >  1 file changed, 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c
> > > > > > index f913b665af725..c24f75942c49d 100644
> > > > > > --- a/drivers/tty/n_null.c
> > > > > > +++ b/drivers/tty/n_null.c
> > > > > > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void)
> > > > > >  module_init(n_null_init);
> > > > > >  module_exit(n_null_exit);
> > > > > >
> > > > > > -MODULE_LICENSE("GPL");
> > > > > >  MODULE_AUTHOR("Alan Cox");
> > > > > >  MODULE_ALIAS_LDISC(N_NULL);
> > > > > >  MODULE_DESCRIPTION("Null ldisc driver");
> > > > > > --
> > > > > > 2.39.1.268.g9de2f9a303
> > > > > >
> > > > >
> > > > > Nope, sorry, this is not good to do, please fix kbuild instead of
> > > > > forcing a tree-wide change like this.
> > > >
> > > > Masahiro Yamada already NACK'd it such effort:
> > > >
> > > > https://lkml.kernel.org/r/CAK7LNAQLttPD=Ae==e0CYeQtS78=o_JZFK+zxa29JnUYio52Ug@mail.gmail.com
> > > >
> > > > And his descriptiuon of the reasoning and logic is explained here:
> > > >
> > > > https://lore.kernel.org/all/CAK7LNASL7_RgfASstBvN6AzhR=nMU=HsQvODf5q13Xud8tBWRQ@mail.gmail.com/
> > > >
> > > > Let me summarize it though with a few quotes from him:
> > > >
> > > > "Having false-positives in modules.builtin should be OK"
> > > > "In this sense, having always-builtin entries in module.builtin is OK."
> > >
> > > None of that matters, sorry.
> > >
> > > Again, all I am saying is that you can not have some MODULE_() macros
> > > that are ok for code that is built in, and some that are not, for
> > > "reasons" that have to do how you all are treating the build system
> > > infrastructure as you are now putting arbritrary requirements for all
> > > driver authors (of which there are thousands) to know this.
> >
> > As noted once again, it is not putting hard requirement. Future tooling
> > not yet added would just not benefit from distinguishing symbols for
> > your modules.
> >
> > I'm happy to live with module authors not wanting to remove the module
> > license tag from their modules if they can never actually be modules
> > from not benefitting from the above tooling gains as its just cherry
> > on top tooling gains.
> 
> Apparently lots of these patches have not arrived in linux-next
> without Acks (we're still discussing about this, right???).
> 
> And some of the modified files have no SPDX-License-Identifier
> lines yet, so we are losing important licensing information:
> 
> $ git grep -L SPDX-License-Identifier -- $(git show $(git log
> --oneline v6.3-rc1..linux-next/master | grep "remove MODULE_LICENSE in
> non-modules" | cut -d " " -f 1) | lsdiff --strip=1)
> drivers/bus/arm-cci.c
> drivers/bus/imx-weim.c
> drivers/bus/simple-pm-bus.c
> drivers/gpu/drm/drm_mipi_dsi.c
> drivers/irqchip/irq-mvebu-pic.c
> drivers/reset/reset-axs10x.c
> drivers/reset/reset-hsdk.c
> drivers/soc/sunxi/sunxi_sram.c
> drivers/video/fbdev/asiliantfb.c
> drivers/video/fbdev/gbefb.c
> drivers/video/fbdev/imsttfb.c
> drivers/xen/xenbus/xenbus_probe.c
> lib/glob.c

Ick, that's not ok at all.

Again, I strongly feel that removing MODULE_LICENSE() lines from files
that just don't happen to be built as a module is not ok as no other
MODULE_*() macro has this arbitrary restriction.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-24  9:14             ` Greg Kroah-Hartman
@ 2023-03-24  9:16               ` Geert Uytterhoeven
  2023-03-24 14:16                 ` Nick Alcock
  2023-03-26  4:52               ` Christoph Hellwig
  1 sibling, 1 reply; 47+ messages in thread
From: Geert Uytterhoeven @ 2023-03-24  9:16 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Luis Chamberlain, Masahiro Yamada, Thomas Gleixner,
	Christoph Hellwig, Nick Alcock, linux-modules, linux-kernel,
	Hitomi Hasegawa, Jiri Slaby

Hi Greg,

On Fri, Mar 24, 2023 at 10:14 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Fri, Mar 24, 2023 at 10:08:17AM +0100, Geert Uytterhoeven wrote:
> > On Fri, Mar 10, 2023 at 8:42 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > > On Fri, Mar 10, 2023 at 08:31:30AM +0100, Greg Kroah-Hartman wrote:
> > > > On Thu, Mar 09, 2023 at 02:38:10PM -0800, Luis Chamberlain wrote:
> > > > > On Thu, Mar 09, 2023 at 05:15:42PM +0100, Greg Kroah-Hartman wrote:
> > > > > > On Thu, Mar 02, 2023 at 09:17:52PM +0000, Nick Alcock wrote:
> > > > > > > Since commit 8b41fc4454e ("kbuild: create modules.builtin without
> > > > > > > Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
> > > > > > > are used to identify modules. As a consequence, uses of the macro
> > > > > > > in non-modules will cause modprobe to misidentify their containing
> > > > > > > object file as a module when it is not (false positives), and modprobe
> > > > > > > might succeed rather than failing with a suitable error message.
> > > > > > >
> > > > > > > So remove it in the files in this commit, none of which can be built as
> > > > > > > modules.
> > > > > > >
> > > > > > > Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> > > > > > > Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
> > > > > > > Cc: Luis Chamberlain <mcgrof@kernel.org>
> > > > > > > Cc: linux-modules@vger.kernel.org
> > > > > > > Cc: linux-kernel@vger.kernel.org
> > > > > > > Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
> > > > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > > > Cc: Jiri Slaby <jirislaby@kernel.org>
> > > > > > > ---
> > > > > > >  drivers/tty/n_null.c | 1 -
> > > > > > >  1 file changed, 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c
> > > > > > > index f913b665af725..c24f75942c49d 100644
> > > > > > > --- a/drivers/tty/n_null.c
> > > > > > > +++ b/drivers/tty/n_null.c
> > > > > > > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void)
> > > > > > >  module_init(n_null_init);
> > > > > > >  module_exit(n_null_exit);
> > > > > > >
> > > > > > > -MODULE_LICENSE("GPL");
> > > > > > >  MODULE_AUTHOR("Alan Cox");
> > > > > > >  MODULE_ALIAS_LDISC(N_NULL);
> > > > > > >  MODULE_DESCRIPTION("Null ldisc driver");
> > > > > > > --
> > > > > > > 2.39.1.268.g9de2f9a303
> > > > > > >
> > > > > >
> > > > > > Nope, sorry, this is not good to do, please fix kbuild instead of
> > > > > > forcing a tree-wide change like this.
> > > > >
> > > > > Masahiro Yamada already NACK'd it such effort:
> > > > >
> > > > > https://lkml.kernel.org/r/CAK7LNAQLttPD=Ae==e0CYeQtS78=o_JZFK+zxa29JnUYio52Ug@mail.gmail.com
> > > > >
> > > > > And his descriptiuon of the reasoning and logic is explained here:
> > > > >
> > > > > https://lore.kernel.org/all/CAK7LNASL7_RgfASstBvN6AzhR=nMU=HsQvODf5q13Xud8tBWRQ@mail.gmail.com/
> > > > >
> > > > > Let me summarize it though with a few quotes from him:
> > > > >
> > > > > "Having false-positives in modules.builtin should be OK"
> > > > > "In this sense, having always-builtin entries in module.builtin is OK."
> > > >
> > > > None of that matters, sorry.
> > > >
> > > > Again, all I am saying is that you can not have some MODULE_() macros
> > > > that are ok for code that is built in, and some that are not, for
> > > > "reasons" that have to do how you all are treating the build system
> > > > infrastructure as you are now putting arbritrary requirements for all
> > > > driver authors (of which there are thousands) to know this.
> > >
> > > As noted once again, it is not putting hard requirement. Future tooling
> > > not yet added would just not benefit from distinguishing symbols for
> > > your modules.
> > >
> > > I'm happy to live with module authors not wanting to remove the module
> > > license tag from their modules if they can never actually be modules
> > > from not benefitting from the above tooling gains as its just cherry
> > > on top tooling gains.
> >
> > Apparently lots of these patches have not arrived in linux-next
> > without Acks (we're still discussing about this, right???).
> >
> > And some of the modified files have no SPDX-License-Identifier
> > lines yet, so we are losing important licensing information:
> >
> > $ git grep -L SPDX-License-Identifier -- $(git show $(git log
> > --oneline v6.3-rc1..linux-next/master | grep "remove MODULE_LICENSE in
> > non-modules" | cut -d " " -f 1) | lsdiff --strip=1)
> > drivers/bus/arm-cci.c
> > drivers/bus/imx-weim.c
> > drivers/bus/simple-pm-bus.c
> > drivers/gpu/drm/drm_mipi_dsi.c
> > drivers/irqchip/irq-mvebu-pic.c
> > drivers/reset/reset-axs10x.c
> > drivers/reset/reset-hsdk.c
> > drivers/soc/sunxi/sunxi_sram.c
> > drivers/video/fbdev/asiliantfb.c
> > drivers/video/fbdev/gbefb.c
> > drivers/video/fbdev/imsttfb.c
> > drivers/xen/xenbus/xenbus_probe.c
> > lib/glob.c
>
> Ick, that's not ok at all.
>
> Again, I strongly feel that removing MODULE_LICENSE() lines from files
> that just don't happen to be built as a module is not ok as no other
> MODULE_*() macro has this arbitrary restriction.

I (still) agree with that, and I saw similar comments from others as well.
Unfortunately these comments are spread across tens of threads :-(

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-24  9:16               ` Geert Uytterhoeven
@ 2023-03-24 14:16                 ` Nick Alcock
  2023-03-24 14:29                   ` Greg Kroah-Hartman
  0 siblings, 1 reply; 47+ messages in thread
From: Nick Alcock @ 2023-03-24 14:16 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Greg Kroah-Hartman, Luis Chamberlain, Masahiro Yamada,
	Thomas Gleixner, Christoph Hellwig, Nick Alcock, linux-modules,
	linux-kernel, Hitomi Hasegawa, Jiri Slaby

On 24 Mar 2023, Geert Uytterhoeven uttered the following:
> I (still) agree with that, and I saw similar comments from others as well.
> Unfortunately these comments are spread across tens of threads :-(

Ugh. Should I do this sort of thing in one big commit next time? That
would fix that problem, but at the cost of others. Lumping seems to me
to be troublesome because it makes it harder to accept/reject different
bits, but would it be *as* troublesome as this much splitting?

-- 
NULL && (void)

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-24 14:16                 ` Nick Alcock
@ 2023-03-24 14:29                   ` Greg Kroah-Hartman
  2023-03-24 18:06                     ` Luis Chamberlain
  0 siblings, 1 reply; 47+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-24 14:29 UTC (permalink / raw)
  To: Nick Alcock
  Cc: Geert Uytterhoeven, Luis Chamberlain, Masahiro Yamada,
	Thomas Gleixner, Christoph Hellwig, linux-modules, linux-kernel,
	Hitomi Hasegawa, Jiri Slaby

On Fri, Mar 24, 2023 at 02:16:03PM +0000, Nick Alcock wrote:
> On 24 Mar 2023, Geert Uytterhoeven uttered the following:
> > I (still) agree with that, and I saw similar comments from others as well.
> > Unfortunately these comments are spread across tens of threads :-(
> 
> Ugh. Should I do this sort of thing in one big commit next time? That
> would fix that problem, but at the cost of others. Lumping seems to me
> to be troublesome because it makes it harder to accept/reject different
> bits, but would it be *as* troublesome as this much splitting?

The problem is, some of us disagree that this should be done at all, so
reverting all of the individual parts is going to be hard now.

Please put back the license bits that you removed, as it is not a good
idea to remove that if the file does not have a SPDX entry at the very
least.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-24 14:29                   ` Greg Kroah-Hartman
@ 2023-03-24 18:06                     ` Luis Chamberlain
  2023-03-27 10:46                       ` Nick Alcock
  2023-04-13 20:24                       ` Luis Chamberlain
  0 siblings, 2 replies; 47+ messages in thread
From: Luis Chamberlain @ 2023-03-24 18:06 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Nick Alcock, Geert Uytterhoeven, Masahiro Yamada,
	Thomas Gleixner, Christoph Hellwig, linux-modules, linux-kernel,
	Hitomi Hasegawa, Jiri Slaby

On Fri, Mar 24, 2023 at 03:29:00PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 24, 2023 at 02:16:03PM +0000, Nick Alcock wrote:
> > On 24 Mar 2023, Geert Uytterhoeven uttered the following:
> > > I (still) agree with that, and I saw similar comments from others as well.
> > > Unfortunately these comments are spread across tens of threads :-(
> > 
> > Ugh. Should I do this sort of thing in one big commit next time? That
> > would fix that problem, but at the cost of others. Lumping seems to me
> > to be troublesome because it makes it harder to accept/reject different
> > bits, but would it be *as* troublesome as this much splitting?
> 
> The problem is, some of us disagree that this should be done at all, so
> reverting all of the individual parts is going to be hard now.
> 
> Please put back the license bits that you removed, as it is not a good
> idea to remove that if the file does not have a SPDX entry at the very
> least.

Nick, I've just dropped your series. Please only re-submit only for
files where the license is clear. The effort of clarifying licenses
on files where one doesn't have an SPDX tag is welcomed but can take
time and we'll need this anyway in the future to help later strive to
see if we can automatically generate the MODULE_LICENSE() from the
SPDX tags.

  Luis

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-24  9:14             ` Greg Kroah-Hartman
  2023-03-24  9:16               ` Geert Uytterhoeven
@ 2023-03-26  4:52               ` Christoph Hellwig
  1 sibling, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2023-03-26  4:52 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Geert Uytterhoeven, Luis Chamberlain, Masahiro Yamada,
	Thomas Gleixner, Christoph Hellwig, Nick Alcock, linux-modules,
	linux-kernel, Hitomi Hasegawa, Jiri Slaby

On Fri, Mar 24, 2023 at 10:14:15AM +0100, Greg Kroah-Hartman wrote:
> Again, I strongly feel that removing MODULE_LICENSE() lines from files
> that just don't happen to be built as a module is not ok as no other
> MODULE_*() macro has this arbitrary restriction.

Yes.  And it should probably have a use in the kernel by checking that
nothing license-incompatible ever gets linked into mvlinux.
At least until we can parse the SPDX tags directly and make use of that
instead.

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-24 18:06                     ` Luis Chamberlain
@ 2023-03-27 10:46                       ` Nick Alcock
  2023-03-27 11:43                         ` Greg Kroah-Hartman
  2023-04-13 20:24                       ` Luis Chamberlain
  1 sibling, 1 reply; 47+ messages in thread
From: Nick Alcock @ 2023-03-27 10:46 UTC (permalink / raw)
  To: Luis Chamberlain
  Cc: Greg Kroah-Hartman, Geert Uytterhoeven, Masahiro Yamada,
	Thomas Gleixner, Christoph Hellwig, linux-modules, linux-kernel,
	Hitomi Hasegawa, Jiri Slaby

On 24 Mar 2023, Luis Chamberlain spake thusly:

> On Fri, Mar 24, 2023 at 03:29:00PM +0100, Greg Kroah-Hartman wrote:
>> Please put back the license bits that you removed, as it is not a good
>> idea to remove that if the file does not have a SPDX entry at the very
>> least.
>
> Nick, I've just dropped your series.

Thanks, that's much easier than getting all those reverts in.
(Presumably the bits taken by other people can all stay.)

>                                      Please only re-submit only for
> files where the license is clear. The effort of clarifying licenses
> on files where one doesn't have an SPDX tag is welcomed but can take
> time and we'll need this anyway in the future to help later strive to
> see if we can automatically generate the MODULE_LICENSE() from the
> SPDX tags.

For now, I have an alternative that might be acceptable. I did a bit of
an audit and it's all a right mess (see below), with wild divergence
even when SPDX is present, GPL versus -only or GPL-2.0+ apparently
applied almost at random and some things being completely different (in
some cases they were both committed simultaneously and were inconsistent
from the moment the module was written). So many things are inconsistent
that kallmodsyms would call a lot of things modules that really aren't:
there is enough error that there probably be noticeable mistakes in
quite a high percentage of kernels.

But... for our purposes, we don't actually *mind* if non-modules list
things like licenses inconsistently in two different places. Removing
MODULE_LICENSE was a means, not an end. What we're actually interested
in doing is removing .modinfo in things that can't possibly be modules,
and since a .modinfo in a guaranteed-non-module is at best entirely
useless I don't think anyone could reasonably be opposed to that end
goal (though they might reasonably be unhappy about all the churn
involved in getting there). They object to the removal of the visible
MODULE_LICENSE() argument text string, not to the useless compile-time
effect of a MODULE_LICENSE in a non-module.

So how about, for the first three groups below (the groups where
MODULE_LICENSE and SPDX are inconsistent, or where a SPDX simply doesn't
exist), instead of removing the MODULE_LICENSE we replace it with an
identical call to a new macro named perhaps NONMODULE_LICENSE(), which
is defined in module.h as simply expanding to nothing, except possibly
emitting a compile-time error if it's ever used in a module? This more
clearly denotes what's going on, keeps the license string in the source
file on a nearly identical line (for whatever purpose it serves), drops
the spurious .modinfo that's causing trouble, and probably makes fewer
people unhappy?

(I'm probably missing something, but the only reason I can see for being
unhappy with this change is if you think the actual text string
MODULE_LICENSE has some sort of legal force that NONMODULE_LICENSE would
not have. Speaking as a genuine non-lawyer, the only argument anyone
could have for that would be customary use, I'd think; and in *that*
case we can fix it without even changing the MODULE_LICENSE text string
by introducing a #define at the top of each affected file which
redefines MODULE_LICENSE() to nothing for that file. But that's ugly: I
think I'd prefer NONMODULE_LICENSE().)

... does that seem more reasonable?


Anyway, the audit of licenses in files touched by (the remainig files
in) this series. Here are the instances that don't fit what seems to be
the usual rule:

arch/x86/crypto/blake2s-glue.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0 OR MIT
arch/x86/mm/debug_pagetables.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
drivers/bus/intel-ixp4xx-eb.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
drivers/bus/qcom-ebi2.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
drivers/clk/clk-bm1880.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0+
drivers/firmware/broadcom/bcm47xx_nvram.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-or-later
drivers/firmware/imx/imx-scu.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0+
drivers/firmware/imx/scu-pd.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0+
drivers/irqchip/irq-mbigen.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
drivers/irqchip/irq-renesas-rzg2l.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0
drivers/irqchip/irq-sl28cpld.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
drivers/pinctrl/mediatek/pinctrl-mt8188.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0
drivers/pinctrl/mediatek/pinctrl-mt8365.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0
drivers/pinctrl/renesas/pinctrl-rzv2m.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0
drivers/power/reset/gpio-restart.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
drivers/power/reset/ltc2952-poweroff.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-or-later
drivers/power/supply/wm97xx_battery.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
drivers/reset/reset-lantiq.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
drivers/reset/reset-microchip-sparx5.c:	ML: MODULE_LICENSE("Dual MIT/GPL");	SPDX: GPL-2.0+
drivers/reset/reset-mpfs.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
drivers/soc/apple/apple-pmgr-pwrstate.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only OR MIT
drivers/soc/tegra/cbb/tegra194-cbb.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0
drivers/soc/tegra/cbb/tegra234-cbb.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0
drivers/tty/n_null.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0
drivers/video/fbdev/vesafb.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
drivers/xen/grant-dma-ops.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
fs/binfmt_elf.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
fs/nfs_common/nfs_ssc.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
kernel/dma/map_benchmark.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
kernel/events/hw_breakpoint_test.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0
kernel/trace/rv/reactor_panic.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0
kernel/trace/rv/reactor_printk.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0
kernel/watch_queue.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0
lib/btree.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
lib/crypto/blake2s-generic.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0 OR MIT
lib/crypto/blake2s.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0 OR MIT
mm/zpool.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only

Here's the subset of that that isn't just GPL-versus-v2 mismatches, all
MIT-versus-GPL in different directions:

arch/x86/crypto/blake2s-glue.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0 OR MIT
drivers/reset/reset-microchip-sparx5.c:	ML: MODULE_LICENSE("Dual MIT/GPL");	SPDX: GPL-2.0+
drivers/soc/apple/apple-pmgr-pwrstate.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only OR MIT
lib/crypto/blake2s-generic.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0 OR MIT
lib/crypto/blake2s.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0 OR MIT

Here are the ones that don't have SPDX at all:

drivers/bus/arm-cci.c:	ML: MODULE_LICENSE("GPL");	SPDX: 
drivers/bus/imx-weim.c:	ML: MODULE_LICENSE("GPL");	SPDX: 
drivers/bus/simple-pm-bus.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: 
drivers/gpu/drm/drm_mipi_dsi.c:	ML: MODULE_LICENSE("GPL and additional rights");	SPDX: 
drivers/reset/reset-axs10x.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: 
drivers/reset/reset-hsdk.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: 
drivers/video/console/vgacon.c:	ML: MODULE_LICENSE("GPL");	SPDX: 
drivers/video/fbdev/asiliantfb.c:	ML: MODULE_LICENSE("GPL");	SPDX: 
drivers/video/fbdev/gbefb.c:	ML: MODULE_LICENSE("GPL");	SPDX: 
drivers/video/fbdev/imsttfb.c:	ML: MODULE_LICENSE("GPL");	SPDX: 
drivers/xen/xenbus/xenbus_probe.c:	ML: MODULE_LICENSE("GPL");	SPDX: 
lib/glob.c:	ML: MODULE_LICENSE("Dual MIT/GPL");	SPDX: 

Here are all the others (verified largely by eye, so there might be a
few errors) -- the majority, but only just:

crypto/asymmetric_keys/asymmetric_type.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-or-later
drivers/accessibility/braille/braille_console.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-or-later
drivers/amba/tegra-ahb.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/android/binder.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/bus/arm-integrator-lm.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/bus/bt1-apb.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/bus/bt1-axi.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/bus/qcom-ssc-block-bus.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/clk/microchip/clk-mpfs.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
drivers/clk/renesas/renesas-cpg-mssr.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/clk/renesas/rzg2l-cpg.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/clocksource/em_sti.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/clocksource/sh_cmt.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/clocksource/sh_mtu2.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/clocksource/sh_tmu.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/clocksource/timer-stm32-lp.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/clocksource/timer-tegra186.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/clocksource/timer-ti-dm.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0+
drivers/dma-buf/heaps/cma_heap.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/dma-buf/heaps/system_heap.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/dma-buf/udmabuf.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/dma/ep93xx_dma.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-or-later
drivers/dma/ipu/ipu_idmac.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/dma/mv_xor_v2.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-or-later
drivers/dma/sh/shdma-base.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/dma/stm32-dmamux.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/dma/stm32-mdma.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/edac/altera_edac.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/hwspinlock/hwspinlock_core.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/interconnect/core.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/iommu/sun50i-iommu.c:	ML: MODULE_LICENSE("Dual BSD/GPL");	SPDX: (GPL-2.0-only OR BSD-2-Clause)
drivers/irqchip/irq-al-fic.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/irqchip/irq-ls-scfg-msi.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/irqchip/irq-mchp-eic.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/irqchip/irq-mvebu-pic.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: 
drivers/irqchip/irq-renesas-intc-irqpin.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/irqchip/irq-renesas-irqc.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/irqchip/irq-renesas-rza1.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/irqchip/irq-ti-sci-inta.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/irqchip/irq-ti-sci-intr.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/mailbox/rockchip-mailbox.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/mfd/altera-sysmgr.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/nvmem/core.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/perf/apple_m1_cpu_pmu.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/phy/intel/phy-intel-lgm-combo.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/pinctrl/actions/pinctrl-s500.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0+
drivers/pinctrl/actions/pinctrl-s700.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0+
drivers/pinctrl/actions/pinctrl-s900.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0+
drivers/pinctrl/bcm/pinctrl-ns.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/pinctrl/mediatek/pinctrl-mt8192.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/pinctrl/pinctrl-amd.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/pinctrl/renesas/pinctrl-rza1.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/pinctrl/renesas/pinctrl-rza2.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/pinctrl/renesas/pinctrl-rzg2l.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/pinctrl/renesas/pinctrl-rzn1.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/power/reset/as3722-poweroff.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/power/reset/gpio-poweroff.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/power/reset/keystone-reset.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/power/reset/mt6323-poweroff.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/power/reset/regulator-poweroff.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/power/reset/restart-poweroff.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/power/reset/tps65086-restart.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/power/supply/power_supply_core.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-only
drivers/regulator/stm32-pwr.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
drivers/remoteproc/remoteproc_core.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/soc/fujitsu/a64fx-diag.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/tty/serial/imx_earlycon.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0+
drivers/tty/serial/rda-uart.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0+
drivers/video/fbdev/mmp/hw/mmp_ctrl.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-or-later
drivers/video/fbdev/mmp/panel/tpo_tj032md01bw.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-or-later
drivers/video/fbdev/wm8505fb.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
drivers/video/fbdev/wmt_ge_rops.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0-only
fs/unicode/utf8-core.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: SPDX-License-Identifier: GPL-2.0
lib/pldmfw/pldmfw.c:	ML: MODULE_LICENSE("GPL v2");	SPDX: GPL-2.0
lib/test_fprobe.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-or-later
mm/zswap.c:	ML: MODULE_LICENSE("GPL");	SPDX: GPL-2.0-or-later

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-27 10:46                       ` Nick Alcock
@ 2023-03-27 11:43                         ` Greg Kroah-Hartman
  2023-03-27 14:54                           ` Nick Alcock
  0 siblings, 1 reply; 47+ messages in thread
From: Greg Kroah-Hartman @ 2023-03-27 11:43 UTC (permalink / raw)
  To: Nick Alcock
  Cc: Luis Chamberlain, Geert Uytterhoeven, Masahiro Yamada,
	Thomas Gleixner, Christoph Hellwig, linux-modules, linux-kernel,
	Hitomi Hasegawa, Jiri Slaby

On Mon, Mar 27, 2023 at 11:46:34AM +0100, Nick Alcock wrote:
> On 24 Mar 2023, Luis Chamberlain spake thusly:
> 
> > On Fri, Mar 24, 2023 at 03:29:00PM +0100, Greg Kroah-Hartman wrote:
> >> Please put back the license bits that you removed, as it is not a good
> >> idea to remove that if the file does not have a SPDX entry at the very
> >> least.
> >
> > Nick, I've just dropped your series.
> 
> Thanks, that's much easier than getting all those reverts in.
> (Presumably the bits taken by other people can all stay.)
> 
> >                                      Please only re-submit only for
> > files where the license is clear. The effort of clarifying licenses
> > on files where one doesn't have an SPDX tag is welcomed but can take
> > time and we'll need this anyway in the future to help later strive to
> > see if we can automatically generate the MODULE_LICENSE() from the
> > SPDX tags.
> 
> For now, I have an alternative that might be acceptable. I did a bit of
> an audit and it's all a right mess (see below), with wild divergence
> even when SPDX is present, GPL versus -only or GPL-2.0+ apparently
> applied almost at random and some things being completely different (in
> some cases they were both committed simultaneously and were inconsistent
> from the moment the module was written). So many things are inconsistent
> that kallmodsyms would call a lot of things modules that really aren't:
> there is enough error that there probably be noticeable mistakes in
> quite a high percentage of kernels.

As you have found out, there is a difference that matters in the SPDX
lines vs the MODULE_LICENSE lines when it comes to GPL vs GPLv2+ stuff.
The SPDX lines are correct for the code itself, while the MODULE_LICENSE
lines are correct from a "this is the license of this binary" point of
view.

So don't get confused here, if you all can figure out a way to generate
the MODULE_LICENSE() lines from SPDX, that would be great, but in my
quick look I think it's going to be very difficult (think about how
multiple files make up a single module binary...)

good luck!

> But... for our purposes, we don't actually *mind* if non-modules list
> things like licenses inconsistently in two different places. Removing
> MODULE_LICENSE was a means, not an end. What we're actually interested
> in doing is removing .modinfo in things that can't possibly be modules,
> and since a .modinfo in a guaranteed-non-module is at best entirely
> useless I don't think anyone could reasonably be opposed to that end
> goal (though they might reasonably be unhappy about all the churn
> involved in getting there). They object to the removal of the visible
> MODULE_LICENSE() argument text string, not to the useless compile-time
> effect of a MODULE_LICENSE in a non-module.

there are other things that create .modinfo lines, so I'm confused why
you picked the license line to trigger all of this.

> So how about, for the first three groups below (the groups where
> MODULE_LICENSE and SPDX are inconsistent, or where a SPDX simply doesn't
> exist), instead of removing the MODULE_LICENSE we replace it with an
> identical call to a new macro named perhaps NONMODULE_LICENSE(), which
> is defined in module.h as simply expanding to nothing, except possibly
> emitting a compile-time error if it's ever used in a module? This more
> clearly denotes what's going on, keeps the license string in the source
> file on a nearly identical line (for whatever purpose it serves), drops
> the spurious .modinfo that's causing trouble, and probably makes fewer
> people unhappy?

Again, no, why aren't you just stubbing out MODULE_LICENSE() in the
build if it's not being built as a module like the other MODULE_*()
macros are?  Why is the license so special here yet the device list or
module authors not?

Don't treat this macro as somehow special where authors have to remember
to not use it (or to use it), while the other MODULE_* macros do not
have the issue?

That's my main objection here.  Don't get confused by the license stuff,
that's secondary.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-27 11:43                         ` Greg Kroah-Hartman
@ 2023-03-27 14:54                           ` Nick Alcock
  2023-03-27 18:23                             ` Nick Alcock
  0 siblings, 1 reply; 47+ messages in thread
From: Nick Alcock @ 2023-03-27 14:54 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Nick Alcock, Luis Chamberlain, Geert Uytterhoeven,
	Thomas Gleixner, Christoph Hellwig, linux-modules, linux-kernel,
	Hitomi Hasegawa, Jiri Slaby

On 27 Mar 2023, Greg Kroah-Hartman told this:

> On Mon, Mar 27, 2023 at 11:46:34AM +0100, Nick Alcock wrote:
>> On 24 Mar 2023, Luis Chamberlain spake thusly:
>> >                                      Please only re-submit only for
>> > files where the license is clear. The effort of clarifying licenses
>> > on files where one doesn't have an SPDX tag is welcomed but can take
>> > time and we'll need this anyway in the future to help later strive to
>> > see if we can automatically generate the MODULE_LICENSE() from the
>> > SPDX tags.
>> 
>> For now, I have an alternative that might be acceptable. I did a bit of
>> an audit and it's all a right mess (see below), with wild divergence
>> even when SPDX is present, GPL versus -only or GPL-2.0+ apparently
>> applied almost at random and some things being completely different (in
>> some cases they were both committed simultaneously and were inconsistent
>> from the moment the module was written). So many things are inconsistent
>> that kallmodsyms would call a lot of things modules that really aren't:
>> there is enough error that there probably be noticeable mistakes in
>> quite a high percentage of kernels.
>
> As you have found out, there is a difference that matters in the SPDX
> lines vs the MODULE_LICENSE lines when it comes to GPL vs GPLv2+ stuff.
> The SPDX lines are correct for the code itself, while the MODULE_LICENSE
> lines are correct from a "this is the license of this binary" point of
> view.

Oh right!

> So don't get confused here, if you all can figure out a way to generate
> the MODULE_LICENSE() lines from SPDX, that would be great, but in my
> quick look I think it's going to be very difficult (think about how
> multiple files make up a single module binary...)

In this specific case, 100% of the files I'm touching cannot be built as
modules at all (they are covered purely by booleans in Kconfig, no
tristate), so by this definition MODULE_LICENSE would seem to have no
meaning for them? If so, I don't see why you're objecting to ripping out
these meaningless lines. (I have already been told not to comment them
out but instead to just delete them.)

>> But... for our purposes, we don't actually *mind* if non-modules list
>> things like licenses inconsistently in two different places. Removing
>> MODULE_LICENSE was a means, not an end. What we're actually interested
>> in doing is removing .modinfo in things that can't possibly be modules,
>> and since a .modinfo in a guaranteed-non-module is at best entirely
>> useless I don't think anyone could reasonably be opposed to that end
>> goal (though they might reasonably be unhappy about all the churn
>> involved in getting there). They object to the removal of the visible
>> MODULE_LICENSE() argument text string, not to the useless compile-time
>> effect of a MODULE_LICENSE in a non-module.
>
> there are other things that create .modinfo lines, so I'm confused why
> you picked the license line to trigger all of this.

I didn't. Yamada did. MODULE_LICENSE is the only thing that generates
.modinfo *sections*, as of this commit:

commit 8b41fc4454e36fbfdbb23f940d023d4dece2de29
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Thu Dec 19 17:33:29 2019 +0900

    kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf
[...]
    This commit simplifies the implementation. Let's exploit the fact
    that every module has MODULE_LICENSE(). (modpost shows a warning if
    MODULE_LICENSE is missing. If so, 0-day bot would already have blocked
    such a module.)
    
    I added MODULE_FILE to <linux/module.h>. When the code is being compiled
    as builtin, it will be filled with the file path of the module, and
    collected into modules.builtin.info. Then, scripts/link-vmlinux.sh
    extracts the list of builtin modules out of it.
    
    This new approach fixes the false-positives above, but adds another
    type of false-positives; non-modular code may have MODULE_LICENSE()
    by mistake. This is not a big deal, it is just the code is always
    orphan. We can clean it up if we like. [...]

It turns out that the presence of .modinfo is the *only* thing Yamada is
willing to use as an indicator that something can be a module: he's
vehemently refused any alternative, such as anything going back to the
tristate statements in Kconfig (using a "gave me nightmares" level of
vehemence, to be honest, and that is not a figure of speech).

But as a result of this, if we want there to be any way to tell whether
something can be a module, we now *have* to use .modinfo, which means we
*have* to ensure that only things that can be a module can contain
MODULE_LICENSEs. After the commit above, correct modules.builtin
construction requires this property. (Before that commit, all that was
necessary was Kconfig.)

>> So how about, for the first three groups below (the groups where
>> MODULE_LICENSE and SPDX are inconsistent, or where a SPDX simply doesn't
>> exist), instead of removing the MODULE_LICENSE we replace it with an
>> identical call to a new macro named perhaps NONMODULE_LICENSE(), which
>> is defined in module.h as simply expanding to nothing, except possibly
>> emitting a compile-time error if it's ever used in a module? This more
>> clearly denotes what's going on, keeps the license string in the source
>> file on a nearly identical line (for whatever purpose it serves), drops
>> the spurious .modinfo that's causing trouble, and probably makes fewer
>> people unhappy?
>
> Again, no, why aren't you just stubbing out MODULE_LICENSE() in the
> build if it's not being built as a module like the other MODULE_*()
> macros are?  Why is the license so special here yet the device list or
> module authors not?

This isn't "being built as a module": this is "can *ever* be built as a
module": i.e. "has a tristate line in Kconfig for at least one CONFIG_
variable governing the build for this object file".

> Don't treat this macro as somehow special where authors have to remember
> to not use it (or to use it), while the other MODULE_* macros do not
> have the issue?

The commit above should make things clearer, I hope? I think Yamada's
idea was that MODULE_LICENSE is something that must be present if module
loading is to work, so hanging other things that should be present in
all modules off it seems reasonable too: this seems pretty reasonable to
me as well, if directly driving via tristate statements is out.

This directly affects things like modules.builtin which are now driven
by .modinfo sections in vmlinux.o, dropped by the linker at final link
time. I'm just trying to make that .modinfo sections not contain entries
for things that are not tristate. Believe me, I'd much rather have done
this *without* a 140-patch series, but this was the first approach that
none of the module maintainers nacked.

> That's my main objection here.  Don't get confused by the license stuff,
> that's secondary.

Well, it seems to me that you're really objecting to the consequences of
a years-old commit that I didn't write. Since the person who did write
it seems to hate me for unclear reasons, I think you might have to ask
him for his rationale yourself (all his few communications with me for
the last several months have been various forms of insult, often for
doing things that he asked me to do years earlier: the remainder were
for doing things Luis asked me to do). If you could possibly get him to
stop attacking me I'd be grateful too. I'm only trying to improve the
kernel here.

(I am aware that saying this is probably going to make Yamada explode --
again -- so I removed him from Cc: out of an excess of hope. Nonetheless
it is true.)

(Not everyone has been awful. Luis in particular has been extremely
helpful even if I cursed at his requests sometimes. He even wrote a
replacement for the patch Yamada initially objected to, without my even
asking, and it was ever so much simpler than the thing I'd derived from
the old scripts/Makefile.modbuiltin. But that patch does rely on
modules.builtin being correct, hence needs all this MODULE_LICENSE
stuff...)

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-27 14:54                           ` Nick Alcock
@ 2023-03-27 18:23                             ` Nick Alcock
  2023-03-29  2:50                               ` Luis Chamberlain
  0 siblings, 1 reply; 47+ messages in thread
From: Nick Alcock @ 2023-03-27 18:23 UTC (permalink / raw)
  To: Nick Alcock
  Cc: Greg Kroah-Hartman, Luis Chamberlain, Geert Uytterhoeven,
	Thomas Gleixner, Christoph Hellwig, linux-modules, linux-kernel,
	Hitomi Hasegawa, Jiri Slaby

On 27 Mar 2023, Nick Alcock uttered the following:
> Well, it seems to me that you're really objecting to the consequences of
> a years-old commit that I didn't write. Since the person who did write
> it seems to hate me for unclear reasons,

I should probably apologise: this was uncalled for. Stressful day and I
typed without thinking (and then rephrased it repeatedly without
thinking). So, sorry! Mea culpa etc.

(I am *good* at putting both feet in it)

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-27 18:23                             ` Nick Alcock
@ 2023-03-29  2:50                               ` Luis Chamberlain
  0 siblings, 0 replies; 47+ messages in thread
From: Luis Chamberlain @ 2023-03-29  2:50 UTC (permalink / raw)
  To: Nick Alcock
  Cc: Greg Kroah-Hartman, Geert Uytterhoeven, Thomas Gleixner,
	Christoph Hellwig, linux-modules, linux-kernel, Hitomi Hasegawa,
	Jiri Slaby

Nick, you *need* something we *want* but the form requires work.
Removing the module license tag and all that other module boiler
plate from modules which cannot possibly be modules is obviously
welcomed. But there's a few issues, one of them is when we don't
have SPDX license pegged on files. We *all* want SPDX files properly
annotated on files. We *want* to automate the module license from
the SPDX tag.

It sounds hard but let's go for the long shot of striving to automate
the module license from the SPDX tags.

Let's break this down into a few steps that also benefit your goals:

1) Fix all all code which use the module license tag but cannot possibly
be modules to ensure they all have proper SPDX tags. This is a welcomed
effort.

2) Create an an association of existing module licenses from mod-objs object
lists.

3) Verify these make sense with us.

4) With that list we can then infer a module license from things which
*can* be modules.

The trick is today we use the module license *for* that inference,
however, look at the tristate, and see if you can add a POSSIBLE_MODULE
as I noted and hinted before. That get's you a module license
replacement. The final nail to all this is use that to replace all
module licenses and have this done automatically.

  Luis

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules
  2023-03-24 18:06                     ` Luis Chamberlain
  2023-03-27 10:46                       ` Nick Alcock
@ 2023-04-13 20:24                       ` Luis Chamberlain
  1 sibling, 0 replies; 47+ messages in thread
From: Luis Chamberlain @ 2023-04-13 20:24 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Thomas Gleixner
  Cc: Nick Alcock, Geert Uytterhoeven, Masahiro Yamada,
	Christoph Hellwig, linux-modules, linux-kernel, Hitomi Hasegawa,
	Jiri Slaby

On Fri, Mar 24, 2023 at 11:06:59AM -0700, Luis Chamberlain wrote:
> On Fri, Mar 24, 2023 at 03:29:00PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Mar 24, 2023 at 02:16:03PM +0000, Nick Alcock wrote:
> > > On 24 Mar 2023, Geert Uytterhoeven uttered the following:
> > > > I (still) agree with that, and I saw similar comments from others as well.
> > > > Unfortunately these comments are spread across tens of threads :-(
> > > 
> > > Ugh. Should I do this sort of thing in one big commit next time? That
> > > would fix that problem, but at the cost of others. Lumping seems to me
> > > to be troublesome because it makes it harder to accept/reject different
> > > bits, but would it be *as* troublesome as this much splitting?
> > 
> > The problem is, some of us disagree that this should be done at all, so
> > reverting all of the individual parts is going to be hard now.
> > 
> > Please put back the license bits that you removed, as it is not a good
> > idea to remove that if the file does not have a SPDX entry at the very
> > least.
> 
> Nick, I've just dropped your series. Please only re-submit only for
> files where the license is clear. The effort of clarifying licenses
> on files where one doesn't have an SPDX tag is welcomed but can take
> time and we'll need this anyway in the future to help later strive to
> see if we can automatically generate the MODULE_LICENSE() from the
> SPDX tags.

I had not seen any effort to get a new series going for this so given
I realize this is a royal pain in the ass to, and Nick has *already*
done enough, I've done the sanity checks myself and dropped the patches
from Nick which lacked SPDX annotations.

One can verify if a patch you are modifying lacks SPDX annotations in
a commit series with:

./scripts/spdxcheck.py -f $(git diff --name-only commid-id | xargs echo)

And so I've dropped all the patches that did that from Nick's series
and pushed to modules-next only the ones that did have an SPDX
annotation.

There were only 11 files which *did not* have SPDX annoations, these can
be worked on with the community later to get SPDX annotations added:

drivers/bus/arm-cci.c
drivers/bus/imx-weim.c
drivers/gpu/drm/drm_mipi_dsi.c
drivers/irqchip/irq-mvebu-pic.c
drivers/reset/reset-axs10x.c
drivers/reset/reset-hsdk.c
drivers/video/fbdev/asiliantfb.c
drivers/video/fbdev/gbefb.c
drivers/video/fbdev/imsttfb.c
drivers/xen/xenbus/xenbus_probe.c
lib/glob.c

  Luis

^ permalink raw reply	[flat|nested] 47+ messages in thread

end of thread, other threads:[~2023-04-13 20:24 UTC | newest]

Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-02 21:17 [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Nick Alcock
2023-03-02 21:17 ` [PATCH 01/17] irqchip: remove MODULE_LICENSE in non-modules Nick Alcock
2023-03-02 21:17 ` [PATCH 02/17] bus: " Nick Alcock
2023-03-02 21:17 ` [PATCH 03/17] braille_console: " Nick Alcock
2023-03-02 21:17 ` [PATCH 04/17] arm-cci: " Nick Alcock
2023-03-02 21:17 ` [PATCH 05/17] drivers: bus: simple-pm-bus: " Nick Alcock
2023-03-03  7:52   ` Geert Uytterhoeven
2023-03-03 18:32     ` Nick Alcock
2023-03-03 18:43       ` Geert Uytterhoeven
2023-03-20 10:58     ` Nick Alcock
2023-03-02 21:17 ` [PATCH 06/17] watch_queue: " Nick Alcock
2023-03-02 21:17 ` [PATCH 07/17] btree: " Nick Alcock
2023-03-02 21:17 ` [PATCH 08/17] lib: " Nick Alcock
2023-03-02 21:17 ` [PATCH 09/17] fprobe: " Nick Alcock
2023-03-02 21:17 ` [PATCH 10/17] tty: " Nick Alcock
2023-03-09 16:15   ` Greg Kroah-Hartman
2023-03-09 22:38     ` Luis Chamberlain
2023-03-10  7:31       ` Greg Kroah-Hartman
2023-03-10 19:33         ` Luis Chamberlain
2023-03-24  9:08           ` Geert Uytterhoeven
2023-03-24  9:12             ` Geert Uytterhoeven
2023-03-24  9:14             ` Greg Kroah-Hartman
2023-03-24  9:16               ` Geert Uytterhoeven
2023-03-24 14:16                 ` Nick Alcock
2023-03-24 14:29                   ` Greg Kroah-Hartman
2023-03-24 18:06                     ` Luis Chamberlain
2023-03-27 10:46                       ` Nick Alcock
2023-03-27 11:43                         ` Greg Kroah-Hartman
2023-03-27 14:54                           ` Nick Alcock
2023-03-27 18:23                             ` Nick Alcock
2023-03-29  2:50                               ` Luis Chamberlain
2023-04-13 20:24                       ` Luis Chamberlain
2023-03-26  4:52               ` Christoph Hellwig
2023-03-02 21:17 ` [PATCH 11/17] unicode: " Nick Alcock
2023-03-06 15:32   ` Gabriel Krisman Bertazi
2023-03-02 21:17 ` [PATCH 12/17] udmabuf: " Nick Alcock
2023-03-02 21:17 ` [PATCH 13/17] regulator: stm32-pwr: " Nick Alcock
2023-03-03  0:31   ` Mark Brown
2023-03-03 18:30     ` Nick Alcock
2023-03-04 20:12       ` Mark Brown
2023-03-02 21:17 ` [PATCH 14/17] mm: " Nick Alcock
2023-03-02 21:17 ` [PATCH 15/17] xen: " Nick Alcock
2023-03-06  7:45   ` Juergen Gross
2023-03-02 21:17 ` [PATCH 16/17] zpool: " Nick Alcock
2023-03-02 21:17 ` [PATCH 17/17] zswap: " Nick Alcock
2023-03-03 22:22 ` [PATCH 00/17] MODULE_LICENSE removals, sixth tranche Luis Chamberlain
2023-03-20 11:00   ` Nick Alcock

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).