linux-kernel - Re: Linux 2.6.32-rc3

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: <1254864803.6035.25.camel@pasglop>
Date:	Wed, 07 Oct 2009 08:33:23 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Dirk Hohndel <hohndel@...radead.org>, Len Brown <lenb@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.32-rc3


> 
> It doesn't help, for several reasons:
> 
>  - the step function of the Makefile change happens once per release, and 
>    if you compile anything but releases, you can never rely on just the 
>    revision. Was it a plain -rc, a plain release, or something in 
>    between? You'll never know, just looking at the 2.6.x.y thing.
> 
>    In other words, you fundamentally have three choices:
> 
>     (a) be confused. Adding an "-rc0" won't help. You'll still be confused 
> 	in between releases about exactly what you're running.

Well, thing is, it's not us who are confused in general, it's users who
do reports with confusing versions. Yes, I agree that anything but a
release warrants a proper commit ID, but that's exactly what I asked for
when I wanted -rc0 here :-)

IE. That the -only- kernel that is called "2.6.x" is the release,
everything else has some kind of -rc in front of it, which allows me to
bug the user for a commit ID and know right away that this isn't a
release kernel.

>     (b) use CONFIG_LOCALVERSION_AUTO=y
> 
> 	Now, if 'uname -r' says 2.6.31, then you _know_ it's exactly 
> 	2.6.31 and nothing else. If it's a few commits after 2.6.31, it 
> 	will say something like '2.6.31-1-g752015d', and you know that 
> 	it's one commit after 2.6.31, and you'll know _which_ commit it is!
> 
>     (c) Don't compile anything but releases. 
> 
>    Those are the choices. 

Sure, when doing the stuff ourselves. Again, the problem is user
reports. Being able to distinguish between a 2.6.x "release" kernel and
anything else would be of value, at least to me. For anything else, I
can say "heh, you've been compiling non-release stuff, you should be
able to get me a git commit ID.

Difference boils down to users falling into two categories: Those who
compile non-release stuff, and should be able to figure out what the ID
is or recompile with LOCAL_VERSION set propertly etc... and those who
don't, didn't always compile the kernel themselves, and fortunately in
-most- cases are only running a "release".
 
>  - An even _more_ fundamental reason: Linux development isn't linear. 
>    There is not one "first commit" after a release, and there never will 
>    be. Sure, there's a first commit that I do, but that has absolutely 
>    zero relevance.

it would be easy enough for you to push a change to the Makefile just
after you tag a release and before you merge anything else.

>    Learn this. Until you do, you'll be confused, and you'll show your 
>    confusion by saying "I want a 2.6.n+1-rc0". You'll _also_ show your 
>    confusion by things like "I was bisecting a bug that happened between 
>    2.6.30 and 2.6.31, and suddenly git was asking me to test a kernel that 
>    said it was version 2.6.29-rc1 - so I stopped bisecting because git was 
>    confused".
> 
> Who was confused? Was it git, or was it the person who thought that the 
> Makefile version could be consistent in a non-linear world?
> 
> So no. I'm not going to do -rc0. Because doing that is _stupid_. And until 
> you understand _why_ it's stupid, it's pointless talking about it, and 
> when you _do_ understand that it's stupid, you'll agree with me.

I disagree. I understand the linearity problem. My point isn't about
having the Makefile provide with any kind of precise "pointer" into that
tree for non-release, but really only to differenciate a release from
anything else.

I know for somebody who uses git everyday, the concept of release even
becomes a bit fuzzy, but there's a lot of folks out there who really
don't see anything else :-) 

Cheers,
Ben.
 
> 			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/


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