linux-kernel - Re: Linux 2.6.29

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.0903270852070.3994@localhost.localdomain>
Date:	Fri, 27 Mar 2009 09:02:08 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Mike Galbraith <efault@....de>
cc:	Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com>,
	Hans-Peter Jansen <hpj@...la.net>, linux-kernel@...r.kernel.org
Subject: Re: Linux 2.6.29

On Fri, 27 Mar 2009, Mike Galbraith wrote:
> > 
> > If you're using the kernel-of-they-day, you're probably using git, and
> > CONFIG_LOCALVERSION_AUTO=y should be mandatory.
> 
> I sure hope it never becomes mandatory, I despise that thing.  I don't
> even do -rc tags.  .nn is .nn until baked and nn.1 appears.

If you're a git user that changes kernels frequently, then enabling 
CONFIG_LOCALVERSION_AUTO is _really_ convenient when you learn to use it.

This is quite common for me:

	gitk v$(uname -r)..

and it works exactly due to CONFIG_LOCALVERSION_AUTO (and because git is 
rather good at figuring out version numbers). It's a great way to say 
"ok, what is in my git tree that I'm not actually running right now".

Another case where CONFIG_LOCALVERSION_AUTO is very useful is when you're 
noticing some new broken behavior, but it took you a while to notice. 
You've rebooted several times since, but you know it worked last Tuesday. 
What do you do?

The thing to do is

	grep "Linux version" /var/log/messages*

and figure out what the good version was, and then do 

	git bisect start
	git bisect good ..that-version..
	git bisect bad v$(uname -r)

and off you go. This is _very_ convenient if you are working with some 
"random git kernel of the day" like I am (and like hopefully others are 
too, in order to get test coverage).

> (would be nice if baked were immediately handed to stable .nn.0 instead
> of being in limbo for a bit, but I don't drive the cart, just tag along
> behind [w. shovel];)

Note that the "v2.6.29[-rcX" part is totally _useless_ in many cases, 
because if you're working past merges, and especially if you end up doing 
bisection, it is very possible that the main Makefile says "2.6.28-rc2", 
but the code you're working on wasn't actually _merged_ until after 
2.6.29. 

In other words, the main Makefile version is totally useless in non-linear 
development, and is meaningful _only_ at specific release times. In 
between releases, it's essentially a random thing, since non-linear 
development means that versioning simply fundamentally isn't some simple
monotonic numbering. And this is exactly when CONFIG_LOCALVERSION_AUTO is 
a huge deal.

(It's even more so if you end up looking at "next" or merging other 
peoples trees. If you only ever track my kernel, and you only ever 
fast-forward - no bisection, no nothing - then the release numbering looks 
"simple", and things like LOCALVERSION looks just like noise).

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