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: <200910062137.06593.elendil@planet.nl>
Date:	Tue, 6 Oct 2009 21:37:05 +0200
From:	Frans Pop <elendil@...net.nl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	mingo@...e.hu, hohndel@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: Linux 2.6.32-rc3

On Tuesday 06 October 2009, you wrote:
> On Tue, 6 Oct 2009, Frans Pop wrote:
> > Enabling it by default somehow would be fine with me, but "compulsory"
> > is a step to far IMO. Users should always be allowed custom schemes.
>
> I do respect that - we shouldn't _force_ things if some people have
> special needs and do things differently and really need a very
> particular version number setup.

Note that I was referring to adding on the full commit identification. I 
have a lot less problems with the "+" (or whatever we end up with).

I would probably even use it, although it will mean that I effectively 
_always_ have the "+" because of local patches. But that is correct as 
with the patches it's no longer a vanilla release.

> That said, we might make it a lot harder for people to overlook this by
> mistake when they don't care or know enough. Maybe we can have three
> levels of the "automatic" version number, and make the third level ("no
> automatic sign of versioning at all") be something that you really need
> to ask for (eg you need to have EMBEDDED enabled to show that you want
> the whole extended config option setup or something fairly draconian
> like that).

I'd opt for the "or something" as I think it would be a mistake to link it 
to EMBEDDED. That has a rather different purpose.

One case to consider is distributions. They will have their own patches, 
possibly as a branch off mainline in git.
AFAICT with the current patch they'd automatically always get the "+", 
which is almost certain to conflict with their own naming schemes.
Distro configs with EMBEDDED set also does not seem right. Nor should it 
IMHO be needed to have to patch the Makefile to get rid of it.

I think just having a config option with the three choices you suggest and 
an appropriate help text to guide users should be sufficient, with the one 
that activates the "+" as default.

Cheers,
FJP
--
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