Question for the lists: does it make sense to pursue a software floating point solution as opposed to trapping floating point instructions? My guess to the answer would be no, as I suspect that 99.9%+ of the code that runs in Linux (both in the kernel and in userland) does not use floating point, but if that's wrong, I'd be interested in hearing opposing viewpoints.Fixing the handling of real FPU instructions would be better. That way you don't crash stuff if you accidentally run a regular 68k binary on your box. Although it's not like it kills the whole kernel anyway.
This is a nice idea, but a majority of the LC040s out there are the ones with the more extreme bug where the process' state isn't properly saved. Nothing short of something which generates tons of overhead is going to fix that.
I think you're drastically underestimating where floating point shows up in regular software. I know things like perl have a tendency to trigger this bug. X is pretty heavy on the FPU as well. While it would be possible to recompile everything, it takes long enough to compile just once. The 68k build boxes for Debian barely keep up as it is.
Floating point is used everywhere. Even common stuff like top uses it.With NetBSD, we've added softfloat to gcc (thanks, Bruce O'neel), created softfloat OS snapshots for download, plus I have two dedicated m68060 machines doing softfloat binary packages. I am only doing non-X apps at the moment since I can't imagine that people with LC040 systems are going to expect to have a GUI, but the X apps will come soon.
While Debian's resources should obviously stay with the regular m68k builds, I can definitely see that making a kernel and OS snapshot available for broken LC040 systems every now and again would not be hard.
John Klos