Re: How to use floating point in a module?
From: Måns Rullgård
Date: Sun May 30 2004 - 21:19:11 EST
> A driver, implemented as a module, must do some floating-point
> computations including trig functions.
Sorry, floating point in the Linux kernel isn't allowed.
> Fortunately the architecture is x86. A few hundred kilograms of
> searching (almost a ton of searching :-) seems to reveal the
> following possibilities.
> Recompile GNU's libc with option "--without-fp". If I understand
> correctly, the resulting libc will completely avoid using
> floating-point hardware while providing floating-point computations to
> its client. Do I understand correctly?
Probably, but it doesn't matter, since the kernel doesn't link with
> Compile the module's .c files with gcc's "-msoft-float" option and
> "-D__NO_MATH_INLINES". (Actually I think "-D__NO_MATH_INLINES" is
> probably unnecessary here.)
Using floating point emulation will be VERY slow.
> Link the module's .o files with the version of libc produced above,
> and try to get a loadable .ko from this... or a loadable .o since the
> target is still kernel 2.4.something.
As I said, the kernel doesn't link with libc.
> But I'm sure there must be a ton of pitfalls that I'm not seeing here.
> I'm not the first poor slob who got tasked with shoving some
> floating-point into a module. My searches found a few tricks that
> people used for a few floating-point operations, but they used the
> real floating-point hardware and they didn't really reveal all the
> trickery they used. (Not that I can blame them, since the hackery
> they did must be virtually unteachable.) I didn't find anyone saying
> that they found a safe method of doing it, whether or not a safe
> method might somewhat resemble the ideas I've just presented. I
> didn't find anyone saying they got trig functions into it either. If
> my ideas could possibly work, surely they would have been done
> already. So, what am I missing?
Floating point is forbidden in kernel code since the floating point
registers (and other floating point context) is not saved/restored
during system calls, for efficiency. I'm speculating here, but it
might be possible to manually save the floating point context while
doing some floating point operations. The problem arises if this code
is interrupted midway. Using a preemptive 2.6 kernel would easily
What you should do is think again about why you need all this floating
point in the kernel. Could it be moved to userspace somehow? Maybe
you could use lookup tables instead of doing floating point
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/