On Fri, 18 Sep 1998, Todd Vierling wrote:

> : 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.
> 
> The only level that prevents that kind of switch is splhigh(), and you
> definitely don't want your FPU intrinsics running there.  Particularly when
> kernel threads arrive (and your code will be required to be reentrant), that
> will break anyway.

What? spl-anything locks the scheduler out, doesn't it? That's the whole
way spltty, splimp, etc work. spltty is specificly to keep other stuff,
including other proceses, from touching the tty queues. splimp keeps
things out of the malloc code...

My whole idea was that since we only mess with the FP registers when we
switch proceses (and not when we deal with interupts), as long as we don't
switch proceses while the dsp code is playing w/ the fpu registers, (and
the DSP code saves/restores the FP state), we should be fine.

We can keep servicing interupts, receiving packets, serial characters,
writing to disk drives, possibly doing splsoftnet or splsoftserial
actions, while the DSP code is running. As long as the other interupt
servicers don't use FP, we're fine.

Take care,

Bill