How invasive would it be to add/require a per-CPU
servicing_interrupt() call to all the ports?
Or perhaps safe_to_sleep()?

That is, in any given kernel context you could ask "is
it safe to call tsleep from here?" (which is separate
from the question "is it *wise* to call tsleep from
here" :-) )

-matt


On Wed, 5 Sep 2001, Jason R Thorpe wrote:

> On Wed, Sep 05, 2001 at 05:58:32PM -0400, Paul Marchione wrote:
>
>  > I believe that this will work:
>  >
>  > if you test the curproc pointer, a zero value implies no process is currently
>  > running,
>
> No, this doesn't work... curproc can be non-NULL in interrupt context.  It
> would indicate which process was running on the CPU when the interrupt
> happened.
>
>  > you would thus have hit the code path from the kernel's hardclock function.
>  >
>  > i.e.
>  >
>  >     if  (!curproc)
>  >         {
>  >         /* base level 0, unsafe to call tsleep */
>  >         return;
>  >         }
>  >
>  > -paul
>  >
>  > Matthew Jacob wrote:
>  >
>  > > I have several possible entry points into a code path in a driver which can
>  > > decide whether to ltsleep for an event or poll. If I know I've entered via an
>  > > interrupt (e.g., the device interrupt service routine)- I can mark state so
>  > > that I don't attempt to ltsleep.
>  > >
>  > > But it turns out that there is a normal callback via hardclock (in scsipi)
>  > > that I have no means of distinguishing from any other call. How can I tell if
>  > > I'm on the interrupt stack and it's not safe to call ltsleep?
>  > >
>  > > -matt
>  >
>
> --
>         -- Jason R. Thorpe <thorpej@wasabisystems.com>
>