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>