Hmm? How?

I mean, without mucking with the code that got started outside my driver?

Paul suggested testing against curproc- that won't work (looking at interrupt
path for Alpha it neither sets nor clears cuproc, so this can't be used as a
general 'on interrupt stack' test).

On Wed, 5 Sep 2001, Christos Zoulas wrote:

> In article <20010905140647.D18531-100000@wonky.feral.com>,
> Matthew Jacob <mjacob@feral.com> wrote:
>
> pass an extra argument?
>
> christos
>
> >
> >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
> >
> >
> >
>
>
>