[PATCH] ARM: remove ARM710 specific assembler code

[Catalin Marinas]

On 17 May 2014, at 10:46, Russell King - ARM Linux <linux at arm.linux.org.uk> wrote:
> On Sat, May 17, 2014 at 10:23:37AM +0100, Catalin Marinas wrote:
>> On Fri, May 16, 2014 at 01:55:46PM +0100, Russell King - ARM Linux wrote:
>>> 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