Re: [PATCH v6 6/8] kbuild: Allow adding modules into the FIT ramdisk
From: Thomas Weißschuh <hidden>
Date: 2025-12-02 10:31:55
Also in:
linux-kbuild, lkml
On Wed, Nov 26, 2025 at 12:26:49PM +0100, Ahmad Fatoum wrote:
On 11/26/25 8:16 AM, Thomas Weißschuh wrote:quoted
On Tue, Nov 25, 2025 at 02:58:12PM -0700, Simon Glass wrote:quoted
On Thu, 20 Nov 2025 at 00:49, Thomas Weißschuh [off-list ref] wrote:quoted
On Wed, Nov 19, 2025 at 11:13:27AM -0700, Simon Glass wrote:(...)quoted
quoted
quoted
quiet_cmd_fit = FIT $@ cmd_fit = $(MAKE_FIT) -o $@ --arch $(UIMAGE_ARCH) --os linux \ - --name '$(UIMAGE_NAME)' \ + --name '$(UIMAGE_NAME)' $(MAKE_FIT_FLAGS) \Remnant of a previous revision?The flags are there to allow extra options to be passed if needed.Are they necessary for the module functionality added here? If not I'd put them into a dedicated commit.quoted
quoted
quoted
$(if $(findstring 1,$(KBUILD_VERBOSE)),-v) \ $(if $(FIT_DECOMPOSE_DTBS),--decompose-dtbs) \ + $(if $(FIT_MODULES),--modules @$(objtree)/modules.order) \I am wondering how module dependencies work without the depmod invocation and modules.dep file.We have a mechanism to place a pre-build initrd with the filesystem, etc. into the FIT. But for this particular feature (suggested by Ahmad Fatoum) we are just providing the raw modules. Presumably another initrd would be needed to provide the startup files?modules.dep is more than optional and generic startup files but an integral part of a module tree. Without it, any module depending on another module's symbols will fail to load. Also the modules will be unsigned, potentially making them unloadable.I'll use the occasion to elaborate a bit on why I thought adding modules is a good idea. - You have a system boot from FIT and maybe even a r/o rootfs - You want to boot a different kernel without any userspace changes, e.g. to bisect - Fortunately, you have a build target that generates you a FIT with kernel, enabled device trees and all modules (including deps and such) - In the bootloader[1], you specify that a CPIO with a minimal init[2] that bindmounts /lib/modules in the initramfs over the rootfs modules before pivot_root and that's it, you are running your new kernel with the old rootfs unchanged. I believe this would be really handy, which is why I suggested it.
The idea sounds good.
quoted
Ahmad's patch does produce a complete and fully functional module tree by means of 'make headers_install'.I originally thought that we could generate the CPIO normally as part of the kernel build and then we can readily depend on it in the rule that invokes make_fit.py.
That works, but it is not what the patch under discussion does, or did.
If this proves to be too cumbersome, I think it's already an improvement if the user can manually run make modules-cpio-pkg and then make image.fit with the initrd specified. A single target would be neater of course, but I didn't intend for this to stall the series.
The single target idea would require 'modules-cpio-pkg' to not be a PHONY target anymore but to properly track dependencies. Otherwise the CPIO and FIT image will be rebuilt even if no sources change. Proper dependencies are always better than PHONY targets, but it will be a bit of additional work.
It can always follow later.
Yep. But for the patch as it is proposed I am still wondering how it will work without modules.dep and friends. (...)