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]
---
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                  | 2 ++
 {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, 16 insertions(+), 9 deletions(-)
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260225-move-gen_init_cpio-to-scripts-9e89ef99e51a

Best regards,
--  
Nicolas

I like this patchset.

Rob (CC'd), does this solve your problem?

Also, in [1] I said:
> command
> "make usr/gen_init_cpio" doesn't work in clean kernel tree even if
> config exists (I checked this)

Now I tested this again, and I see that "make usr/gen_init_cpio" indeed
doesn't work in current mainline in that scenario, but
"cd usr; make gen_init_cpio" works (how I supposed to know this?).
So, problems in [1] are not as big as I thought. You don't need to build
whole kernel two times in that scenario. But still I like this your
new patchset.

Also, I think that top-level "usr" directory exists as a placeholder for
klibc-init project (this is merely my hypothesis, I don't know for sure).
I. e. it was supposed to contain source for userspace init program, which
was supposed to be put into default initramfs.

But klibc-init project, unfortunately, seems to fail. So, I think we should
remove whole top level "usr" directory and move its contents to other places.

[1] https://lore.kernel.org/all/20260220191150.244006-1-safinaskar@gmail.com



-- 
Askar Safin

On March 9, 2026 6:54:16 PM PDT, Askar Safin <safinaskar@gmail.com> wrote:
>I like this patchset.
>
>Rob (CC'd), does this solve your problem?
>
>Also, in [1] I said:
>> command
>> "make usr/gen_init_cpio" doesn't work in clean kernel tree even if
>> config exists (I checked this)
>
>Now I tested this again, and I see that "make usr/gen_init_cpio" indeed
>doesn't work in current mainline in that scenario, but
>"cd usr; make gen_init_cpio" works (how I supposed to know this?).
>So, problems in [1] are not as big as I thought. You don't need to build
>whole kernel two times in that scenario. But still I like this your
>new patchset.
>
>Also, I think that top-level "usr" directory exists as a placeholder for
>klibc-init project (this is merely my hypothesis, I don't know for sure).
>I. e. it was supposed to contain source for userspace init program, which
>was supposed to be put into default initramfs.
>
>But klibc-init project, unfortunately, seems to fail. So, I think we should
>remove whole top level "usr" directory and move its contents to other places.
>
>[1] https://lore.kernel.org/all/20260220191150.244006-1-safinaskar@gmail.com
>
>
>

Well, it worked, but got vetoed. It is still maintained out of tree.