mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Calvin Owens <calvin@wbinvd.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	Masahiro Yamada <masahiroy@kernel.org>,
	Nicolas Schier <nicolas@fjasle.eu>,
	linux-kbuild@vger.kernel.org
Subject: Re: [PATCH] kbuild: buildtar: Add arm support
Date: Wed, 10 Apr 2024 15:56:11 -0700	[thread overview]
Message-ID: <ZhcZCwMmANQS39s2@mozart.vkv.me> (raw)
In-Reply-To: <20240410170450.GA1828262@dev-arch.thelio-3990X>

On Wednesday 04/10 at 10:04 -0700, Nathan Chancellor wrote:
> Hi Calvin,
> 
> Thanks for the patch!
> 
> On Tue, Apr 09, 2024 at 10:17:07AM -0700, Calvin Owens wrote:
> > Make 'make tar-pkg' and friends work on 32-bit arm.
> > 
> > Signed-off-by: Calvin Owens <calvin@wbinvd.org>
> 
> Technically speaking, buildtar works for 32-bit ARM right now (I use it
> almost daily), this is just explicitly adding it to the supported list
> to avoid the warning and putting zImage at vmlinuz-${KERNELRELEASE}
> instead of vmlinux-kbuild-${KERNELRELEASE}, right?

Exactly. I assumed (maybe incorrectly?) the vmlinux-kbuild-* name was
generic "unimplemented" filler that was meant to be replaced. It seems
like the vmlinuz-* naming has sort of become a de facto standard in the
tar-pkgs.

The context for me is a pile of scripts that build kernels and boot them
with QEMU on arm and arm64: it's convenient if the tar-pkg structure is
consistent between the two (and across other architectures too).

> That said, looks mostly fine to me, one comment below.
> 
> Before:
> 
>   './System.map' -> 'tar-install/boot/System.map-6.9.0-rc3-00023-g2c71fdf02a95'
>   '.config' -> 'tar-install/boot/config-6.9.0-rc3-00023-g2c71fdf02a95'
>   './vmlinux' -> 'tar-install/boot/vmlinux-6.9.0-rc3-00023-g2c71fdf02a95'
>   'arch/arm/boot/zImage' -> 'tar-install/boot/vmlinux-kbuild-6.9.0-rc3-00023-g2c71fdf02a95'
> 
>   ** ** **  WARNING  ** ** **
> 
>   Your architecture did not define any architecture-dependent files
>   to be placed into the tarball. Please add those to scripts/package/buildtar ...
> 
> After:
> 
>   './System.map' -> 'tar-install/boot/System.map-6.9.0-rc3-00023-g2c71fdf02a95-dirty'
>   '.config' -> 'tar-install/boot/config-6.9.0-rc3-00023-g2c71fdf02a95-dirty'
>   './vmlinux' -> 'tar-install/boot/vmlinux-6.9.0-rc3-00023-g2c71fdf02a95-dirty'
>   './arch/arm/boot/zImage' -> 'tar-install/boot/vmlinuz-6.9.0-rc3-00023-g2c71fdf02a95-dirty'
> 
> and the location of zImage is the only thing that changes as expected.
> 
> > ---
> >  scripts/package/buildtar | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/scripts/package/buildtar b/scripts/package/buildtar
> > index 72c91a1b832f..0939f9eabbf2 100755
> > --- a/scripts/package/buildtar
> > +++ b/scripts/package/buildtar
> > @@ -101,6 +101,9 @@ case "${ARCH}" in
> >  			fi
> >  		done
> >  		;;
> > +	arm)
> > +		[ -f "${objtree}/arch/arm/boot/zImage" ] && cp -v -- "${objtree}/arch/arm/boot/zImage" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
> 
> While it probably does not matter too much, it would be more proper to
> make this
> 
>   [ -f "${KBUILD_IMAGE}" ] && cp -v -- "${KBUILD_IMAGE}" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
> 
> as the current line does not work with CONFIG_XIP_KERNEL=y, since zImage
> does not exist (KBUILD_IMAGE is arch/arm/boot/xipImage with this
> configuration)
> 
>   $ ls arch/arm/boot
>   compressed  dts  xipImage
> 
> resulting in buildtar failing because
> 
>   [ -f "${objtree}/arch/arm/boot/zImage" ]
> 
> fails and is the last statement that runs in the script (and the tar
> package is not really complete in this configuration anyways).
> 
> Prior to this change, the correct image would get placed into the
> tarball.
> 
>   'arch/arm/boot/xipImage' -> 'tar-install/boot/vmlinux-kbuild-6.9.0-rc3-00023-g2c71fdf02a95'

Makes sense, thanks. Although...

> > +		;;
> >  	*)
> >  		[ -f "${KBUILD_IMAGE}" ] && cp -v -- "${KBUILD_IMAGE}" "${tmpdir}/boot/vmlinux-kbuild-${KERNELRELEASE}"
> >  		echo "" >&2

...it ends up looking almost identical to the default case. Does it make
make more sense to change the destination in the default case and remove
the warning? I'm not sure if anything might rely on the current
behavior, it goes all the way back (git sha 6d983feab809).

Thanks,
Calvin

> > -- 
> > 2.39.2
> > 
> 
> Cheers,
> Nathan

  reply	other threads:[~2024-04-10 22:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-09 17:17 Calvin Owens
2024-04-10 17:04 ` Nathan Chancellor
2024-04-10 22:56   ` Calvin Owens [this message]
2024-04-12 19:23     ` Calvin Owens
2024-04-12 21:47       ` Nathan Chancellor
2024-04-12 19:26     ` [PATCH v2] kbuild: buildtar: Add explicit 32-bit " Calvin Owens
2024-04-12 21:48       ` Nathan Chancellor
2024-06-21  2:25       ` [RESEND PATCH " Calvin Owens
2024-06-21 14:55         ` Nathan Chancellor
2024-06-22  2:55           ` Calvin Owens

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=ZhcZCwMmANQS39s2@mozart.vkv.me \
    --to=calvin@wbinvd.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=nathan@kernel.org \
    --cc=nicolas@fjasle.eu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®