Add generated modalias to modules.builtin.modinfo

Define MODULE_DEVICE_TABLE only if a structure is defined for it.

drivers/scsi/BusLogic.c:3735:26: error: use of undeclared identifier 'blogic_pci_tbl'
 3735 | MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);

Quoted 5 lines · Alexey Gladkov

Define MODULE_DEVICE_TABLE only if a structure is defined for it.

drivers/scsi/BusLogic.c:3735:26: error: use of undeclared identifier 'blogic_pci_tbl'
 3735 | MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);

Well, a) need to cc the scsi list

and b) how is this possible when
MODULE_DEVICE_TABLE() has an empty definition if MODULE isn't defined (so the guard you move should be over an empty statement)?

Quoted 9 lines · James Bottomley

Quoted 6 lines · Alexey Gladkov

Define MODULE_DEVICE_TABLE only if a structure is defined for it.

drivers/scsi/BusLogic.c:3735:26: error: use of undeclared identifier
'blogic_pci_tbl'
 3735 | MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);

Well, a) need to cc the scsi list

Sorry. I miss it.

Quoted 3 lines

and b) how is this possible when MODULE_DEVICE_TABLE() has an empty definition if MODULE isn't defined (so the guard you move should be over an empty statement)?

In the next patch:

[PATCH v3 4/6] modpost: Create modalias for builtin modules

I remove this condition for the MODULE_DEVICE_TABLE macro and it will be always defined.

Quoted 21 lines · Alexey Gladkov

Quoted 9 lines · James Bottomley

Quoted 6 lines · Alexey Gladkov

Define MODULE_DEVICE_TABLE only if a structure is defined for it.

drivers/scsi/BusLogic.c:3735:26: error: use of undeclared identifier
'blogic_pci_tbl'
 3735 | MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);

Well, a) need to cc the scsi list

Sorry. I miss it.

Quoted 3 lines

and b) how is this possible when MODULE_DEVICE_TABLE() has an empty definition if MODULE isn't defined (so the guard you move should be over an empty statement)?

In the next patch:

[PATCH v3 4/6] modpost: Create modalias for builtin modules

Quoted 2 lines

I remove this condition for the MODULE_DEVICE_TABLE macro and it will be always defined.

Well, why? If there's a reason for the table to always exist, wouldn't the best fix then be to remove the module guards from the PCI table in the buslogic ... they only really exist to prevent a defined but not used error which it sounds like you're getting rid of?

The __MODULE_INFO macros always use __MODULE_INFO_PREFIX. The only way to use a different prefix is to override __MODULE_INFO_PREFIX, which is not very useful.

The new macro will be used in file2alias.c to generate modalias for builtin modules.

Signed-off-by Alexey Gladkov <[email protected]>

Reviewed-by Petr Pavlu <[email protected]>

---
 include/linux/module.h      | 3 +++
 include/linux/moduleparam.h | 7 +++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

include/linux/module.h +3 -0

index 8050f77c3b64..88048561360f 100644
@@ -170,6 +170,9 @@ struct module_kobject *lookup_or_create_module_kobject(const char *name);
 /* For userspace: you can also call me... */
 #define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
 
+#define MODULE_ALIAS_MODNAME(_modname, _alias) \
+       __MODULE_INFO_WITH_PREFIX(_modname ".", alias, alias, _alias)
+
 /* Soft module dependencies. See man modprobe.d for details.
  * Example: MODULE_SOFTDEP("pre: module-foo module-bar post: module-baz")
  */

include/linux/moduleparam.h +5 -3

index bfb85fd13e1f..3f819fc67c43 100644
@@ -20,10 +20,13 @@
 /* Chosen so that structs with an unsigned long line up. */
 #define MAX_PARAM_PREFIX_LEN (64 - sizeof(unsigned long))
 
-#define __MODULE_INFO(tag, name, info)                                   \
+#define __MODULE_INFO_WITH_PREFIX(prefix, tag, name, info)               \
        static const char __UNIQUE_ID(name)[]                             \
                __used __section(".modinfo") __aligned(1)                 \
-               = __MODULE_INFO_PREFIX __stringify(tag) "=" info
+               = prefix __stringify(tag) "=" info
+
+#define __MODULE_INFO(tag, name, info)                                   \
+       __MODULE_INFO_WITH_PREFIX(__MODULE_INFO_PREFIX, tag, name, info)
 
 #define __MODULE_PARM_TYPE(name, _type)                                          \
        __MODULE_INFO(parmtype, name##type, #name ":" _type)
--

2.49.0

Quoted 4 lines · Alexey Gladkov

The __MODULE_INFO macros always use __MODULE_INFO_PREFIX. The only way to use a different prefix is to override __MODULE_INFO_PREFIX, which is not very useful.

Not necessarily.
This would be a very special case only used in modpost, and modpost can use MODULE_INFO() instead.

        list_for_each_entry_safe(alias, next, &mod->aliases, node) {

Quoted 48 lines

The new macro will be used in file2alias.c to generate modalias for builtin modules.

Signed-off-by Alexey Gladkov <[email protected]>

Reviewed-by Petr Pavlu <[email protected]>

---
 include/linux/module.h      | 3 +++
 include/linux/moduleparam.h | 7 +++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

include/linux/module.h +3 -0

index 8050f77c3b64..88048561360f 100644
@@ -170,6 +170,9 @@ struct module_kobject *lookup_or_create_module_kobject(const char *name);
 /* For userspace: you can also call me... */
 #define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
 
+#define MODULE_ALIAS_MODNAME(_modname, _alias) \
+       __MODULE_INFO_WITH_PREFIX(_modname ".", alias, alias, _alias)
+
 /* Soft module dependencies. See man modprobe.d for details.
  * Example: MODULE_SOFTDEP("pre: module-foo module-bar post: module-baz")
  */

include/linux/moduleparam.h +5 -3

index bfb85fd13e1f..3f819fc67c43 100644
@@ -20,10 +20,13 @@
 /* Chosen so that structs with an unsigned long line up. */
 #define MAX_PARAM_PREFIX_LEN (64 - sizeof(unsigned long))
 
-#define __MODULE_INFO(tag, name, info)                                   \
+#define __MODULE_INFO_WITH_PREFIX(prefix, tag, name, info)               \
        static const char __UNIQUE_ID(name)[]                             \
                __used __section(".modinfo") __aligned(1)                 \
-               = __MODULE_INFO_PREFIX __stringify(tag) "=" info
+               = prefix __stringify(tag) "=" info
+
+#define __MODULE_INFO(tag, name, info)                                   \
+       __MODULE_INFO_WITH_PREFIX(__MODULE_INFO_PREFIX, tag, name, info)
 
 #define __MODULE_PARM_TYPE(name, _type)                                          \
        __MODULE_INFO(parmtype, name##type, #name ":" _type)
--

2.49.0

Signature · 2 lines

Best Regards
Masahiro Yamada

In order to avoid symbol conflicts if they appear in the same binary, a more unique alias identifier can be generated.

Signed-off-by Alexey Gladkov <[email protected]>

Reviewed-by Petr Pavlu <[email protected]>

---
 include/linux/module.h   | 14 ++++++++++++--
 scripts/mod/file2alias.c | 18 ++++++++++++++----
 2 files changed, 26 insertions(+), 6 deletions(-)

include/linux/module.h +12 -2

index 88048561360f..e7506684069d 100644
@@ -249,10 +249,20 @@ struct module_kobject *lookup_or_create_module_kobject(const char *name);
 /* What your module does. */
 #define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
 
+/* Format: __mod_device_table__<counter>__kmod_<modname>__<type>__<name> */
+#define __mod_device_table(type, name) \
+       __PASTE(__mod_device_table__,   \
+       __PASTE(__COUNTER__,            \
+       __PASTE(__,                     \
+       __PASTE(__KBUILD_MODNAME,       \
+       __PASTE(__,                     \
+       __PASTE(type,                   \
+       __PASTE(__, name)))))))
+
 #ifdef MODULE
 /* Creates an alias so file2alias.c can find device table. */
-#define MODULE_DEVICE_TABLE(type, name)                                        \
-extern typeof(name) __mod_device_table__##type##__##name               \
+#define MODULE_DEVICE_TABLE(type, name)                        \
+extern typeof(name) __mod_device_table(type, name)     \
   __attribute__ ((unused, alias(__stringify(name))))
 #else  /* !MODULE */
 #define MODULE_DEVICE_TABLE(type, name)

scripts/mod/file2alias.c +14 -5

index 00586119a25b..dff1799a4c79 100644
@@ -1476,8 +1476,8 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
 {
        void *symval;
        char *zeros = NULL;
-       const char *type, *name;
-       size_t typelen;
+       const char *type, *name, *modname;
+       size_t typelen, modnamelen;
        static const char *prefix = "__mod_device_table__";
 
        /* We're looking for a section relative symbol */

@@ -1488,10 +1488,20 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
        if (ELF_ST_TYPE(sym->st_info) != STT_OBJECT)
                return;
 
-       /* All our symbols are of form __mod_device_table__<type>__<name>. */
+       /* All our symbols are of form __mod_device_table__<counter>__kmod_<modname>__<type>__<name>. */
        if (!strstarts(symname, prefix))
                return;
-       type = symname + strlen(prefix);
+
+       modname = strstr(symname, "__kmod_");
+       if (!modname)
+               return;
+       modname += strlen("__kmod_");
+
+       type = strstr(modname, "__");
+       if (!type)
+               return;
+       modnamelen = type - modname;
+       type += strlen("__");
 
        name = strstr(type, "__");
        if (!name)
--

2.49.0

Quoted 3 lines · Alexey Gladkov

In order to avoid symbol conflicts if they appear in the same binary, a more unique alias identifier can be generated.

Why must this be unique?

What problem would happen if the same symbol names appear in MODULE_DEVICE_TABLE()?

Quoted 77 lines

Signed-off-by Alexey Gladkov <[email protected]>

Reviewed-by Petr Pavlu <[email protected]>

---
 include/linux/module.h   | 14 ++++++++++++--
 scripts/mod/file2alias.c | 18 ++++++++++++++----
 2 files changed, 26 insertions(+), 6 deletions(-)

include/linux/module.h +12 -2

index 88048561360f..e7506684069d 100644
@@ -249,10 +249,20 @@ struct module_kobject *lookup_or_create_module_kobject(const char *name);
 /* What your module does. */
 #define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
 
+/* Format: __mod_device_table__<counter>__kmod_<modname>__<type>__<name> */
+#define __mod_device_table(type, name) \
+       __PASTE(__mod_device_table__,   \
+       __PASTE(__COUNTER__,            \
+       __PASTE(__,                     \
+       __PASTE(__KBUILD_MODNAME,       \
+       __PASTE(__,                     \
+       __PASTE(type,                   \
+       __PASTE(__, name)))))))
+
 #ifdef MODULE
 /* Creates an alias so file2alias.c can find device table. */
-#define MODULE_DEVICE_TABLE(type, name)                                        \
-extern typeof(name) __mod_device_table__##type##__##name               \
+#define MODULE_DEVICE_TABLE(type, name)                        \
+extern typeof(name) __mod_device_table(type, name)     \
   __attribute__ ((unused, alias(__stringify(name))))
 #else  /* !MODULE */
 #define MODULE_DEVICE_TABLE(type, name)

scripts/mod/file2alias.c +14 -5

index 00586119a25b..dff1799a4c79 100644
@@ -1476,8 +1476,8 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
 {
        void *symval;
        char *zeros = NULL;
-       const char *type, *name;
-       size_t typelen;
+       const char *type, *name, *modname;
+       size_t typelen, modnamelen;
        static const char *prefix = "__mod_device_table__";
 
        /* We're looking for a section relative symbol */

@@ -1488,10 +1488,20 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
        if (ELF_ST_TYPE(sym->st_info) != STT_OBJECT)
                return;
 
-       /* All our symbols are of form __mod_device_table__<type>__<name>. */
+       /* All our symbols are of form __mod_device_table__<counter>__kmod_<modname>__<type>__<name>. */
        if (!strstarts(symname, prefix))
                return;
-       type = symname + strlen(prefix);
+
+       modname = strstr(symname, "__kmod_");
+       if (!modname)
+               return;
+       modname += strlen("__kmod_");
+
+       type = strstr(modname, "__");
+       if (!type)
+               return;
+       modnamelen = type - modname;
+       type += strlen("__");
 
        name = strstr(type, "__");
        if (!name)
--

2.49.0

Signature · 2 lines

Best Regards
Masahiro Yamada

Quoted 9 lines · Masahiro Yamada

Quoted 3 lines · Alexey Gladkov

In order to avoid symbol conflicts if they appear in the same binary, a more unique alias identifier can be generated.

Why must this be unique?

What problem would happen if the same symbol names appear in MODULE_DEVICE_TABLE()?

Before these patches this was not a problem as non-unique characters are in separate object files when the module is compiled separately.

But when the modules are compiled into the kernel, there is a symbol conflict when linking vmlinuz. We have modules that export multiple device tables from different object files.

Quoted 12 lines · Alexey Gladkov

Quoted 9 lines · Masahiro Yamada

Quoted 3 lines · Alexey Gladkov

In order to avoid symbol conflicts if they appear in the same binary, a more unique alias identifier can be generated.

Why must this be unique?

What problem would happen if the same symbol names appear in MODULE_DEVICE_TABLE()?

Quoted 6 lines

Before these patches this was not a problem as non-unique characters are in separate object files when the module is compiled separately.

But when the modules are compiled into the kernel, there is a symbol conflict when linking vmlinuz. We have modules that export multiple device tables from different object files.

This is because the __mod_device_table__* symbols are global, but I suspect they do not need to be.

Let's test this
https://lore.kernel.org/lkml/[email protected]/T/#u

Quoted 20 lines · Masahiro Yamada

Quoted 12 lines · Alexey Gladkov

Quoted 9 lines · Masahiro Yamada

Quoted 3 lines · Alexey Gladkov

In order to avoid symbol conflicts if they appear in the same binary, a more unique alias identifier can be generated.

Why must this be unique?

What problem would happen if the same symbol names appear in MODULE_DEVICE_TABLE()?

Quoted 6 lines

Before these patches this was not a problem as non-unique characters are in separate object files when the module is compiled separately.

But when the modules are compiled into the kernel, there is a symbol conflict when linking vmlinuz. We have modules that export multiple device tables from different object files.

Quoted 5 lines

This is because the __mod_device_table__* symbols are global, but I suspect they do not need to be.

Let's test this
https://lore.kernel.org/lkml/[email protected]/T/#u

I tested this patch with the config:

make allmodconfig
make mod2yesconfig

and it works.

Quoted 30 lines · Alexey Gladkov

Quoted 20 lines · Masahiro Yamada

Quoted 12 lines · Alexey Gladkov

Quoted 9 lines · Masahiro Yamada

Quoted 3 lines · Alexey Gladkov

In order to avoid symbol conflicts if they appear in the same binary, a more unique alias identifier can be generated.

Why must this be unique?

What problem would happen if the same symbol names appear in MODULE_DEVICE_TABLE()?

Quoted 6 lines

Before these patches this was not a problem as non-unique characters are in separate object files when the module is compiled separately.

But when the modules are compiled into the kernel, there is a symbol conflict when linking vmlinuz. We have modules that export multiple device tables from different object files.

Quoted 5 lines

This is because the __mod_device_table__* symbols are global, but I suspect they do not need to be.

Let's test this
https://lore.kernel.org/lkml/[email protected]/T/#u

I tested this patch with the config:

Quoted 4 lines

make allmodconfig
make mod2yesconfig

and it works.

Good.
Then, __COUNTER__ is unnecessary.

Quoted 15 lines

Quoted 7 lines

Quoted 6 lines

Before these patches this was not a problem as non-unique characters are in separate object files when the module is compiled separately.

But when the modules are compiled into the kernel, there is a symbol conflict when linking vmlinuz. We have modules that export multiple device tables from different object files.

Quoted 5 lines

This is because the __mod_device_table__* symbols are global, but I suspect they do not need to be.

Let's test this
https://lore.kernel.org/lkml/[email protected]/T/#u

I tested this patch with the config:

Quoted 4 lines

make allmodconfig
make mod2yesconfig

and it works.

Good.
Then, __COUNTER__ is unnecessary.

Quoted 18 lines · Masahiro Yamada

Quoted 18 lines

Quoted 7 lines

Quoted 6 lines

Before these patches this was not a problem as non-unique characters are in separate object files when the module is compiled separately.

But when the modules are compiled into the kernel, there is a symbol conflict when linking vmlinuz. We have modules that export multiple device tables from different object files.

Quoted 5 lines

This is because the __mod_device_table__* symbols are global, but I suspect they do not need to be.

Let's test this
https://lore.kernel.org/lkml/[email protected]/T/#u

I tested this patch with the config:

make allmodconfig
make mod2yesconfig

Quoted 4 lines

Quoted 1 line

and it works.

Good.
Then, __COUNTER__ is unnecessary.

I didn't immediately notice. The patch you suggested works, but these symbols remain in System.map and it seems in vmlinuz.

Quoted 20 lines · Alexey Gladkov

Quoted 18 lines · Masahiro Yamada

Quoted 18 lines

Quoted 7 lines

Quoted 6 lines

Before these patches this was not a problem as non-unique characters are in separate object files when the module is compiled separately.

But when the modules are compiled into the kernel, there is a symbol conflict when linking vmlinuz. We have modules that export multiple device tables from different object files.

Quoted 5 lines

This is because the __mod_device_table__* symbols are global, but I suspect they do not need to be.

Let's test this
https://lore.kernel.org/lkml/[email protected]/T/#u

I tested this patch with the config:

make allmodconfig
make mod2yesconfig

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

and it works.

Good.
Then, __COUNTER__ is unnecessary.

I didn't immediately notice. The patch you suggested works, but these symbols remain in System.map and it seems in vmlinuz.

Ah, yes, if your patch set is applied.

Currently, MODULE_DEVICE_TABLE() is no-op in vmlinux.

This makes me realize that your v3 4/6 increased the vmlinux image, as MODULE_DEVICE_TABLE() is kept for modpost.

In order to avoid symbol conflicts if they appear in the same binary, a more unique alias identifier can be generated.

Signed-off-by Alexey Gladkov <[email protected]>

Reviewed-by Petr Pavlu <[email protected]>

---
 include/linux/module.h   | 14 ++++++++++++--
 scripts/mod/file2alias.c | 18 ++++++++++++++----
 2 files changed, 26 insertions(+), 6 deletions(-)

include/linux/module.h +0 -0

index 88048561360f..e7506684069d 100644

Quoted 19 lines · Alexey Gladkov

In order to avoid symbol conflicts if they appear in the same binary, a more unique alias identifier can be generated.

Signed-off-by Alexey Gladkov <[email protected]>

Reviewed-by Petr Pavlu <[email protected]>

---
 include/linux/module.h   | 14 ++++++++++++--
 scripts/mod/file2alias.c | 18 ++++++++++++++----
 2 files changed, 26 insertions(+), 6 deletions(-)

include/linux/module.h +0 -0

index 88048561360f..e7506684069d 100644
@@ -249,10 +249,20 @@ struct module_kobject *lookup_or_create_module_kobject(const char *name);
 /* What your module does. */
 #define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
 

include/linux/module.h struct module_kobject *lookup_or_create_module_kobject(const char *name); · line 252

Quoted 1 line

include/linux/module.h +1 -0

+/* Format: __mod_device_table__<counter>__kmod_<modname>__<type>__<name> */

This format relies on module-name mangling, but
I hope we will be able to stop doing it some day.

Can we come up with a different idea
in case <modname> contains hyphens?

Quoted 20 lines · Masahiro Yamada

Quoted 19 lines · Alexey Gladkov

In order to avoid symbol conflicts if they appear in the same binary, a more unique alias identifier can be generated.

Signed-off-by Alexey Gladkov <[email protected]>

Reviewed-by Petr Pavlu <[email protected]>

---
 include/linux/module.h   | 14 ++++++++++++--
 scripts/mod/file2alias.c | 18 ++++++++++++++----
 2 files changed, 26 insertions(+), 6 deletions(-)

include/linux/module.h +0 -0

index 88048561360f..e7506684069d 100644
@@ -249,10 +249,20 @@ struct module_kobject *lookup_or_create_module_kobject(const char *name);
 /* What your module does. */
 #define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
 

Quoted 4 lines

include/linux/module.h struct module_kobject *lookup_or_create_module_kobject(const char *name); · line 252

Quoted 1 line

include/linux/module.h +1 -0

+/* Format: __mod_device_table__<counter>__kmod_<modname>__<type>__<name> */

This format relies on module-name mangling, but
I hope we will be able to stop doing it some day.

I didn't like this approach either when I found out how it was implemented.

We can only add the module name to the structure to which the alias is made. But the problem with this is that right now there is no common structure for DEVICE_TABLE. Each module comes up with its own.

It is possible to add a common structure, but that would be a big refactoring.

Quoted 22 lines · Alexey Gladkov

Quoted 20 lines · Masahiro Yamada

Quoted 19 lines · Alexey Gladkov

In order to avoid symbol conflicts if they appear in the same binary, a more unique alias identifier can be generated.

Signed-off-by Alexey Gladkov <[email protected]>

Reviewed-by Petr Pavlu <[email protected]>

---
 include/linux/module.h   | 14 ++++++++++++--
 scripts/mod/file2alias.c | 18 ++++++++++++++----
 2 files changed, 26 insertions(+), 6 deletions(-)

include/linux/module.h +0 -0

index 88048561360f..e7506684069d 100644
@@ -249,10 +249,20 @@ struct module_kobject *lookup_or_create_module_kobject(const char *name);
 /* What your module does. */
 #define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
 

Quoted 7 lines

Quoted 4 lines

include/linux/module.h struct module_kobject *lookup_or_create_module_kobject(const char *name); · line 252

Quoted 1 line

include/linux/module.h +1 -0

+/* Format: __mod_device_table__<counter>__kmod_<modname>__<type>__<name> */

This format relies on module-name mangling, but
I hope we will be able to stop doing it some day.

I didn't like this approach either when I found out how it was implemented.

Yeah, I dislike it.

I hope we can stop this historical mistake:
https://lore.kernel.org/lkml/[email protected]/

Once we stop doing that, __KBUILD_MODNAME will not match to KBUILD_MODNAME.

Also, you need to be careful about the rust side, as you did not take care of it.

https://github.com/torvalds/linux/blob/v6.15/rust/kernel/device_id.rs#L157

Quoted 31 lines · Masahiro Yamada

Quoted 29 lines · Alexey Gladkov

Quoted 20 lines · Masahiro Yamada

Quoted 19 lines · Alexey Gladkov

In order to avoid symbol conflicts if they appear in the same binary, a more unique alias identifier can be generated.

Signed-off-by Alexey Gladkov <[email protected]>

Reviewed-by Petr Pavlu <[email protected]>

---
 include/linux/module.h   | 14 ++++++++++++--
 scripts/mod/file2alias.c | 18 ++++++++++++++----
 2 files changed, 26 insertions(+), 6 deletions(-)

include/linux/module.h +0 -0

index 88048561360f..e7506684069d 100644
@@ -249,10 +249,20 @@ struct module_kobject *lookup_or_create_module_kobject(const char *name);
 /* What your module does. */
 #define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
 

Quoted 4 lines

include/linux/module.h struct module_kobject *lookup_or_create_module_kobject(const char *name); · line 252

Quoted 1 line

include/linux/module.h +1 -0

+/* Format: __mod_device_table__<counter>__kmod_<modname>__<type>__<name> */

This format relies on module-name mangling, but
I hope we will be able to stop doing it some day.

I didn't like this approach either when I found out how it was implemented.

Quoted 6 lines

Yeah, I dislike it.

I hope we can stop this historical mistake:
https://lore.kernel.org/lkml/[email protected]/

Once we stop doing that, __KBUILD_MODNAME will not match to KBUILD_MODNAME.

Do I understand you correctly that I cannot use __KBUILD_MODNAME now ?

Quoted 4 lines

Also, you need to be careful about the rust side, as you did not take care of it.

https://github.com/torvalds/linux/blob/v6.15/rust/kernel/device_id.rs#L157

Oh. This will make it much more complicated because I don't know rust well. :(

I found a few more issues with modules when they compile as part of the kernel, but was hoping to fix them after these patches.

--
Rgrds, legion

Hi Alexey,

kernel test robot noticed the following build errors:

[auto build test ERROR on masahiroy-kbuild/for-next]
[also build test ERROR on masahiroy-kbuild/fixes linus/master v6.15 next-20250528] [cannot apply to mkp-scsi/for-next jejb-scsi/for-next mcgrof/modules-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Alexey-Gladkov/scsi-Define-MODULE_DEVICE_TABLE-only-if-necessary/20250528-020814
base:   https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git for-next
patch link:    https://lore.kernel.org/r/1910073cfee59df4a3edb7f724214eeb4b8a3faa.1748335606.git.legion%40kernel.org
patch subject: [PATCH v3 5/6] kbuild: Move modules.builtin.modinfo to another makefile

:::::: branch date: 19 hours ago
:::::: commit date: 19 hours ago
config: x86_64-randconfig-003-20250528 (https://download.01.org/0day-ci/archive/20250528/[email protected]/config)
compiler: clang version 20.1.2 (https://github.com/llvm/llvm-project 58df0ef89dd64126512e4ee27b4ac3fd8ddf6247) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250528/[email protected]/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/r/[email protected]/

All errors (new ones prefixed by >>):

Quoted 2 lines

Quoted 2 lines

make[3]: *** No rule to make target 'modules.builtin.modinfo', needed by '/tmp/kernel/x86_64-randconfig-003-20250528/clang-20/0f04dfcaa62efc3a521b20ba0b39b2a78c4389db/lib/modules/6.15.0-rc7-00019-g0f04dfcaa62e/modules.builtin.modinfo'. make[3]: *** No rule to make target 'modules.builtin', needed by '/tmp/kernel/x86_64-randconfig-003-20250528/clang-20/0f04dfcaa62efc3a521b20ba0b39b2a78c4389db/lib/modules/6.15.0-rc7-00019-g0f04dfcaa62e/modules.builtin'.

make[3]: Target '__modinst' not remade because of errors. make[2]: *** [Makefile:1909: modules_install] Error 2 shuffle=3457807955 make[1]: *** [Makefile:248: __sub-make] Error 2 shuffle=3457807955 make[1]: Target 'modules_install' not remade because of errors.
make: *** [Makefile:248: __sub-make] Error 2 shuffle=3457807955
make: Target 'modules_install' not remade because of errors.

Since MODULE_DEVICE_TABLE no longer depends on whether the module is built separately or compiled into the kernel, it now makes sense to always define DEVICE_TABLE. In this case, even if the module is in the
kernel, correct module.builtin.modaliases will be generated.

Suggested-by James Bottomley <[email protected]>

Signed-off-by Alexey Gladkov <[email protected]>

---
 drivers/scsi/BusLogic.c | 2 --

 1 file changed, 2 deletions(-)

drivers/scsi/BusLogic.c +0 -0

index 8ce2ac9293a3..08e12a3d6703 100644
@@ -3715,7 +3715,6 @@ static void __exit blogic_exit(void)

 __setup("BusLogic=", blogic_setup);

-#ifdef MODULE
 /*static const struct pci_device_id blogic_pci_tbl[] = { { PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER,
    PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},

Quoted 28 lines · Alexey Gladkov

Since MODULE_DEVICE_TABLE no longer depends on whether the module is built separately or compiled into the kernel, it now makes sense to always define DEVICE_TABLE. In this case, even if the module is in the
kernel, correct module.builtin.modaliases will be generated.

Suggested-by James Bottomley <[email protected]>

Signed-off-by Alexey Gladkov <[email protected]>

---
 drivers/scsi/BusLogic.c | 2 --

 1 file changed, 2 deletions(-)

drivers/scsi/BusLogic.c +0 -0

index 8ce2ac9293a3..08e12a3d6703 100644
@@ -3715,7 +3715,6 @@ static void __exit blogic_exit(void)

 __setup("BusLogic=", blogic_setup);

-#ifdef MODULE
 /*static const struct pci_device_id blogic_pci_tbl[] = { { PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER,
    PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},

drivers/scsi/BusLogic.c +0 -0

@@ -3732,7 +3731,6 @@ static const struct pci_device_id
 blogic_pci_tbl[] = {
  	{0, },

drivers/scsi/BusLogic.c static const struct pci_device_id blogic_pci_tbl[] = { · line 3735

Quoted 3 lines

drivers/scsi/BusLogic.c +0 -1

  };
  MODULE_DEVICE_TABLE(pci, blogic_pci_tbl);
-#endif

You don't need to do this in two steps. The original problem of defined but not used table stopped being a problem when the structure was converted to static const over ten years ago (the compiler doesn't warn about unused static consts).