From: Frans Pop <elendil@planet.nl>
To: paulmck@linux.vnet.ibm.com
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
linux-kernel@vger.kernel.org, zippel@linux-m68k.org,
mingo@elte.hu, akpm@linux-foundation.org,
torvalds@linux-foundation.org
Subject: Re: [PATCH RFC] kconfig: place git SHA1 in .config output if in git tree
Date: Wed, 3 Mar 2010 01:42:41 +0100 [thread overview]
Message-ID: <201003030142.43310.elendil@planet.nl> (raw)
In-Reply-To: <20100303000134.GD6786@linux.vnet.ibm.com>
On Wednesday 03 March 2010, Paul E. McKenney wrote:
> > Wouldn't it be more logical to include the line in the dmesg output?
> > My preference would be a separate line below the existing (Linux
> > version) line. That line could only be output if the kernel was built
> > from a VCS. It could then even be repeated in oops output.
>
> My concern with only putting it in the dmesg output is that people do
> not always capture that. The oops output is more often captured, but
> the kernel only has this information if CONFIG_LOCALVERSION_AUTO is set.
Yes, my suggestion is exactly because IMO it should be independent of
CONFIG_LOCALVERSION_AUTO.
I hugely dislike that option because it makes the git version part of the
kernel version and thus affects how the kernel gets installed (names of
files in /boot, name of the directory in /lib/modules, name of the Debian
package created using the deb-pkg target, etc.).
For all those things I want a "clean" kernel version and thus I will never
enable CONFIG_LOCALVERSION_AUTO.
But I do see the value of a reliable and consistent identification of what
exact source a kernel was built from. Including the git version separately
from the kernel version would allow that.
Cheers,
FJP
next prev parent reply other threads:[~2010-03-03 0:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-01 4:22 [PATCH RFC] kconfig: place git SHA1 in .config output if in git tree Paul E. McKenney
2010-03-01 8:34 ` Ingo Molnar
2010-03-01 9:42 ` Frans Pop
2010-03-01 10:10 ` Geert Uytterhoeven
2010-03-01 16:27 ` Paul E. McKenney
2010-03-01 16:53 ` Frans Pop
2010-03-01 18:16 ` Paul E. McKenney
2010-03-01 20:29 ` Frans Pop
2010-03-02 1:16 ` Paul E. McKenney
2010-03-02 15:19 ` Frans Pop
2010-03-03 0:01 ` Paul E. McKenney
2010-03-03 0:42 ` Frans Pop [this message]
2010-03-03 2:19 ` Paul E. McKenney
2010-03-01 16:22 ` Linus Torvalds
2010-03-01 16:48 ` Paul E. McKenney
2010-03-01 20:46 ` James Cloos
2010-03-02 1:20 ` Paul E. McKenney
2010-03-02 1:53 ` James Cloos
2010-03-02 5:21 ` Paul E. McKenney
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=201003030142.43310.elendil@planet.nl \
--to=elendil@planet.nl \
--cc=akpm@linux-foundation.org \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=zippel@linux-m68k.org \
/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.