| Message ID | 20190406121447.GB4047@localhost.localdomain (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] moduleparam: Save information about built-in modules in separate file | expand |
On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <gladkov.alexey@gmail.com> 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 <glebfm@altlinux.org> > Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org> > Signed-off-by: Alexey Gladkov <gladkov.alexey@gmail.com> > --- > 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 <gladkov.alexey@gmail.com> 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 <jeyu@kernel.org> wrote: > > +++ Masahiro Yamada [18/04/19 20:10 +0900]: > >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <gladkov.alexey@gmail.com> 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
On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu <jeyu@kernel.org> wrote: > > +++ Masahiro Yamada [18/04/19 20:10 +0900]: > >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <gladkov.alexey@gmail.com> 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 <jeyu@kernel.org> wrote: >> >> +++ Masahiro Yamada [18/04/19 20:10 +0900]: >> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <gladkov.alexey@gmail.com> 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 <jeyu@kernel.org> wrote: > > +++ Masahiro Yamada [19/04/19 00:26 +0900]: > >On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu <jeyu@kernel.org> wrote: > >> > >> +++ Masahiro Yamada [18/04/19 20:10 +0900]: > >> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <gladkov.alexey@gmail.com> 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
On Fri, Apr 19, 2019 at 12:03:50PM +0900, Masahiro Yamada wrote: > On Fri, Apr 19, 2019 at 12:36 AM Jessica Yu <jeyu@kernel.org> wrote: > > > > +++ Masahiro Yamada [19/04/19 00:26 +0900]: > > >On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu <jeyu@kernel.org> wrote: > > >> > > >> +++ Masahiro Yamada [18/04/19 20:10 +0900]: > > >> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <gladkov.alexey@gmail.com> 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.
On Sat, Apr 27, 2019 at 12:29 AM Alexey Gladkov <gladkov.alexey@gmail.com> 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 <jeyu@kernel.org> wrote: > > > > > > +++ Masahiro Yamada [19/04/19 00:26 +0900]: > > > >On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu <jeyu@kernel.org> wrote: > > > >> > > > >> +++ Masahiro Yamada [18/04/19 20:10 +0900]: > > > >> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov <gladkov.alexey@gmail.com> 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.
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