How to move usr/Makefile call to just before vmlinux_a target ?
Tj <[email protected]> Thu, 30 Jul 2026 09:43:27 +0000
| Newsgroups | gmane.linux.kbuild.devel |
|---|---|
| Message-ID | <[email protected]> |
Note: re-send since original accidentally only got sent to Nicholas.
I've developed a new feature for CONFIG_INITRAMFS_SOURCE implemented in usr=
/gen_initramfs.sh that extends dir_filelist(). The feature enables includin=
g a directory filter of the form:
=C2=A0filter:/path/to/script:/path/to/dir/
where /path/to/script decides the list of files to include from /path/to/di=
r/
My current usage is=C2=A0 to take a dynamic selection of modules from the c=
urrent build and include them in the initramfs.
One of the purposes is to create a self-contained kernel image for automate=
d rapid bisect/pre-build or bisect/build/test iterations that avoid requiri=
ng building an external initrd.img or adding modules to a root file-system =
and can be passed directly to qemu -kernel.
This all works fine. The problem I have struggled with over the last day or=
so is how to move the call to usr/Makefile to just before the vmlinux_a ta=
rget so that the CPIO, compressed, and usr/built-in.a files are built after=
all modules are complete and just prior to all the built-in.a's being asse=
mbled together ?
-- 8-< snip original additional info that Nicholas' response renders mute -=
--
Nicholas pointed me to the November 2025 mailing-list discussions, I was no=
t aware of, on this topic that appear to have a similar aim:
*https://lore.kernel.org/linux-kbuild/28e18785-1336-4fbc-9f2b-69aa6bb06375@=
pengutronix.de/
*https://lore.kernel.org/all/20251125-cpio-modules-pkg-v2-0-aa8277d89682@pe=
ngutronix.de/
Based on Nicholas' response to me regarding the need to fully build vmlinux=
first there is an obvious chicken-and-egg problem. However, I wonder if th=
ere's a sneaky way around it?
Whilst I was doing my (now hundreds) of test cycles I was fooled a few time=
s when the initramfs was correctly populated - making me think the changes =
I'd made were working.
After some thought I realised it was because the incremental build benefite=
d from the module builds of the previous full build and therefore although =
usr/Makefile executes early it can create a valid working initramfs that is=
embedded in the normal flow.
Thinking on this and Nicholas' observation I wonder if the solution here is=
to create a new top-level target something like this:
vmlinux_initramfs: initramfs_modules
initramfs_modules: vmlinux modules
$(Q)$(MAKE) -f $(srctree)/usr/Makefile ... initramfs_add_modules
# rebuild vmlinux to include usr/built-in.a
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux
Adding a new target (or modifying existing) in usr/Makefile
initramfs_add_modules: ...
...
There are other details to take care of for this approach such as ensuring =
modules.dep and any other prerequisites are built.
The second call to Makefile.vmlinux should only need to repeat the AR task,=
I think.
Comments and suggestions welcome - especially if they prevent me exploring =
futile paths!