| Message ID | 20250608104459.1888510-1-dixitparmar19@gmail.com |
|---|---|
| State | Under Review |
| Headers | show |
| Series | [v2] ref-manual: document KERNEL_SPLIT_MODULES variable | expand |
On Sun Jun 8, 2025 at 12:44 PM CEST, Dixit Parmar via lists.yoctoproject.org wrote: > This variable controls the kernel module spliting. > > Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> > --- > documentation/ref-manual/variables.rst | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst > index 9768d8f5b..b7dde2604 100644 > --- a/documentation/ref-manual/variables.rst > +++ b/documentation/ref-manual/variables.rst > @@ -5359,6 +5359,20 @@ system and gives an overview of their function and contents. > the :term:`KERNEL_PATH` variable. Both variables are common variables > used by external Makefiles to point to the kernel source directory. > > + :term:`KERNEL_SPLIT_MODULES` > + When inheriting the :ref:`ref-classes-kernel-module-split` class, this > + variable controls whether kernel modules are split into separate packages > + or bundled into a single package. > + > + For some use cases, a monolithic kernel module package > + :ref:`KERNEL_PACKAGE_NAME` (by default named ``kernel``) that contains This should be :term:`KERNEL_PACKAGE_NAME` (not :ref:). Otherwise fails to build. > + all modules built from the kernel sources may be preferred. Because a > + monolithic package can reduce download time and speed up installation. I think this can be simplified by "...may be preferred to speed up installation". "Download time" is too context specific, probably related to package management on the target. > + > + By default, this variable is set to ``1``, resulting in one package per > + module. Setting it to any other value will generate a single monolithic > + package containing all kernel modules. > + > :term:`KERNEL_SRC` > The location of the kernel sources. This variable is set to the value > of the :term:`STAGING_KERNEL_DIR` within the :ref:`ref-classes-module` Thanks, Antonin
On Tue Jun 10, 2025 at 10:55 AM CEST, Antonin Godard wrote: > On Sun Jun 8, 2025 at 12:44 PM CEST, Dixit Parmar via lists.yoctoproject.org wrote: >> This variable controls the kernel module spliting. >> >> Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> >> --- >> documentation/ref-manual/variables.rst | 14 ++++++++++++++ >> 1 file changed, 14 insertions(+) >> >> diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst >> index 9768d8f5b..b7dde2604 100644 >> --- a/documentation/ref-manual/variables.rst >> +++ b/documentation/ref-manual/variables.rst >> @@ -5359,6 +5359,20 @@ system and gives an overview of their function and contents. >> the :term:`KERNEL_PATH` variable. Both variables are common variables >> used by external Makefiles to point to the kernel source directory. >> >> + :term:`KERNEL_SPLIT_MODULES` >> + When inheriting the :ref:`ref-classes-kernel-module-split` class, this >> + variable controls whether kernel modules are split into separate packages >> + or bundled into a single package. >> + >> + For some use cases, a monolithic kernel module package >> + :ref:`KERNEL_PACKAGE_NAME` (by default named ``kernel``) that contains > > This should be :term:`KERNEL_PACKAGE_NAME` (not :ref:). Otherwise fails to > build. > >> + all modules built from the kernel sources may be preferred. Because a >> + monolithic package can reduce download time and speed up installation. > > I think this can be simplified by "...may be preferred to speed up > installation". "Download time" is too context specific, probably related to > package management on the target. > >> + >> + By default, this variable is set to ``1``, resulting in one package per >> + module. Setting it to any other value will generate a single monolithic >> + package containing all kernel modules. >> + >> :term:`KERNEL_SRC` >> The location of the kernel sources. This variable is set to the value >> of the :term:`STAGING_KERNEL_DIR` within the :ref:`ref-classes-module` Not sure about the "kernel" package name. After building with KERNEL_SPLIT_MODULES to 0: $ bitbake-getvar KERNEL_PACKAGE_NAME -r virtual/kernel # # $KERNEL_PACKAGE_NAME [2 operations] # set /build/../work/openembedded-core/meta/conf/documentation.conf:253 # [doc] "Name prefix for kernel packages. Defaults to 'kernel'." # set /build/../work/openembedded-core/meta/classes-recipe/kernel.bbclass:11 # [_defaultval] "kernel" # pre-expansion value: # "kernel" KERNEL_PACKAGE_NAME="kernel" $ oe-pkgdata-util list-pkgs | grep kernel kernel kernel-base kernel-dbg kernel-dev kernel-image kernel-image-image kernel-modules kernel-vmlinux $ oe-pkgdata-util list-pkg-files kernel-modules | head -7 kernel-modules: /lib/modules/6.12.30-yocto-standard/kernel/crypto/af_alg.ko /lib/modules/6.12.30-yocto-standard/kernel/crypto/algif_aead.ko /lib/modules/6.12.30-yocto-standard/kernel/crypto/algif_hash.ko /lib/modules/6.12.30-yocto-standard/kernel/crypto/algif_rng.ko /lib/modules/6.12.30-yocto-standard/kernel/crypto/algif_skcipher.ko /lib/modules/6.12.30-yocto-standard/kernel/crypto/blowfish_common.ko ... So it seems to me that the name of the package is "kernel-modules", not "kernel"? Another side question: in my experience I never had to set KERNEL_SPLIT_MODULES to be able to install *all* kernel modules. Whatever the value of KERNEL_SPLIT_MODULES, installing the package "kernel-modules" would just install the modules. So what is the difference after setting this variable? Antonin
Will fix the ref->term typo and the take your suggestion on rewording. There seem to be confusion related to the kernel package name, however I feel it was additional information. I shall remove the mention of the kernel package name (keep the variable reference only) for simplicity in next version. Another side question: in my experience I never had to set KERNEL_SPLIT_MODULES to be able to install *all* kernel modules. Whatever the value of KERNEL_SPLIT_MODULES, installing the package "kernel-modules" would just install the modules. So what is the difference after setting this variable? Yes, you would be able to install "all" the kernel-modules without bothering about KERNEL_SPLIT_MODULES. The issue is having autoload .conf file being installed or not when KERNEL_MODULE_AUTOLOAD is having your modules listed to be autoloader. When KERNEL_SPLIT_MODULES = 0 the .conf files for driver autoload and probeconf is not getting generated.
On Wed Jun 18, 2025 at 2:14 PM CEST, Dixit Parmar via lists.yoctoproject.org wrote: > Will fix the ref->term typo and the take your suggestion on rewording. > > There seem to be confusion related to the kernel package name, however I feel > it was additional information. I shall remove the mention of the kernel > package name (keep the variable reference only) for simplicity in next > version. Looking forward to it! > Yes, you would be able to install "all" the kernel-modules without bothering > about KERNEL_SPLIT_MODULES. The issue is having autoload .conf file being > installed or not when KERNEL_MODULE_AUTOLOAD is having your modules listed to > be autoloader. When KERNEL_SPLIT_MODULES = 0 the .conf files for driver > autoload and probeconf is not getting generated. This sounds like a bug to me, no? Why would someone expect setting KERNEL_SPLIT_MODULES to 0 have the autoload files missing? I ran a some tests. So when I set KERNEL_SPLIT_MODULES to 1, and KERNEL_MODULE_AUTOLOAD to "xt_limit", a kernel-module-xt-limit.ipk package is generated like so: ├── etc │ └── modules-load.d │ └── xt_limit.conf └── lib └── modules └── 6.12.30-yocto-standard └── kernel └── net └── netfilter └── xt_limit.ko When KERNEL_SPLIT_MODULES is set to 0, only one kernel-modules.ipk package is generated, and does _not_ contain xt_limit.conf, but only xt_limit.ko. To me this sounds like a bug, what do you think? I would _not_ describe that behavior in the documentation for the KERNEL_SPLIT_MODULES variables. The fact that "kernel-modules" is still available when KERNEL_SPLIT_MODULES = 1 is simply because a "fake" kernel-modules.ipk package is generated, and depends on the other kernel-module-* packages - so you can ignore my remark in my previous message. Thanks, Antonin
On Wed, Jun 18, 2025 at 06:30 PM, Antonin Godard wrote: > > On Wed Jun 18, 2025 at 2:14 PM CEST, Dixit Parmar via > lists.yoctoproject.org wrote: > >> Will fix the ref->term typo and the take your suggestion on rewording. >> >> There seem to be confusion related to the kernel package name, however I >> feel >> it was additional information. I shall remove the mention of the kernel >> package name (keep the variable reference only) for simplicity in next >> version. > > Looking forward to it! > > >> Yes, you would be able to install "all" the kernel-modules without >> bothering >> about KERNEL_SPLIT_MODULES. The issue is having autoload .conf file being >> installed or not when KERNEL_MODULE_AUTOLOAD is having your modules listed >> to >> be autoloader. When KERNEL_SPLIT_MODULES = 0 the .conf files for driver >> autoload and probeconf is not getting generated. > > This sounds like a bug to me, no? Why would someone expect setting > KERNEL_SPLIT_MODULES to 0 have the autoload files missing? > > I ran a some tests. So when I set KERNEL_SPLIT_MODULES to 1, and > KERNEL_MODULE_AUTOLOAD to "xt_limit", a kernel-module-xt-limit.ipk package > is > generated like so: > > ├── etc > │ └── modules-load.d > │ └── xt_limit.conf > └── lib > └── modules > └── 6.12.30-yocto-standard > └── kernel > └── net > └── netfilter > └── xt_limit.ko > > When KERNEL_SPLIT_MODULES is set to 0, only one kernel-modules.ipk package > is > generated, and does _not_ contain xt_limit.conf, but only xt_limit.ko. To > me > this sounds like a bug, what do you think? Exactly, that's the issue reported https://bugzilla.yoctoproject.org/show_bug.cgi?id=15145 ( https://bugzilla.yoctoproject.org/show_bug.cgi?id=15145 ) and I am fixing it here with this solution https://lists.openembedded.org/g/openembedded-core/message/218290. > > I would _not_ describe that behavior in the documentation for the > KERNEL_SPLIT_MODULES variables. True, that's why the documentation does not mention anything about the conf files. > > The fact that "kernel-modules" is still available when > KERNEL_SPLIT_MODULES = 1 > is simply because a "fake" kernel-modules.ipk package is generated, and > depends > on the other kernel-module-* packages - so you can ignore my remark in my > previous message. Which remark exactly?? > > Thanks, > Antonin > > -- > Antonin Godard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
On Wed Jun 18, 2025 at 3:19 PM CEST, Dixit Parmar via lists.yoctoproject.org wrote: > On Wed, Jun 18, 2025 at 06:30 PM, Antonin Godard wrote: > >> >> On Wed Jun 18, 2025 at 2:14 PM CEST, Dixit Parmar via >> lists.yoctoproject.org wrote: >> >>> Will fix the ref->term typo and the take your suggestion on rewording. >>> >>> There seem to be confusion related to the kernel package name, however I >>> feel >>> it was additional information. I shall remove the mention of the kernel >>> package name (keep the variable reference only) for simplicity in next >>> version. >> >> Looking forward to it! >> >> >>> Yes, you would be able to install "all" the kernel-modules without >>> bothering >>> about KERNEL_SPLIT_MODULES. The issue is having autoload .conf file being >>> installed or not when KERNEL_MODULE_AUTOLOAD is having your modules listed >>> to >>> be autoloader. When KERNEL_SPLIT_MODULES = 0 the .conf files for driver >>> autoload and probeconf is not getting generated. >> >> This sounds like a bug to me, no? Why would someone expect setting >> KERNEL_SPLIT_MODULES to 0 have the autoload files missing? >> >> I ran a some tests. So when I set KERNEL_SPLIT_MODULES to 1, and >> KERNEL_MODULE_AUTOLOAD to "xt_limit", a kernel-module-xt-limit.ipk package >> is >> generated like so: >> >> ├── etc >> │ └── modules-load.d >> │ └── xt_limit.conf >> └── lib >> └── modules >> └── 6.12.30-yocto-standard >> └── kernel >> └── net >> └── netfilter >> └── xt_limit.ko >> >> When KERNEL_SPLIT_MODULES is set to 0, only one kernel-modules.ipk package >> is >> generated, and does _not_ contain xt_limit.conf, but only xt_limit.ko. To >> me >> this sounds like a bug, what do you think? > > Exactly, that's the issue reported https://bugzilla.yoctoproject.org/show_bug.cgi?id=15145 ( https://bugzilla.yoctoproject.org/show_bug.cgi?id=15145 ) and I am fixing it here with this solution https://lists.openembedded.org/g/openembedded-core/message/218290. > >> >> I would _not_ describe that behavior in the documentation for the >> KERNEL_SPLIT_MODULES variables. > > True, that's why the documentation does not mention anything about the conf files. > >> >> The fact that "kernel-modules" is still available when >> KERNEL_SPLIT_MODULES = 1 >> is simply because a "fake" kernel-modules.ipk package is generated, and >> depends >> on the other kernel-module-* packages - so you can ignore my remark in my >> previous message. > > Which remark exactly?? About the possibility to install "kernel-modules" both when KERNEL_SPLIT_MODULES is 0 or 1. I guess it doesn't hurt to add a note about that at the end of the definition: """ .. note:: If :term:`KERNEL_SPLIT_MODULES` is set to 0, it is still possible to install all kernel modules at once by adding ``kernel-modules`` to :term:`IMAGE_INSTALL`. The way it works is that a placeholder "kernel-modules" package will be created and will depend on every other individual kernel module packages. """ So there's no confusion. What do you think? Antonin
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst index 9768d8f5b..b7dde2604 100644 --- a/documentation/ref-manual/variables.rst +++ b/documentation/ref-manual/variables.rst @@ -5359,6 +5359,20 @@ system and gives an overview of their function and contents. the :term:`KERNEL_PATH` variable. Both variables are common variables used by external Makefiles to point to the kernel source directory. + :term:`KERNEL_SPLIT_MODULES` + When inheriting the :ref:`ref-classes-kernel-module-split` class, this + variable controls whether kernel modules are split into separate packages + or bundled into a single package. + + For some use cases, a monolithic kernel module package + :ref:`KERNEL_PACKAGE_NAME` (by default named ``kernel``) that contains + all modules built from the kernel sources may be preferred. Because a + monolithic package can reduce download time and speed up installation. + + By default, this variable is set to ``1``, resulting in one package per + module. Setting it to any other value will generate a single monolithic + package containing all kernel modules. + :term:`KERNEL_SRC` The location of the kernel sources. This variable is set to the value of the :term:`STAGING_KERNEL_DIR` within the :ref:`ref-classes-module`
This variable controls the kernel module spliting. Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> --- documentation/ref-manual/variables.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+)