[PATCH v2 0/2] Move tool for generating initramfs cpio to scripts/

[PATCH v2 0/2] Move tool for generating initramfs cpio to scripts/

[Nicolas Schier]

initramfs cpio tools had been subject of several recent discussions on
linux-kbuild.  Let's get two minor steps forward by enabling a
top-level target for building gen_init_cpio w/o the need of a valid
kbuild configuration [1] and move the tools for generating the builtin
initramfs from usr/ to scripts/ [2].

Link: https://lore.kernel.org/all/20260220191150.244006-1-safinaskar@gmail.com # [1]
Link: https://lore.kernel.org/all/aSdrCFkUQup3qb-q@derry.ads.avm.de/ # [2]
---
Changes in v2:
  * Build gen_init_cpio only if CONFIG_BLK_DEV_INITRD (Thomas)
  * Keep underscore top-level target name (scripts_gen_init_cpio)
    (Thomas)
  * Link to v1: https://patch.msgid.link/20260309-move-gen_init_cpio-to-scripts-v1-0-0c5059b1ec5b@kernel.org

---
Nicolas Schier (2):
      kbuild: Mark usr_gen_init_cpio as no-dot-config-target
      kbuild: Move gen_init_cpio and gen_initramfs.sh to scripts/

 MAINTAINERS                       | 1 +
 Makefile                          | 9 +++++----
 scripts/.gitignore                | 1 +
 scripts/Makefile                  | 3 +++
 {usr => scripts}/gen_init_cpio.c  | 0
 {usr => scripts}/gen_initramfs.sh | 2 +-
 scripts/remove-stale-files        | 2 ++
 usr/.gitignore                    | 4 +++-
 usr/Makefile                      | 4 +---
 9 files changed, 17 insertions(+), 9 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260225-move-gen_init_cpio-to-scripts-9e89ef99e51a

Best regards,
-- 
Nicolas

Re: [PATCH v2 0/2] Move tool for generating initramfs cpio to scripts/

[Tj]

I've almost finished the feature to add to usr/gen_initramfs.sh::dir_filelist()
parsing of:

filter:/path/to/filter_script.sh:/path/to/directory/

A generic solution that can generate a cpio list dynamically.

My feature's current status is "working well".

I use it to include a sub-set of just-built modules in the initramfs
with some additional ./Makefile top-level magic.

I noticed this proposal to move scripts so want to provide a heads-up.

I described the technique as 'sneaky' in my email of 30th July:

"How to move usr/Makefile call to just before vmlinux_a target ?"

In it I add usr/Makefile.add_modules. It relies on being able to include,
unmodified, usr/Makefile, and use its targets.

Does moving usr/gen_initramfs.sh to scripts/ infer my 'example' script

usr/gen_initramfs_dirlist_filter.sh

should also be prepared to move to scripts/ ? It feels like that would
be moving it from its logical home.

Due to the trial-and-error process whilst developing it, and much additional debug
logging to understand call flows, it is not currently in a state to propose.

My aim is to clean it up by end of this week (8th August) and post an
RFC patch series.

Re: [PATCH v2 0/2] Move tool for generating initramfs cpio to scripts/

[Nicolas Schier]

On Mon, Aug 03, 2026 at 09:15:39PM +0000, Tj wrote:
> I've almost finished the feature to add to usr/gen_initramfs.sh::dir_filelist()
> parsing of:
> 
> filter:/path/to/filter_script.sh:/path/to/directory/
> 
> A generic solution that can generate a cpio list dynamically.
> 
> My feature's current status is "working well".
> 
> I use it to include a sub-set of just-built modules in the initramfs
> with some additional ./Makefile top-level magic.
> 
> I noticed this proposal to move scripts so want to provide a heads-up.
> 
> I described the technique as 'sneaky' in my email of 30th July:
> 
> "How to move usr/Makefile call to just before vmlinux_a target ?"
> 
> In it I add usr/Makefile.add_modules. It relies on being able to include,
> unmodified, usr/Makefile, and use its targets.
> 
> Does moving usr/gen_initramfs.sh to scripts/ infer my 'example' script
> 
> usr/gen_initramfs_dirlist_filter.sh
> 
> should also be prepared to move to scripts/ ? It feels like that would
> be moving it from its logical home.

I think so, but guessing w/o concrete patches is probably not very
reliable.

> Due to the trial-and-error process whilst developing it, and much additional debug
> logging to understand call flows, it is not currently in a state to propose.
> 
> My aim is to clean it up by end of this week (8th August) and post an
> RFC patch series.

Please go ahead.  I will not able to have a in-depth look at it before
mid-August.

-- 
Nicolas