All of lore.kernel.org
 help / color / mirror / Atom feed
From: mzoran@crowfest.net (Michael Zoran)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM64: Disabling warnings about deprecated armv8 instructions
Date: Mon, 30 Jan 2017 09:41:32 -0800	[thread overview]
Message-ID: <1485798092.484.5.camel@crowfest.net> (raw)
In-Reply-To: <CAKv+Gu_jEvKdWFWB2Ofxb5ruoTYUEt1puZXBb=9Cn2kEOZO1hg@mail.gmail.com>

On Mon, 2017-01-30 at 17:09 +0000, Ard Biesheuvel wrote:
> 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.

Just to inject two cents worth since I'm still on the thread and I
originally started the topic...

The Intel comparison seems relevant.  I think in theory you can still
run old MS-DOS software on an Intel PC if you were so inclined to do
so.

I would think the best would be to turn the warnings off by default
when running in 32 bit mode with the option to turn them back on.  Then
as time progresses more of more of these instructions can be converted
to software emulation and removed from the hardware.  And hopefully as
time progresses, all the user mode software gets upgraded to 64 bit so
that 32 bit get dropped.

The issue seems to me to be more that the kernel is screaming in the
logs rather then if it's emulating the instructions in hardware or
software.

  parent reply	other threads:[~2017-01-30 17:41 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
2017-01-30 17:39                     ` Eric Anholt
2017-01-30 17:41                     ` Michael Zoran [this message]
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=1485798092.484.5.camel@crowfest.net \
    --to=mzoran@crowfest.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.