Using kernel_fpu_begin() in device driver - feasible or not?

[Rickard Westman <rwestman@telia.com>]

Hi,

I am porting a device driver from an embedded platform where it's OK
to do floating-point arithmetic in drivers.  To make it easy to
incorporate future improvements from this "reference driver", I have
tried to keep my modifications at a minimum, with most Linux-specific
code clearly separated.  The heavy use of interspersed floating-point
arithmetic is an obstacle, though, as I'm aware of the policy to avoid
floating-point arithmetic in the Linux kernel.

Ideally, I'd like to use the FPU in a daemonized kernel thread created
by the driver, and possibly from process context as well (in the
implementation of some ioctl:s.)  The target architecture is i386, and
non-portable solutions are quite acceptable.

Now, I've noticed that there are two interesting-looking functions in
the 2.4 kernel: kernel_fpu_begin() and kernel_fpu_end().  I have found
little information on how to use them, though, and I'd appreciate any
hints and guidelines.  Here are some issues I'm concerned about:

1. Would it be sufficient to just bracket all fpu-using code code by
kernel_fpu_begin()/kernel_fpu_end()?  If not, what problems could I
run into?

2. Would it be OK to go to sleep inside such a region, or should I
take care to avoid that?

3. Perhaps I should call init_fpu() at some point as well?  If so,
should it be done before or after kernel_fpu_begin()?

4. Is there any difference between doing this in the context of a user
process (implementation of an ioctl) compared to doing it in a
daemonized kernel thread (created by a loadable kernel module)?

5. The functions mentioned above are not exported for use by loadable
modules, but I guess that could be arranged for.  Is there any other
reason why it shouldn't work from a loadable kernel module?

Suggestions on alternative approaches are welcome as well, of course,
but I *do* realize that I could replace the calculations with
fixed-point arithmetic, divide things so that all floating-point
calculations were done in user-space, and similar ways to dodge the
issue.  But for now, I'm just looking for feedback on how to actually
do it in kernel space, aesthetics aside...

-- 
Rickard Westman         "Beware of the panacea peddlers: Just
<rwestman@telia.com>     because you wind up naked doesn't
                          make you an emperor."
                                     - Michael A Padlipsky