linux-kernel - Re: [PATCH, v2] kbuild: Improve version string logic

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091014073306.GB22778@elte.hu>
Date:	Wed, 14 Oct 2009 09:33:06 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Frans Pop <elendil@...net.nl>,
	Dirk Hohndel <hohndel@...radead.org>,
	Len Brown <lenb@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH, v2] kbuild: Improve version string logic


* David Rientjes <rientjes@...gle.com> wrote:

> On Wed, 14 Oct 2009, Ingo Molnar wrote:
> 
> > > I don't think you want to do that because it would require the .config 
> > > to be posted on bug reports, for example, to determine the setting of 
> > > CONFIG_LOCALVERSION_AUTO before you can interpret the kernel version.  
> > > In other words, you wouldn't know that "2.6.32-rc4" is actually 200 
> > > commits beyond the actual release unless you also know that the 
> > > .config has CONFIG_LOCALVERSION_AUTO="none".
> > 
> > We've come a full circle ...
> > 
> > That's the current !CONFIG_LOCALVERSION_AUTO status quo ... That was 
> > being asked to be preserved for (unspecified) packaging reasons. So
> > your suggestion is to do away with that behavior altogether?
> > 
> 
> I don't think it's helpful to specify a version as "2.6.32-rc4" when 
> in reality it has 200 commits beyond the release and I like the 
> addition of `+' for !CONFIG_LOCALVERSION_AUTO if we're not at a tagged 
> commit.  That's what my two patches do so the only time you could get 
> a "2.6.32-rc4" version string is for when it's the equivalent of 
> http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.32-rc4.tar.bz2 
> (and you would actually get that regardless of whether you're using 
> CONFIG_LOCALVERSION_AUTO or not).
> 
> There's another possible extension that could be made: we could allow 
> LOCALVERSION= as passed to "make" to override the added `+' since it 
> is used to identify kernel versions by a string anyway; so make 
> LOCALVERSION=-slub_fixes would become v2.6.32-rc4-slub_fixes if 
> CONFIG_LOCALVERSION_AUTO were disabled, regardless of what commit 
> we're at, and v2.6.32-rc4-slub_fixes-00094-g80f5069 if it were 
> enabled.
> 
> Regardless of future improvements, I think my two patches allow the 
> kernel version to more accurately describe what is running.  That is 
> predicated on my belief that "v2.6.32-rc4", though, should never 
> describe _anything_ except the kernel.org v2.6.32-rc4 kernel.

I agree with all that - in fact i started this thread by stating that 
view and suggesting the '+' extension to the short version name.

But there's been packaging related objections from Frans and others, and 
i suspect you'll need to answer/address those instead of further 
detailing the virtues of proper version names (which i still 100% agree 
with).

Btw., i only minimally agree with the packaging objections: there's 
certainly no harm in enabling for folks to still keep things as they 
were for years. But we can definitely change the default and we can make 
it difficult to choose the faulty short-name scheme.

Thanks,

	Ingo
--
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/