Re: [PATCH v2] moduleparam: Save information about built-in modules in separate file
On Sat, Apr 27, 2019 at 12:29 AM Alexey Gladkov 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 wrote: > > > > > > +++ Masahiro Yamada [19/04/19 00:26 +0900]: > > > >On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu wrote: > > > >> > > > >> +++ Masahiro Yamada [18/04/19 20:10 +0900]: > > > >> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov > > > >> > 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.' vs 'builtin.' > > instead of > > 'modules.' vs 'modules.builtin.' > > > > I am slightly in favor of the former > > since it is shorter and > > (I hope) still clear enough. > > > > If this
Re: [PATCH v2] moduleparam: Save information about built-in modules in separate file
On Fri, Apr 19, 2019 at 12:03:50PM +0900, Masahiro Yamada wrote: > On Fri, Apr 19, 2019 at 12:36 AM Jessica Yu wrote: > > > > +++ Masahiro Yamada [19/04/19 00:26 +0900]: > > >On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu wrote: > > >> > > >> +++ Masahiro Yamada [18/04/19 20:10 +0900]: > > >> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov > > >> > 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.' vs 'builtin.' > instead of > 'modules.' vs 'modules.builtin.' > > 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
Re: [PATCH v2] moduleparam: Save information about built-in modules in separate file
On Fri, Apr 19, 2019 at 12:36 AM Jessica Yu wrote: > > +++ Masahiro Yamada [19/04/19 00:26 +0900]: > >On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu wrote: > >> > >> +++ Masahiro Yamada [18/04/19 20:10 +0900]: > >> >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov > >> >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.' vs 'builtin.' instead of 'modules.' vs 'modules.builtin.' 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
Re: [PATCH v2] moduleparam: Save information about built-in modules in separate file
+++ Masahiro Yamada [19/04/19 00:26 +0900]: On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu wrote: +++ Masahiro Yamada [18/04/19 20:10 +0900]: >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov 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
Re: [PATCH v2] moduleparam: Save information about built-in modules in separate file
On Thu, Apr 18, 2019 at 10:52 PM Jessica Yu wrote: > > +++ Masahiro Yamada [18/04/19 20:10 +0900]: > >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov > >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
Re: [PATCH v2] moduleparam: Save information about built-in modules in separate file
On Thu, Apr 18, 2019 at 6:52 AM Jessica Yu wrote: > > +++ Masahiro Yamada [18/04/19 20:10 +0900]: > >On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov > >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
Re: [PATCH v2] moduleparam: Save information about built-in modules in separate file
+++ Masahiro Yamada [18/04/19 20:10 +0900]: On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov 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
Re: [PATCH v2] moduleparam: Save information about built-in modules in separate file
On Sat, Apr 6, 2019 at 9:15 PM Alexey Gladkov 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 > Signed-off-by: Gleb Fotengauer-Malinovskiy > Signed-off-by: Alexey Gladkov > --- > 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
[PATCH v2] moduleparam: Save information about built-in modules in separate file
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 Signed-off-by: Gleb Fotengauer-Malinovskiy Signed-off-by: Alexey Gladkov --- .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