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;
* Add MODULE_VERSION to modinfo that is saved to the kernel.builtin;
* Fix build warnings on powerpc.
Co-Developed-by: Gleb Fotengauer-Malinovskiy <[email protected]>
Signed-off-by: Gleb Fotengauer-Malinovskiy <[email protected]>
Signed-off-by: Alexey Gladkov <[email protected]>
---
.gitignore | 1 +
Makefile | 2 ++
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/module.h | 1 +
include/linux/moduleparam.h | 12 +++++-------
scripts/link-vmlinux.sh | 4 ++++
6 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/.gitignore b/.gitignore
index a20ac26aa2f5..432332fd745e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -45,6 +45,7 @@
*.xz
Module.symvers
modules.builtin
+kernel.builtin
#
# Top-level generic files
diff --git a/Makefile b/Makefile
index d5713e7b1e50..d9dc6211fbc7 100644
--- a/Makefile
+++ b/Makefile
@@ -1288,6 +1288,7 @@ _modinst_:
fi
@cp -f $(objtree)/modules.order $(MODLIB)/
@cp -f $(objtree)/modules.builtin $(MODLIB)/
+ @cp -f $(objtree)/kernel.builtin $(MODLIB)/
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
# This depmod is only for convenience to give the initial
@@ -1328,6 +1329,7 @@ endif # CONFIG_MODULES
# Directories & files removed with 'make clean'
CLEAN_DIRS += $(MODVERDIR) include/ksym
+CLEAN_FILES += kernel.builtin
# Directories & files removed with 'make mrproper'
MRPROPER_DIRS += include/config usr/include include/generated \
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 3d7a6a9c2370..44c724bf7d3a 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -844,6 +844,7 @@
EXIT_CALL \
*(.discard) \
*(.discard.*) \
+ *(.modinfo) \
}
/**
diff --git a/include/linux/module.h b/include/linux/module.h
index f5bc4c046461..1cae28b1172a 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -237,6 +237,7 @@ extern typeof(name) __mod_##type##__##name##_device_table \
#define MODULE_VERSION(_version) MODULE_INFO(version, _version)
#else
#define MODULE_VERSION(_version) \
+ MODULE_INFO(version, _version); \
static struct module_version_attribute ___modver_attr = { \
.mattr = { \
.attr = { \
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index ba36506db4fb..5ba250d9172a 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -10,23 +10,21 @@
module name. */
#ifdef MODULE
#define MODULE_PARAM_PREFIX /* empty */
+#define __MODULE_INFO_PREFIX /* empty */
#else
#define MODULE_PARAM_PREFIX KBUILD_MODNAME "."
+/* We cannot use MODULE_PARAM_PREFIX because some modules override it. */
+#define __MODULE_INFO_PREFIX KBUILD_MODNAME "."
#endif
/* 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
+ = __MODULE_INFO_PREFIX __stringify(tag) "=" info
+
#define __MODULE_PARM_TYPE(name, _type) \
__MODULE_INFO(parmtype, name##type, #name ":" _type)
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index c8cf45362bd6..b914e026ef28 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -226,6 +226,10 @@ modpost_link vmlinux.o
# modpost vmlinux.o to check for section mismatches
${MAKE} -f "${srctree}/scripts/Makefile.modpost" vmlinux.o
+info MODINFO kernel.builtin
+"${OBJCOPY}" -j .modinfo -O binary vmlinux.o kernel.builtin
+chmod 444 kernel.builtin
+
kallsymso=""
kallsyms_vmlinux=""
if [ -n "${CONFIG_KALLSYMS}" ]; then
--
2.21.0
On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <[email protected]> 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.
> * Add MODULE_VERSION to modinfo that is saved to the kernel.builtin;
> * Fix build warnings on powerpc.
>
> Co-Developed-by: Gleb Fotengauer-Malinovskiy <[email protected]>
> Signed-off-by: Gleb Fotengauer-Malinovskiy <[email protected]>
> Signed-off-by: Alexey Gladkov <[email protected]>
> ---
> diff --git a/.gitignore b/.gitignore
> index a20ac26aa2f5..432332fd745e 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -45,6 +45,7 @@
> *.xz
> Module.symvers
> modules.builtin
> +kernel.builtin
This file is generated only in the top of the tree.
Please add '/' prefix and move it to
the "# Top-level generic files" section.
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index c8cf45362bd6..b914e026ef28 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -226,6 +226,10 @@ modpost_link vmlinux.o
> # modpost vmlinux.o to check for section mismatches
> ${MAKE} -f "${srctree}/scripts/Makefile.modpost" vmlinux.o
>
> +info MODINFO kernel.builtin
> +"${OBJCOPY}" -j .modinfo -O binary vmlinux.o kernel.builtin
> +chmod 444 kernel.builtin
Could you explain why this "chmod" is necessary?
Thanks.
--
Best Regards
Masahiro Yamada
+++ Masahiro Yamada [18/04/19 20:10 +0900]:
>On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <[email protected]> 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? It clearly conveys that
this file contains modinfo for builtin modules.
I'll leave it up to Lucas to decide if the file format is OK for kmod.
With the modinfo dump, kmod could then decide what to do with the
information, append to modules.alias{,.bin}, etc.
Also, I think this file needs to be documented in Documentation/kbuild/kbuild.txt.
Thanks,
Jessica
On Thu, Apr 18, 2019 at 6:52 AM Jessica Yu <[email protected]> wrote:
>
> +++ Masahiro Yamada [18/04/19 20:10 +0900]:
> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <[email protected]> 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
I agree with modules.builtin.modinfo
> names consistent with what is already there? It clearly conveys that
> this file contains modinfo for builtin modules.
>
> I'll leave it up to Lucas to decide if the file format is OK for kmod.
> With the modinfo dump, kmod could then decide what to do with the
> information, append to modules.alias{,.bin}, etc.
I think it's ok with the current format. It's simple enough. I would
delay merging it until
the userspace counterpart is implemented though. So to make sure we
have everything we need.
I can work on that in ~1 or 2 weeks.
thanks
Lucas De Marchi
>
> Also, I think this file needs to be documented in Documentation/kbuild/kbuild.txt.
>
> Thanks,
>
> Jessica
--
Lucas De Marchi
On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu <[email protected]> wrote:
>
> +++ Masahiro Yamada [18/04/19 20:10 +0900]:
> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <[email protected]> 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.
> It clearly conveys that
> this file contains modinfo for builtin modules.
>
> I'll leave it up to Lucas to decide if the file format is OK for kmod.
> With the modinfo dump, kmod could then decide what to do with the
> information, append to modules.alias{,.bin}, etc.
>
> Also, I think this file needs to be documented in Documentation/kbuild/kbuild.txt.
>
> Thanks,
>
> Jessica
--
Best Regards
Masahiro Yamada
+++ Masahiro Yamada [19/04/19 00:26 +0900]:
>On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu <[email protected]> wrote:
>>
>> +++ Masahiro Yamada [18/04/19 20:10 +0900]:
>> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <[email protected]> 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
On Fri, Apr 19, 2019 at 12:36 AM Jessica Yu <[email protected]> wrote:
>
> +++ Masahiro Yamada [19/04/19 00:26 +0900]:
> >On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu <[email protected]> wrote:
> >>
> >> +++ Masahiro Yamada [18/04/19 20:10 +0900]:
> >> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <[email protected]> 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.
OK, I see.
> But you are the maintainer, so I do not have a strong
> opinion on this either way :-)
My idea was to use
'modules.<file-type>' vs 'builtin.<file-type>'
instead of
'modules.<file-type>' vs 'modules.builtin.<file-type>'
I am slightly in favor of the former
since it is shorter and
(I hope) still clear enough.
If this naming is not nice for external projects such as kmod,
please speak up.
(BTW, I am thinking of renaming 'modules.builtin' into 'builtin.order'
for kbuild internal. We cannot change that for the installation area, though.)
>
> Thanks,
>
> Jessica
--
Best Regards
Masahiro Yamada
On Fri, Apr 19, 2019 at 12:03:50PM +0900, Masahiro Yamada wrote:
> On Fri, Apr 19, 2019 at 12:36 AM Jessica Yu <[email protected]> wrote:
> >
> > +++ Masahiro Yamada [19/04/19 00:26 +0900]:
> > >On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu <[email protected]> wrote:
> > >>
> > >> +++ Masahiro Yamada [18/04/19 20:10 +0900]:
> > >> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <[email protected]> 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.
>
> OK, I see.
>
> > But you are the maintainer, so I do not have a strong
> > opinion on this either way :-)
>
> My idea was to use
> 'modules.<file-type>' vs 'builtin.<file-type>'
> instead of
> 'modules.<file-type>' vs 'modules.builtin.<file-type>'
>
> I am slightly in favor of the former
> since it is shorter and
> (I hope) still clear enough.
>
> If this naming is not nice for external projects such as kmod,
> please speak up.
>
>
> (BTW, I am thinking of renaming 'modules.builtin' into 'builtin.order'
> for kbuild internal. We cannot change that for the installation area, though.)
Since there were no other suggestions, how can I better name the file ?
modules.builtin.modinfo or just builtin.modinfo ? I personally like the
first one more.
--
Rgrds, legion
On Sat, Apr 27, 2019 at 12:29 AM Alexey Gladkov
<[email protected]> wrote:
>
> On Fri, Apr 19, 2019 at 12:03:50PM +0900, Masahiro Yamada wrote:
> > On Fri, Apr 19, 2019 at 12:36 AM Jessica Yu <[email protected]> wrote:
> > >
> > > +++ Masahiro Yamada [19/04/19 00:26 +0900]:
> > > >On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu <[email protected]> wrote:
> > > >>
> > > >> +++ Masahiro Yamada [18/04/19 20:10 +0900]:
> > > >> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <[email protected]> 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.
> >
> > OK, I see.
> >
> > > But you are the maintainer, so I do not have a strong
> > > opinion on this either way :-)
> >
> > My idea was to use
> > 'modules.<file-type>' vs 'builtin.<file-type>'
> > instead of
> > 'modules.<file-type>' vs 'modules.builtin.<file-type>'
> >
> > I am slightly in favor of the former
> > since it is shorter and
> > (I hope) still clear enough.
> >
> > If this naming is not nice for external projects such as kmod,
> > please speak up.
> >
> >
> > (BTW, I am thinking of renaming 'modules.builtin' into 'builtin.order'
> > for kbuild internal. We cannot change that for the installation area, though.)
>
> Since there were no other suggestions, how can I better name the file ?
> modules.builtin.modinfo or just builtin.modinfo ? I personally like the
> first one more.
Either is fine.
Please put it in Documentation/dontdiff too.
Thanks.
--
Best Regards
Masahiro Yamada