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]
Date:	Tue, 26 Oct 2010 11:53:47 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jan Beulich <JBeulich@...ell.com>,
	Alexander van Heukelum <heukelum@...tmail.fm>,
	Ingo Molnar <mingo@...e.hu>, akpm@...ux-foundation.org,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	David Howells <dhowells@...hat.com>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers
 in brackets

On Mon, 25 Oct 2010, H. Peter Anvin wrote:

> > No reason to make for maintenance problems and uglier code if we can
> > just say "get a newer gas" to a few people. It's not like we haven't
> > done that with gcc and other tools too.
> 
> The problem is that 2.16 isn't all that old; al lot of the "enterprise"
> distros still ship it or AFAIK even older versions.  2.6.90 which I
> *think* is the first fixed version dates from April 2005, so is
> currently 5 years old; maybe that is within reason to kill off.

 For the record -- binutils 2.21 are about to be released and for several 
years now the schedule has roughly been one major release per year, 
sometimes followed by some bug-fix minor releases as needed.  That'll make 
2.16 *five* releases away from the current version and hardly a reason to 
keep maintaining support for it in the face of critical problems.

 If some random distribution insists on maintaining such old tools, then 
it's their responsibility to backport critical fixes, such as these 
required to get the parser (or whatever piece of code is responsible for 
the breakage observed here) right, isn't it?  Then once they did it, they 
can patch up their kernels to accept their tools too.

 Also note that *.*.9x versions are snapshots from the FSF repository (so 
there's no fixed date associated with them), which also delegates 
maintenance responsibility to whoever packages them and makes available to 
people.  In the state as imported from the repository they may have odd 
problems or grave bugs, as exhaustive regression testing is generally only 
made after a release branch has been created and otherwise changes to the 
head of the tree are only tested for a limited subset of targets before 
they are applied.  Therefore local fixes are inevitable for them anyway.

 And last but not least binutils are one of the easier tools to build from 
sources, so installing a newer version, especially when it comes to native 
tools (hardly anyone uses cross-compilation targeting x86, I believe), 
somewhere under $HOME to use for kernel builds is a trivial effort:

$ ./configure --prefix=$HOME/somewhere && make && make install
$ PATH=$HOME/somewhere/bin:$PATH

Certainly much easier than building the kernel, especially when it comes 
to selecting the right configuration options.

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