lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 2 Mar 2010 18:19:01 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Frans Pop <elendil@...net.nl>
Cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	linux-kernel@...r.kernel.org, zippel@...ux-m68k.org, mingo@...e.hu,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH RFC] kconfig: place git SHA1 in .config output if in
	git tree

On Wed, Mar 03, 2010 at 01:42:41AM +0100, Frans Pop wrote:
> 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.

That does sound a bit painful...

> 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.

Fortunately, scripts/setlocalversion seems to run quite a bit faster the
second time I run it, probably due to various caches having been warmed
up the first time.  Because doing all of this straightforwardly means up
to three invocations in a given kernel build.  ;-)

							Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ