Thread (9 messages) 9 messages, 5 authors, 2018-05-10

Re: Differences between builtins and modules

From: Michal Marek <hidden>
Date: 2015-02-25 11:53:40
Also in: lkml
Subsystem: generic include/asm header files, module support, the rest · Maintainers: Arnd Bergmann, Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen, Linus Torvalds

On Tue, Feb 24, 2015 at 10:02:55PM -0300, Lucas De Marchi wrote:
On Mon, Feb 23, 2015 at 12:51 PM, Michal Marek [off-list ref] wrote:
quoted
On 2015-02-23 15:30, Lucas De Marchi wrote:
quoted
My questions are:
1) should we put *all* the "modules" in the builtin index?
You mean all *.o files that do not end up in some *.ko? That won't work,
because unlike module names, the names of object files are not global.
I was actually meaning anything that can have a directory under
/sys/module/. I figure we can't easily know this.
I see. Well, we could generate the .modinfo section also for builtin
object files and discard it from vmlinux later, like this:
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index ac78910..efe1798 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -683,6 +683,7 @@
 	EXIT_CALL							\
 	*(.discard)							\
 	*(.discard.*)							\
+	*(.modinfo)							\
 	}
 
 /**
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 1c9effa..f38abfa 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -16,23 +16,17 @@
 /* Chosen so that structs with an unsigned long line up. */
 #define MAX_PARAM_PREFIX_LEN (64 - sizeof(unsigned long))
 
-#ifdef MODULE
 #define __MODULE_INFO(tag, name, info)					  \
 static const char __UNIQUE_ID(name)[]					  \
   __used __attribute__((section(".modinfo"), unused, aligned(1)))	  \
   = __stringify(tag) "=" info
-#else  /* !MODULE */
-/* This struct is here for syntactic coherency, it is not used */
-#define __MODULE_INFO(tag, name, info)					  \
-  struct __UNIQUE_ID(name) {}
-#endif
 #define __MODULE_PARM_TYPE(name, _type)					  \
-  __MODULE_INFO(parmtype, name##type, #name ":" _type)
+  __MODULE_INFO(parmtype, name##type, MODULE_PARAM_PREFIX #name ":" _type)
 
 /* One for each parameter, describing how to use it.  Some files do
    multiple of these per line, so can't just use MODULE_INFO. */
 #define MODULE_PARM_DESC(_parm, desc) \
-	__MODULE_INFO(parm, _parm, #_parm ":" desc)
+	__MODULE_INFO(parm, _parm, MODULE_PARAM_PREFIX #_parm ":" desc)
 
 struct kernel_param;
 
Then some script would look at the parmtype= fields in the built-in.o
files and complement the list of builtin modules. However, the question
is whether this is worth it. As far as I understand, the problem is just
the discrepancy between modules.builtin and /sys/module. In practice, no
sane tool is going to need to modprobe 'vt' or 'printk', because there
is no configuration in which these modules would exist.

quoted
Plus, there was IIRC an idea to teach lsmod to print builtin modules --
listing all *.o would make it rather useless.
This was one of my ideas... to traverse /sys/module and give more
information than we actually output right now, including builtin
modules. However, given the fact that builtin modules only have an
entry in /sys/module if they have params and now that I'm aware of the
race between the creation of the directory and the initstate file, I'm
giving up on this idea for now.
You could still print the module names from modules.builtin(.idx). But
this is an unrelated topic, I only brought it up because I did not
understand what you were proposing.

Michal
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help