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:	Sat, 17 May 2014 10:56:02 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Paul Bolle <pebolle@...cali.nl>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Arnd Bergmann <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ARM: remove ARM710 specific assembler code

On 17 May 2014, at 10:46, Russell King - ARM Linux <linux@....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--
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