linux-kernel - Re: [PATCH] Partially revert patch that encloses asm-offset.h numbers in brackets

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 18:34:10 +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 Tue, 26 Oct 2010, H. Peter Anvin wrote:

> >  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.
> 
> Well, sort of... the x.x.9x releases used in production -- specifically
> the ones with a numbering scheme like x.x.9x.0.x -- in the Linux world
> tend to be the ones maintained and released by H.J. Lu:
> 
> http://www.kernel.org/pub/linux/devel/binutils/

 Yeah, in practice this means the packagers have an additional choice to 
pester H.J. if something goes wrong. ;)

 I used H.J.'s releases once too, then around 2.9.4 I switched over to 
pristine FSF sources as I figured out I needed to make own fixes for the 
MIPS port and it was easier for me to propagate them upstream this way.  
And overall I found no problems (apart from the usual bugs here and there 
every once in a while) having since used them for the Alpha, MIPS, VAX and 
x86 ports of Linux (OK, perhaps x86 is not a port ;) ), so the choice 
between the two flavours is mostly the matter of taste it would seem.

> >  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.
> 
> Yes, although there is also a version dependency between binutils and
> gcc, as I unhappily found out trying to run an upversion gcc on an old
> distro at one point.

 Fair enough if you do it this way, but switching to a higher version of 
binutils shouldn't ever be a problem.  GCC detects some binutils features 
at the configuration time and sets itself up accordingly, but these do not 
get removed, at least not that I heard of.

  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/