[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1010261126590.15889@eddie.linux-mips.org>
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