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: <4C0DE526.40504@panasas.com>
Date:	Tue, 08 Jun 2010 09:37:26 +0300
From:	Boaz Harrosh <bharrosh@...asas.com>
To:	David Rientjes <rientjes@...gle.com>
CC:	Ingo Molnar <mingo@...e.hu>,
	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 - two for the
 price of one - No thanks

On 06/08/2010 09:18 AM, David Rientjes wrote:
> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
> 
>>>> I already have my:
>>>>  VERSION = 2
>>>>  PATCHLEVEL = 6
>>>>  SUBLEVEL = 35
>>>> -EXTRAVERSION = -rc2
>>>> +EXTRAVERSION = -rc2-my_tree
>>>>
>>>
>>> You shouldn't be using EXTRAVERSION for this purpose, you should be 
>>> passing LOCALVERSION=my_tree to make.
>>>
>>
>> That will not work because the way I run make is out of my control. Every
>> one in the working group has his system. The Makefile is part of the
>> public git tree, so every one will get the same identification without
>> any confusion with Vanilla kernel, or what was compiled.
>>
> 
> If everyone using that tree wants the same version string for that kernel, 
> use CONFIG_LOCALVERSION="-my_tree" in your .config and use "make 
> LOCALVERSION=".

That does not work I tried LOCALVERSION is checked for emptiness. So the
"plus" is added just the same. I tried:

$ make			# gets a plus
$ make LOCALVERSION=""	# same plus

CONFIG_LOCALVERSION will not work because it, too, is not in the git. I need
something that everyone can get by checkout. (The config file is usually a
distro config with make oldconfig)

> 
>>> Unless it's a vanilla 2.6.35-rc2 kernel, it's inaccurate to persent it as 
>>> 2.6.35-rc2; you'll need to pass LOCALVERSION to make to identify this as a 
>>> non-vanilla kernel.
>>
>> What are we lawyers? come on. And I do not have that problem! The output will
>> not be 2.6.35-rc2 as you fear. It will be 2.6.35-rc2-my-tree-my-version.
> 
> That's because you're using EXTRAVERSION which is also used upstream to 
> describe kernel releases (stable, rc, mm, etc).
> 

That's why it is perfect. Because I have that patch as first in my tree that
changes that in Makefile. Then from time to time when I rebase I get the
conflict with Linus change of the name, and have the privilege to specify how
this is a different tree, with a different name and version. It is all git work
no external factors. (That I will keep, regardless of plus or no plus)

And you have not answered my question:
  What does the CONFIG_LOCALVERSION_AUTO give me? the name is changed regardless
  so now it has become. Min-Auto-Name or Informative-Auto-Name. It used to be
  Auto-name-yes or Auto-Name-no. Please change the config name to reflect the choice
  we actually have. (And keep the old config because we need the original choice)

>> Please stop this *none-sense* this is not your place to mandate my Kernel name. If
>> I'm forced to have an external Makefile I can just "mv" what ever name I choose.
>> The Kernel name is an ABI you have just broken that, You must revert it ASAP.
>>
> 
> You still have the tools available to do everything you once did.

No! how? I couldn't find how please specify exact commands to use.

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