2014-04-07 9:28 GMT-07:00 Ralf Baechle <ralf@xxxxxxxxxxxxxx>: > 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. We have had the same problems in OpenWrt, but we now output a big fat warning to say "hey your kernel does not have FPU". > > 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. There are some braindead bootloaders out there that will only allow for a small kernel partition, while the rootfs partition can virtually span the remainder of the available flash space... and all sorts of crazy designs like these. > > 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. I think it is good to offer this as an option (hint: just like what ARM does) along with the necessary warnings/messages to make sure that bug filters can be easily filtered out. -- Florian
