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

[Jessica Yu]

+++ Masahiro Yamada [19/04/19 00:26 +0900]:
> On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu <jeyu@xxxxxxxxxx> wrote:
> > +++ Masahiro Yamada [18/04/19 20:10 +0900]:
> > >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <gladkov.alexey@xxxxxxxxx> wrote:
> > >>
> > >> 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.
> > >>
> > >> 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.
> > >>
> > >> 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.
> > >>
> > >> Proposal:
> > >>
> > >> The proposed patch does not remove .modinfo section with module
> > >> information from the vmlinux at the build time and saves it into a
> > >> separate file after kernel linking. So, the kernel does not increase in
> > >> size and no additional information remains in it. Information is stored
> > >> in the same format as in the separate modules (null-terminated string
> > >> array). Because the .modinfo section is already exported with a separate
> > >> modules, we are not creating a new API.
> > >>
> > >> It can be easily read in the userspace:
> > >>
> > >> $ tr '\0' '\n' < kernel.builtin
> > >> ext4.softdep=pre: crc32c
> > >> ext4.license=GPL
> > >> ext4.description=Fourth Extended Filesystem
> > >> ext4.author=Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
> > >> ext4.alias=fs-ext4
> > >> ext4.alias=ext3
> > >> ext4.alias=fs-ext3
> > >> ext4.alias=ext2
> > >> ext4.alias=fs-ext2
> > >> md_mod.alias=block-major-9-*
> > >> md_mod.alias=md
> > >> md_mod.description=MD RAID framework
> > >> md_mod.license=GPL
> > >> md_mod.parmtype=create_on_open:bool
> > >> md_mod.parmtype=start_dirty_degraded:int
> > >> ...
> > >>
> > >> v2:
> > >>  * Extract modinfo from vmlinux.o as suggested by Masahiro Yamada;
> > >>  * Rename output file to kernel.builtin;
> > >
> > >Sorry, I do not get why you renamed
> > >"kernel.builtin.modinfo" to "kernel.builtin".
> > >
> > >If you drop "modinfo", we do not understand
> > >what kind information is contained in it.
> > >
> > >I think "kernel" and "builtin" have
> > >a quite similar meaning here.
> > >
> > >How about "builtin.modinfo" for example?
> > >
> > >
> > >It is shorter, and it is clear enough
> > >that it contains module_info.
> >
> > I agree that the name kernel.builtin is unclear in what kind of
> > information it contains. Apologies for not having clarified this in
> > the previous review.
> >
> > Since kbuild already produces "modules.order" and "modules.builtin"
> > files, why not just name it "modules.builtin.modinfo" to keep the
> > names consistent with what is already there?
>
>
> Is it consistent?
>
> If we had "modules.order" and "modules.builtin.order" there,
> I would agree with "modules.builtin.modinfo",
> and also "modules.alias" vs "modules.builtin.alias".
>
>
> We already have "modules.builtin", and probably impossible
> to rename it, so we cannot keep consistency in any way.
>
>
> "modules.builtin" is a weird name since
> it actually contains "order", but its extension
> does not express what kind of information is in it.
> Hence, I doubt "modules.builtin" is a good precedent.
>
> IMHO, "modules" and "builtin" are opposite
> to each other. "modules.builtin" sounds iffy to me.

I've always interpreted "modules.builtin" to mean "this is a list of
modules that have been built-in into the kernel", no? So I thought the
name made sense. But you are the maintainer, so I do not have a strong
opinion on this either way :-)

Thanks,

Jessica