From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM64: Disabling warnings about deprecated armv8 instructions
Date: Mon, 30 Jan 2017 17:09:47 +0000 [thread overview]
Message-ID: <CAKv+Gu_jEvKdWFWB2Ofxb5ruoTYUEt1puZXBb=9Cn2kEOZO1hg@mail.gmail.com> (raw)
In-Reply-To: <20170130165837.GE27312@n2100.armlinux.org.uk>
On 30 January 2017 at 16:58, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Mon, Jan 30, 2017 at 02:50:23PM +0000, Ard Biesheuvel wrote:
[..]
>> I see. I was indeed mainly referring to userspace, which is what this
>> thread is about, specifically setend and the CP15 barrier
>> instructions. You can disagree with ARM's policy to deprecate and
>> remove some instructions, but given the reality of it, I think it is
>> perfectly reasonable to warn by default about setend instructions
>> issued in 32-bit userspace when running under the 64-bit ARMv8 kernel.
>
> Linus has commented on this in the past, and his reaction (iirc) was
> that deprecating instructions that userspace uses is not a sane
> behaviour, pointing out that instructions that i386 supported still
> work today on the latest Intel CPUs.
>
> He has a point, it's the same argument against breaking userspace
> through making a change to the kernel. It gives users a painful
> experience.
>
> That said, no one expects that you can run an i386 binary on ARM,
> which is pretty much understood by users. However, ARM vs ARM64
> where ARM64 provides a 32-bit ARM compatible environment is a
> totally different story - it's _not_ compatible if it complains
> about instructions that _were_ legal with 32-bit ARM binaries.
> It makes me question the value of providing what is an incompatible
> environment to run older binaries.
>
> The purpose of such an environment is to provide _compatibility_ to
> older binaries. You aren't providing a compatible environment if
> you then decide to noisily warn about deprecated instructions.
>
> You might as well just rebuild the binaries for a 64-bit environment
> and stop the illusion of a 32-bit compatible environment, because it
> isn't.
>
Well, the question is really how to deal with 32-bit compatibility
given the fact that the ARM architecture will drop such instructions
in its next revision. Whether we agree with that, and whether we
should argue our positions with the architects if we don't is not
relevant here.
What is relevant is whether we inform userspace if we spot such a
deprecated instruction, and I think we should.
Note that this is not only an issue for the arm64 kernel. The 32-bit
kernel will have the exact same issue when you try to run it on
hardware that no longer has support for those instructions.
next prev parent reply other threads:[~2017-01-30 17:09 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-22 8:07 ARM64: Disabling warnings about deprecated armv8 instructions Michael Zoran
2017-01-22 8:52 ` Alexander Stein
2017-01-22 8:58 ` Michael Zoran
2017-01-22 9:05 ` Jisheng Zhang
2017-01-22 9:38 ` Michael Zoran
2017-01-22 9:43 ` Ard Biesheuvel
2017-01-22 9:52 ` Michael Zoran
2017-01-22 9:56 ` Michael Zoran
2017-01-22 10:54 ` Ard Biesheuvel
2017-01-22 11:05 ` Michael Zoran
2017-01-22 11:22 ` Michael Zoran
2017-01-22 9:09 ` Ard Biesheuvel
2017-01-22 9:33 ` Michael Zoran
2017-01-22 9:36 ` Ard Biesheuvel
2017-01-22 9:49 ` Michael Zoran
2017-01-22 11:46 ` Alexander Stein
2017-01-22 12:21 ` Michael Zoran
2017-01-22 13:01 ` Ard Biesheuvel
2017-01-22 14:02 ` Michael Zoran
2017-01-22 15:05 ` Ard Biesheuvel
2017-01-30 14:13 ` Russell King - ARM Linux
2017-01-30 14:50 ` Ard Biesheuvel
2017-01-30 16:38 ` Måns Rullgård
2017-01-30 16:58 ` Russell King - ARM Linux
2017-01-30 17:09 ` Ard Biesheuvel [this message]
2017-01-30 17:39 ` Eric Anholt
2017-01-30 17:41 ` Michael Zoran
2017-01-30 18:17 ` Måns Rullgård
2017-01-30 18:34 ` Michael Zoran
2017-01-30 18:49 ` Will Deacon
2017-01-30 19:53 ` Michael Zoran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKv+Gu_jEvKdWFWB2Ofxb5ruoTYUEt1puZXBb=9Cn2kEOZO1hg@mail.gmail.com' \
--to=ard.biesheuvel@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).