All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
	Nicolas Schier <nicolas@fjasle.eu>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] scripts/setlocalversion: also consider annotated tags of the form vx.y.z-${file_localversion}
Date: Fri, 8 Sep 2023 11:19:50 -0700	[thread overview]
Message-ID: <ZPtlxmdIJXOe0sEy@google.com> (raw)
In-Reply-To: <20230804120536.2339722-1-linux@rasmusvillemoes.dk>

On Fri, Aug 04, 2023, Rasmus Villemoes wrote:
> Commit 6ab7e1f95e96 ("setlocalversion: use only the correct release
> tag for git-describe") was absolutely correct to limit which annotated
> tags would be used to compute the -01234-gabcdef suffix. Otherwise, if
> some random annotated tag exists closer to HEAD than the vX.Y.Z one,
> the commit count would be too low.
> 
> However, since the version string always includes the
> ${file_localversion} part, now the problem is that the count can be
> too high. For example, building an 6.4.6-rt8 kernel with a few patches
> on top, I currently get
> 
> $ make -s kernelrelease
> 6.4.6-rt8-00128-gd78b7f406397
> 
> But those 128 commits include the 100 commits that are in
> v6.4.6..v6.4.6-rt8, so this is somewhat misleading.
> 
> Amend the logic so that, in addition to the linux-next consideration,
> the script also looks for a tag corresponding to the 6.4.6-rt8 part of
> what will become the `uname -r` string. With this patch (so 29 patches
> on top of v6.4.6-rt8), one instead gets
> 
> $ make -s kernelrelease
> 6.4.6-rt8-00029-gd533209291a2
> 
> While there, note that the line
> 
>   git describe --exact-match --match=$tag $tag 2>/dev/null
> 
> obviously asks if $tag is an annotated tag, but it does not actually
> tell if the commit pointed to has any relation to HEAD. So remove both
> uses of --exact-match, and instead just ask if the description
> generated is identical to the tag we provided. Since we then already
> have the result of
> 
>   git describe --match=$tag
> 
> we also end up reducing the number of times we invoke "git describe".

Dropping "--exact-match" is resulting in unnacceptable latencies for me.  I don't
understand what this is trying to do well enough to make a suggestion, but something
has to change.

E.g. on my build box, a single `git describe --match=v6.5` takes ~8.5 seconds,
whereas a complete from-scratch kernel build takes <30 seconds, and an incremental
build takes <2 seconds.  When build testing to-be-applied changes, I compile each
commit ~15 times (different x86 configs plus one for each other KVM architecture),
which makes the ~8.5 second delay beyond painful.

And for actual testing, I can do an incremental build and boot into a VM in under
20 seconds, a multi-second delay is extremely painful there as well.

  parent reply	other threads:[~2023-09-08 18:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-04 12:05 [PATCH v2] scripts/setlocalversion: also consider annotated tags of the form vx.y.z-${file_localversion} Rasmus Villemoes
2023-08-05 15:26 ` Masahiro Yamada
2023-09-08 18:19 ` Sean Christopherson [this message]
2023-09-08 22:34   ` Rasmus Villemoes
2023-09-08 23:21     ` Sean Christopherson

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=ZPtlxmdIJXOe0sEy@google.com \
    --to=seanjc@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=masahiroy@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 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.