> Date: Fri, 18 Sep 1998 13:51:54 -0700 (PDT)
 > From: "Dr. Bill Studenmund" <wrstuden@loki.stanford.edu>
 > Cc: Andreas Gustafsson <gson@araneus.fi>, tech-kern@netbsd.org
 > 
 > On 18 Sep 1998, Chris G. Demetriou wrote:
 > 
 > > >  b) fixable?
 > > 
 > > You can probably fix it, but again, it's not desirable that you do so.
 > > I doubt that NetBSD would buy back the fix, even if you do, but i'm
 > > not authoritative there.
 > > 
 > > You won't be able to fix it as an LKM, though.  you need to replace
 > > choice bits of existing code.
 > 
 > Would it be possible to let the lkm do floating point, assuming it's
 > sufficiently careful? I.E. how much as to change in the kernel to let code
 > do this?
 > 
 > I agree that in general we don't want to permit it, but it sounds like
 > this application needs it. So a viable compromise would be for the driver
 > to set some sort of soft interupt level to keep the scheduler from
 > switching to a different user process, saving the FPU state, and then
 > letting the code have at it. When the code's done, it just resets the FPU
 > state, and lowers the spl level.

I would expect that kernel saves/restores user's FPU state so it should be
safe just use FP in kernel mode assuming that you are the only part of kernel
who does that. Don't know what to do with interrupts from FP in kernel mode.

 > 
 > Take care,
 > 
 > Bill
 > 
 > 

Regards,
	Andrey