Thread (24 messages) flat view 24 messages, 7 authors, 2014-05-23

[PATCH] ARM: remove ARM710 specific assembler code

From: catalin.marinas@arm.com (Catalin Marinas)
Date: 2014-05-17 09:56:08
Also in: lkml

On 17 May 2014, at 10:46, Russell King - ARM Linux [off-list ref] wrote:
On Sat, May 17, 2014 at 10:23:37AM +0100, Catalin Marinas wrote:
quoted
On Fri, May 16, 2014 at 01:55:46PM +0100, Russell King - ARM Linux wrote:
quoted
There was a CPU called the ARM710, it was ARMv3 and it had no Thumb support.

There is also a CPU called the ARM710T, which is ARMv4 and has Thumb support.

These are two completely different CPUs, the former was removed along with
the removal of ARMv3 support.  The latter remains because we still support
ARMv4.
BTW, while clearly this patch was removing code for the wrong reasons, I
think we should set a longer term timeline for getting rid of some of
old features. Let's say in 10 years time we remove everything ARMv4,
another 10 years ARMv5 and so on. We could make these milestones shorter
but it really depends on what people use, we should not force them out
of the kernel if still in use.
I still use StrongARM based machines here, and I don't see that changing
unless some suitably designed ARM boards come my way which (a) offer the
same features and (b) out perform it.

The problem is that there's lots of ARM boards which satisfy (b) - the
iMX6 stuff clearly does - but hardly anything which satisfies (a).

There's also been some recent effort with SA1100 SoC code, so there's
also other interest there still.

So, ARMv4 is still very much in use with modern kernels.
That?s why I said maybe aim for removing it in 10 year. But if code is
still in use by that time, we keep it.
The difference between what you're proposing and what happened to ARMv3
is that ARMv3 was broken for quite some time (we read from some of the
CP15 registers which are read-only in ARMv3) and no one ever raised a
problem with that.  So, after a sufficient period of time, it got removed
- and no one batted an eyelid.  That's the correct way to do it - allow
code to age, and if no one notices it's been broken, then it can be
removed.
I?m more for pro-actively ?breaking? it with a DEPRECATED
dependency. For example, if you suspect that some code like ARM710T is
no longer in use, we mark it and see if anyone complains about this over
a two years period. If not, it gets removed.

Waiting for code to get broken is another way but it?s less
predictable.

Catalin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help