Thread (13 messages) flat view 13 messages, 6 authors, 2019-04-03

Re: [RESEND PATCH v1] moduleparam: Save information about built-in modules in separate file

From: Alexey Gladkov <hidden>
Date: 2019-03-27 16:04:53
Also in: linux-kbuild, lkml

On Wed, Mar 27, 2019 at 04:40:25PM +0100, Jessica Yu wrote:
quoted hunk ↗ jump to hunk
+++ Alexey Gladkov [26/03/19 18:24 +0100]:
quoted
On Fri, Mar 22, 2019 at 02:34:12PM +0900, Masahiro Yamada wrote:
quoted
Hi.

(added some people to CC)
(Thanks Masahiro for the CC!)
quoted
quoted
On Fri, Mar 15, 2019 at 7:10 PM Alexey Gladkov [off-list ref] wrote:
quoted
Problem:

When a kernel module is compiled as a separate module, some important
information about the kernel module is available via .modinfo section of
the module.  In contrast, when the kernel module is compiled into the
kernel, that information is not available.

I might be missing something, but
vmlinux provides info of builtin modules
in /sys/module/.
No. There are definitely not all modules. I have a builtin sha256_generic,
but I can't find him in the /sys/module.
Yeah, you'll only find builtin modules under /sys/module/ if it has any module
parameters, otherwise you won't find it there. As Masahiro already mentioned,
if a builtin module has any parameters, they would be accessible under /sys/module/.
quoted
quoted
(Looks like currently only module_param and MODULE_VERSION)

This patch is not exactly the same, but I see a kind of overwrap.
I'd like to be sure if we want this new scheme.
The /sys/module is only for running kernel. One of my use cases is
to create an initrd for a new kernel.
quoted
quoted
Information about built-in modules is necessary in the following cases:

1. When it is necessary to find out what additional parameters can be
passed to the kernel at boot time.

Actually, /sys/module/<module>/parameters/
exposes this information.

Doesn't it work for your purpose?
No, since creating an initrd needs to know all the modalias before
I get the sysfs for new kernel. Also there are no modalias at all.
quoted
quoted
2. When you need to know which module names and their aliases are in
the kernel. This is very useful for creating an initrd image.
Hm, I do see one possible additional use-case for preserving module alias
information for built-in modules - modprobe will currently error (I think,
correct me if I'm wrong) if we try invoking modprobe with an alias of a
built-in module, simply because this information is not in modules.builtin or
modules.alias.
Yes. Patch for modprobe in my todo list. The reason I didn’t do it was
because I wasn’t sure that the file format was final.
Since kbuild already outputs modules.builtin, I would suggest outputting
something like a modules.builtin.alias file (and I guess maybe a modules.builtin.param
file too if that's deemed useful), in a format that is consumable by kmod/modprobe,
so that modprobing an alias of a built-in module doesn't produce an error. I
think this should be easy to do if we keep and parse the resulting .modinfo for
builtin modules. This is just an idea, opinions welcome. I've added Lucas to CC
in case he has any thoughts.
You don't like kernel.builtin.modinfo ?

It is much easier to create and it has almost the same format as the
modules. So I think it will be easier to parse in kmod.

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