Re: [poky] [PATCH v3] genericarm64 core-image-initramfs-boot: remove some kernel drivers
Richard Purdie <[email protected]> Fri, 17 Apr 2026 13:06:11 +0100
| Newsgroups | org.yoctoproject.lists.poky |
|---|---|
| Message-ID | <c39bc15ec611160c073b3c1338244d1ee6a99f5a.camel@linuxfoundation.org> |
On Fri, 2026-04-17 at 12:25 +0300, Mikko Rapeli wrote: > Hi, >=20 > On Fri, Apr 17, 2026 at 10:10:07AM +0100, Richard Purdie wrote: > > On Mon, 2026-04-13 at 10:27 +0300, Mikko Rapeli via lists.yoctoproject.= org wrote: > > > genericarm64 supports a lot of HW and thus large collection of kernel > > > drivers are enabled and installed to images by default. > > > Subset of the kernel drivers are needed in initramfs to mount rootfs > > > from local mass storage devices. This increases initramfs size a lot > > > and with new kernel config updates even more. Thus remove kernel > > > drivers from initramfs image which are not needed for mounting > > > rootfs from local mass storage devices. GPU, Bluetooth, NFC, > > > sound, networking etc support is not needed in the initramfs. > > >=20 > > > According to buildhistory core-image-initramfs-boot size is reduced > > > from 118 to 83 Mb. > > >=20 > > > Signed-off-by: Mikko Rapeli <[email protected]> > > > --- > > > =C2=A0.../images/core-image-initramfs-boot.bbappend | 28 ++++++++++++= +++++++ > > > =C2=A01 file changed, 28 insertions(+) > > > =C2=A0create mode 100644 meta-yocto-bsp/recipes-core/images/core-imag= e-initramfs-boot.bbappend > > >=20 > > > v3: added PATHS_TO_REMOVE variable so that it can be customized > > > =C2=A0=C2=A0=C2=A0 as suggested by Jose Quaresma <quaresma.jose@gmail= .com> > > >=20 > > > v2: https://lists.yoctoproject.org/g/poky/message/13894 > > >=20 > > > diff --git a/meta-yocto-bsp/recipes-core/images/core-image-initramfs-= boot.bbappend b/meta-yocto-bsp/recipes-core/images/core-image-initramfs-boo= t.bbappend > > > new file mode 100644 > > > index 000000000000..2298c2f94740 > > > --- /dev/null > > > +++ b/meta-yocto-bsp/recipes-core/images/core-image-initramfs-boot.bb= append > > > @@ -0,0 +1,28 @@ > > > +POSTFUNCS =3D "" > > > +POSTFUNCS:genericarm64 =3D "reduce_initrd_size" > > > + > > > +PATHS_TO_REMOVE =3D "" > > > +# these kernel modules are not needed for rootfs mount from local ma= ss storage > > > +# and can be loaded from main rootfs by udev > > > +PATHS_TO_REMOVE:genericarm64 =3D "\ > > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/driv= ers/bluetooth \ > > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/driv= ers/gpu \ > > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/driv= ers/media \ > > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/driv= ers/net \ > > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/driv= ers/nfc \ > > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/driv= ers/usb/gadget \ > > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/fs/f= use \ > > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/net/= bluetooth \ > > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/net/= bridge \ > > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/net/= netfilter \ > > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/net/= nfc \ > > > +=C2=A0=C2=A0=C2=A0 ${WORKDIR}/rootfs/${libdir}/modules/*/kernel/soun= d \ > > > +" > > > + > > > +do_rootfs[postfuncs] +=3D "${POSTFUNCS}" > > > +reduce_initrd_size () { > > > +=C2=A0=C2=A0=C2=A0 if [ -n "${PATHS_TO_REMOVE}" ]; then > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rm -rf ${PATHS_TO_REMOVE} > > > +=C2=A0=C2=A0=C2=A0 fi > > > +} > > > + > >=20 > > This is a tough one. There are some simple things like "POSTFUNCS" > > being a bit generic as a name. I also worry a little this may trip up > > yocto-check-layer with the added variable POSTFUNCS, even if it is > > empty. I think if we're creating this as API, listing the directories: > >=20 > > =C2=A0=C2=A0=C2=A0 drivers/bluetooth \ > > =C2=A0=C2=A0=C2=A0 drivers/gpu \ > > =C2=A0=C2=A0=C2=A0 drivers/media \ > > =C2=A0=C2=A0=C2=A0 drivers/net \ > > =C2=A0=C2=A0=C2=A0 drivers/nfc \ > > =C2=A0=C2=A0=C2=A0 drivers/usb/gadget \ > > =C2=A0=C2=A0=C2=A0 fs/fuse \ > > =C2=A0=C2=A0=C2=A0 net/bluetooth \ > > =C2=A0=C2=A0=C2=A0 net/bridge \ > > =C2=A0=C2=A0=C2=A0 net/netfilter \ > > =C2=A0=C2=A0=C2=A0 net/nfc \ > > =C2=A0=C2=A0=C2=A0 sound \ > >=20 > > and then adding the prefix would probably be cleaner too. Those are all > > easier tweaks. > >=20 > > The bigger challenge is "generic" kernel adding all this. Ideally you > > wouldn't install these things to the initramfs in the first place, then > > you wouldn't need to delete them. I'm not sure how you could > > detect/filter and install only the subset of modules you want, or how > > that list of modules would be maintained/updated. >=20 > kernel-modules correctly get installed to all images through MACHINE_EXTR= A_RDEPENDS. > This is flexible to drivers being built-in or modules. IMO initramfs > image should not be explicitly tied to the exact kernel config and thus > should not depend on the exact set of kernel module packages. A slightly = more abstract > interface between kernel and initramfs image is needed, and "kernel-modul= es" > decent at that. This works well for the real rootfs but is not optimal fo= r > initramfs. >=20 > > A different package to "kernel-modules" could be one idea, how you > > construct that, again, I'm less sure. The above filter list could be > > used to iterate the modules and filter by path I guess? >=20 > I had a patchset for this but ran into issues with it. >=20 > https://lists.openembedded.org/g/openembedded-core/topic/112087526#msg214= 354 >=20 > I don't see how that can move forward though. The problems there didn't seem unsolvable but I don't remember the full details. I think we should revisit that in 6.1. > > Now we've merged the firmware update, the builds are breaking but some > > of these kinds of changes are probably too late for the release/LTS. > >=20 > > Perhaps we just have to increase the size of the initramfs for now :( >=20 > Sigh, alright then. We're too close to release to start doing other things unfortunately. Cheers, Richard