Re: [PATCH 2/2] kbuild: Move gen_init_cpio and gen_initramfs.sh to scripts/

[Thomas Weißschuh]

On Tue, Mar 10, 2026 at 08:14:36AM +0100, Nicolas Schier wrote:
> On Mon, Mar 09, 2026 at 02:41:53PM +0100, Thomas Weißschuh wrote:
> > On Mon, Mar 09, 2026 at 08:56:30AM +0100, Nicolas Schier wrote:

(...)

> > > @@ -1437,9 +1437,9 @@ ifdef CONFIG_HEADERS_INSTALL
> > >  prepare: headers
> > >  endif
> > >  
> > > -PHONY += usr_gen_init_cpio
> > > -usr_gen_init_cpio: scripts_basic
> > > -	$(Q)$(MAKE) $(build)=usr usr/gen_init_cpio
> > > +PHONY += scripts/gen_init_cpio
> > > +scripts/gen_init_cpio: scripts_basic
> > > +	$(Q)$(MAKE) $(build)=scripts scripts/gen_init_cpio
> > 
> > The other proxy targets for scripts/ use the 'scripts_' prefix.
> > Why is this one different?
> 
> Good question; I was ambiguous about that, but I chose 'scripts/' in
> favor of 'scripts_' as
> 
> 1. The $(obj)/initramfs_data.cpio target in usr/Makefile has to depend
>    on 'scripts/gen_init_cpio' regardless of how the top-level target is
>    called, as the sub-make cannot depend on a phony top-level rule.
>    If possible, I like to have the same name for dependencies as for the
>    rule that generates them.
> 
> 2. I cannot see the reason for the 'scripts_' prefix currently used in
>    top-level Makefile for real targets building a single output file.
>    It seems to me that commit bdd7714b6f4c ("kbuild: build all
>    prerequisites of headers_install simultaneously") introduced the
>    'scripts_' prefix due to the historic origin 'scripts_basic'; which
>    itself came with commit 952a0ae394f4 ("[PATCH] Fix early parallel
>    make failures", v2.6.5) [1].  I _guess_ the 'scripts_' prefix was
>    meant to clearly make a difference from the previous 'scripts'
>    target, and the name makes clear that it is a phony target building
>    several things.
> 
> Masahiro, if you are around I'd appreciate a comment from you.
> 
> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=952a0ae394f4
> 
> Thomas, does the reasoning make sense to you?  Or do you expect troubles
> due to the 'scripts/' prefix?

Sounds reasonable. Personally I would still prefer consistency, but that is
subjective of course.

In any case:
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxxxx>


Thomas