From: Nicolas Schier <nsc@kernel.org>
To: Janne Grunau <j@jannau.net>
Cc: "Nathan Chancellor" <nathan@kernel.org>,
"Ahmad Fatoum" <a.fatoum@pengutronix.de>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Simon Glass" <sjg@chromium.org>,
"Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kbuild: modules-cpio-pkg: Respect INSTALL_MOD_PATH
Date: Wed, 25 Mar 2026 16:25:29 +0100 [thread overview]
Message-ID: <acP-ad4e-YQYqIsh@levanger> (raw)
In-Reply-To: <20260325144826.GA2137845@robin.jannau.net>
On Wed, Mar 25, 2026 at 03:48:26PM +0100, Janne Grunau wrote:
> On Sat, Mar 21, 2026 at 04:18:46PM +0100, Nicolas Schier wrote:
> > On Fri, Mar 20, 2026 at 03:30:32PM +0100, Janne Grunau wrote:
> > > The modules-cpio-pkg target added in commit 2a9c8c0b59d3 ("kbuild: add
> > > target to build a cpio containing modules") is incompatible with
> > > initramfs with merged /lib and /usr/lib directories [1]. "/lib" cannot
> > > be a link and directory at the same time.
> > > Respect a non-empty INSTALL_MOD_PATH in the modules-cpio-pkg target so
> > > that `make INSTALL_MOD_PATH=/usr modules-cpio-pkg` results in the same
> > > module install location as `make INSTALL_MOD_PATH=/usr modules_install`.
> > >
> > > Tested with Fedora distribution initramfs produced by dracut.
> > >
> > > Link: https://systemd.io/THE_CASE_FOR_THE_USR_MERGE/ [1]
> > > Signed-off-by: Janne Grunau <j@jannau.net>
> > > ---
> > > Hej,
> > >
> > > this patch allows to produce modules-cpio initramfs which are compatible
> > > with initramfs with merged /lib and /usr/lib (/lib as symlink to
> > > /usr/lib). I expect initramfs of distributions with merged /usr to have
> > > a merged /usr as well. This is at least true for Fedora initramfs built
> > > with dracut.
> > >
> > > I'm not sure whether the trickery to avoid repeated '/' is justified. It
> > > is necessary to add a slash between "$@" and a non empty
> > > $(INSTALL_MOD_PATH) to avoid make failures due to non existing
> > > .tmp_modules_cpio when INSTALL_MOD_PATH without leading slash is used.
> > > modules-cpio-pkg`.
> > >
> > > Better or shorter ways to document this not completely obvious behavior
> > > would be appreciated.
> > >
> > > Janne
> > > ---
> > > scripts/Makefile.package | 6 ++++--
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/scripts/Makefile.package b/scripts/Makefile.package
> > > index 0ec946f9b905f74f8698d8d6967d22f5b76f64e0..ab18cf81622ae319380528c401f9aeb6d32070c6 100644
> > > --- a/scripts/Makefile.package
> > > +++ b/scripts/Makefile.package
> > > @@ -195,7 +195,9 @@ tar%-pkg: linux-$(KERNELRELEASE)-$(ARCH).tar.% FORCE
> > > .tmp_modules_cpio: FORCE
> > > $(Q)$(MAKE) -f $(srctree)/Makefile
> > > $(Q)rm -rf $@
> > > - $(Q)$(MAKE) -f $(srctree)/Makefile INSTALL_MOD_PATH=$@ modules_install
> > > + $(Q)$(MAKE) -f $(srctree)/Makefile \
> > > + INSTALL_MOD_PATH=$@$(if $(INSTALL_MOD_PATH),/$(INSTALL_MOD_PATH:/%=%)) \
> > > + modules_install
> >
> > Thanks for the patch along with its detailed description!
> >
> > For completeness: I'd rather use $(addprefix):
> >
> > INSTALL_MOD_PATH=$@$(addprefix /,$(INSTALL_MOD_PATH:/%=%))
> >
> > but as POSIX states:
> >
> > | Multiple successive <slash> characters are considered to be the same
> > | as one <slash>, except it is implementation-defined whether the case
> > | of exactly two leading <slash> characters is treated specially.
> > https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/
>
> argh, I did read this but confused myself by the second part to think it
> was only for leading slashes.
:) you are by far not the only one who gets confused by that.
--
Nicolas
prev parent reply other threads:[~2026-03-25 15:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 14:30 [PATCH] kbuild: modules-cpio-pkg: Respect INSTALL_MOD_PATH Janne Grunau
2026-03-21 15:02 ` Simon Glass
2026-03-21 15:18 ` Nicolas Schier
2026-03-25 14:48 ` Janne Grunau
2026-03-25 15:25 ` Nicolas Schier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acP-ad4e-YQYqIsh@levanger \
--to=nsc@kernel.org \
--cc=a.fatoum@pengutronix.de \
--cc=j@jannau.net \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=sjg@chromium.org \
--cc=thomas.weissschuh@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.