All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Paul Burton <paul.burton@imgtec.com>
Cc: Manuel Lauss <manuel.lauss@gmail.com>,
	Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: [RFC PATCH v4 2/2] MIPS: make FPU emulator optional
Date: Mon, 7 Apr 2014 18:28:57 +0200	[thread overview]
Message-ID: <20140407162857.GQ17197@linux-mips.org> (raw)
In-Reply-To: <20140407135315.GX14803@pburton-linux.le.imgtec.org>

On Mon, Apr 07, 2014 at 02:53:15PM +0100, Paul Burton wrote:

> On Mon, Apr 07, 2014 at 12:57:04PM +0200, Manuel Lauss wrote:
> > This small patch makes the MIPS FPU emulator optional. The kernel
> > kills float-users on systems without a hardware FPU by sending a SIGILL.
> 
> One issue with this is that if someone runs a kernel with the FPU
> emulator disabled on hardware that has an FPU, they're likely to hit
> seemingly odd behaviour where FP works just fine until they hit a
> condition the hardware doesn't support. To make it clear that using FP
> without the emulator is a bad idea, perhaps it would be safer to disable
> FP entirely rather than only the emulator? Then userland can die the
> first time it uses FP instead of when it happens to operate on a
> denormal.
> 
> Unless there are FPUs which never generate an unimplemented operation
> exception, in which case perhaps more Kconfig is needed to identify such
> systems & allow the emulator to be disabled for those only.

The original reason for me to remove the FPU emulator option was that I
was getting flooded by bogus bug reports because users thought they could
remove the FPU emulator with a hardware FPU present.

Another pain point is that soft-FPU establishes another ABI variant so
I'd not mind to see soft-FPU go.

Some of the tradeoffs involved were a bit bogus at times.  Soft-fp
application code can be much bigger than hard-fp - to the point where the
50k or so for the kernel FP software are a good investment.

But I don't mind making the FPU emulator selectable again - but this
time with nasty kernel messages and killing of processes that happen to
dare to execute a FPU instruction.

  Ralf

  parent reply	other threads:[~2014-04-07 16:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-07 10:57 [RFC PATCH v4 1/2] MIPS: move mmips branch support code out of the fpu emu code Manuel Lauss
2014-04-07 10:57 ` [RFC PATCH v4 2/2] MIPS: make FPU emulator optional Manuel Lauss
2014-04-07 13:53   ` Paul Burton
2014-04-07 14:48     ` Manuel Lauss
2014-04-07 15:06       ` Paul Burton
2014-04-07 16:28     ` Ralf Baechle [this message]
2014-04-07 16:37       ` Florian Fainelli
2014-04-07 18:02         ` Ralf Baechle
2014-04-07 18:04           ` Florian Fainelli

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=20140407162857.GQ17197@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=linux-mips@linux-mips.org \
    --cc=manuel.lauss@gmail.com \
    --cc=paul.burton@imgtec.com \
    /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.