On Fri, Jul 5, 2024 at 2:35 PM Jörg Sommer via lists.openembedded.org <[email protected]> wrote: > > Bruce Ashfield via lists.openembedded.org schrieb am Fr 05. Jul, 10:08 (GMT): > > On Fri, Jul 5, 2024 at 9:19 AM Jörg Sommer via lists.openembedded.org > > <[email protected]> wrote: > > > > > > From: Jörg Sommer <[email protected]> > > > > > > The current do_package does not strip the kernel modules, if they are > > > signed. Hence, the files in a release image stay very big and the debug > > > information are not split into the kernel-dbg package. > > > > > > The idea of this change is to suppress the signing of the modules on > > > `modules_install` and run `modules_sign` after the debug information was > > > striped. > > > > > > Signed-off-by: Jörg Sommer <[email protected]> > > > --- > > > meta/classes-recipe/kernel.bbclass | 13 ++++++++++++- > > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > > > > > > Another idea would be to move the code to split the debug info in > > > package.bbclass to a > > > stand-alone tool and inject this in the kernel's modules_install. > > > > > > > > > diff --git a/meta/classes-recipe/kernel.bbclass > > > b/meta/classes-recipe/kernel.bbclass > > > index 89badd90f1..96e40be085 100644 > > > --- a/meta/classes-recipe/kernel.bbclass > > > +++ b/meta/classes-recipe/kernel.bbclass > > > @@ -461,7 +461,8 @@ kernel_do_install() { > > > # > > > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE > > > if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then > > > - oe_runmake DEPMOD=echo > > > MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION} > > > INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install > > > + # don't sign now, it's down after extraction of debug > > > information > > > + oe_runmake CONFIG_MODULE_SIG_ALL=n DEPMOD=echo > > > MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION} > > > INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install > > > > This isn't a good idea, since it both hardcodes the option name, and > > it doesn't allow any method of overriding the setting. > > The option name is also hardcoded in the kernel Makefile and drives this > feature. I would threat it the same as DEPMOD and MODLIB.
Sure, but that's actually specific to a single kernel and kernel version, and isn't spread from the kernel source to the meta-data coupling the two. And I can easily configure that in, or out of, my kernel. I'd absolutely not treat it the same as those two tools. > > > > +PACKAGEBUILDPKGD += "sign_kernel_modules" > > > But even if those other variables are used, this seems to force the extra > > signing step, which I can say for certain that not everyone wants. > > What would be the other option? Having an anonymous python function to check > the .config if signing and debug information are enabled and configure the > process accordingly? > You definitely do NOT want to grep the .config unless absolutely necessary. That's fundamentally the same binding as putting the option directly in the command environment. I'd make it optional via a distro feature that enables signing (or maybe there already is one for that ? I don't sign modules, so I'm not familiar with what goes on in that area). I don't have a specific problem with the implementation, I'm a kernel and containers maintainer .. not a packaging expert. My issue is that it didn't look like there was a way to disable the extra processing. > As I said, the other way would be to create a stand-alone tool to split the > debug information and feed this as STRIP into modules_install. But this > would alter the process too, because the stripping happens during > do_install. As long as it was optional, I wouldn't be adamant one way or the other. But if it was passed into STRIP via a variable definition, someone could set STRIP to whatever value they wanted and avoid the extra processing or signing. Bruce > > Jörg > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#201615): https://lists.openembedded.org/g/openembedded-core/message/201615 Mute This Topic: https://lists.openembedded.org/mt/107053401/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
