From: Afzal Mohammed <afzal.mohd.ma@gmail.com>
To: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Afzal Mohammed <afzal.mohd.ma@gmail.com>,
Michal Marek <mmarek@suse.cz>,
Christophe Leroy <christophe.leroy@c-s.fr>,
Christian Kujau <lists@nerdbynature.de>
Subject: [PATCH RFC] kbuild: prevent git private tag altering kernelrelease
Date: Sat, 14 Sep 2013 03:19:58 +0530 [thread overview]
Message-ID: <1379109004-2411-1-git-send-email-afzal.mohd.ma@gmail.com> (raw)
If a private tag is created after the most recent kernelversion tag, a
commit after this private tag would feed kernelrelease with commits
after private tag and kernelversion tag. This may confuse user relying
on kernelrelease (mostly a developer while debugging), mainly if HEAD
has a private tag and otherwise w.r.t git distance from kernelversion
tag.
Suppose the Kernel is 18 commits after v3.11-rc1, kernelrelease would be
something like '3.11.0-rc1-00018-gdeadbeef'.
And if an annotated(or signed) tag is created at HEAD, kernelrelease
would become 3.11.0-rc1, which makes one feel that source corresponds to
v3.11-rc1 tag.
Instead if such a tag is created at say HEAD~, kernelrelease would be
v3.11.0-rc1-00001-gdeadbeef, misleading the observer w.r.t git distance
from nearest kernelversion tag.
Here an attempt is made to prevent private tag from altering
kernelrelease.
Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
---
Hi,
This seems to work on different scenarios that could be readily thought
of. I am shaky about this change, but acheives the purpose.
Regards
Afzal
Makefile | 4 ++--
scripts/setlocalversion | 12 ++++++++----
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index e73f758..923e492 100644
--- a/Makefile
+++ b/Makefile
@@ -795,7 +795,7 @@ $(vmlinux-dirs): prepare scripts
$(Q)$(MAKE) $(build)=$@
define filechk_kernel.release
- echo "$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree))"
+ echo "$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree) $(KERNELVERSION))" > $@
endef
# Store (new) KERNELRELEASE string in include/config/kernel.release
@@ -1330,7 +1330,7 @@ checkstack:
$(PERL) $(src)/scripts/checkstack.pl $(CHECKSTACK_ARCH)
kernelrelease:
- @echo "$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree))"
+ @echo "$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree) $(KERNELVERSION))"
kernelversion:
@echo $(KERNELVERSION)
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index d105a44..2c4552c 100755
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -10,7 +10,7 @@
#
usage() {
- echo "Usage: $0 [--save-scmversion] [srctree]" >&2
+ echo "Usage: $0 [--save-scmversion] [srctree] [kernelversion]" >&2
exit 1
}
@@ -24,7 +24,11 @@ if test $# -gt 0; then
srctree=$1
shift
fi
-if test $# -gt 0 -o ! -d "$srctree"; then
+if test $# -gt 0; then
+ kernelversion=`echo $1 | sed -e 's/[.]0//' -e 's/^/v/'`
+ shift
+fi
+if test $# -gt 0 -o ! -d "$srctree" -o -z "$kernelversion"; then
usage
fi
@@ -47,7 +51,7 @@ scm_version()
# If we are at a tagged commit (like "v2.6.30-rc6"), we ignore
# it, because this version is defined in the top level Makefile.
- if [ -z "`git describe --exact-match 2>/dev/null`" ]; then
+ if [ -z "`git describe --exact-match --match $kernelversion 2>/dev/null`" ]; then
# If only the short version is requested, don't bother
# running further git commands
@@ -57,7 +61,7 @@ scm_version()
fi
# If we are past a tagged commit (like
# "v2.6.30-rc5-302-g72357d5"), we pretty print it.
- if atag="`git describe 2>/dev/null`"; then
+ if atag="`git describe --match $kernelversion 2>/dev/null`"; then
echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'
# If we don't have a tag at all we print -g{commitish}.
--
1.8.2.135.g7b592fa
next reply other threads:[~2013-09-13 21:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-13 21:49 Afzal Mohammed [this message]
2013-10-23 13:21 ` [PATCH RFC] kbuild: prevent git private tag altering kernelrelease Michal Marek
2013-10-27 19:39 ` Afzal Mohammed
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=1379109004-2411-1-git-send-email-afzal.mohd.ma@gmail.com \
--to=afzal.mohd.ma@gmail.com \
--cc=christophe.leroy@c-s.fr \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lists@nerdbynature.de \
--cc=mmarek@suse.cz \
/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