On Wednesday,  5 September 2001 at 16:26:50 -0700, Matt Jacob wrote:
> On Tue, 4 Sep 2001, Bill Studenmund wrote:
>> On Wed, 5 Sep 2001, Matthew Jacob wrote:
>>> Hmm? How?
>>>
>>> I mean, without mucking with the code that got started outside my driver?
>>
>> I think the idea is that you make can-sleep and can't-sleep entry points.
>> All they might do is set a parameter and then call a common routine, which
>> uses that parameter to tell if it can sleep.
>>
>> You then tell the things which will call you when you can sleep to use the
>> can-sleep entry, and the ones which will call you in an interrupt context
>> you give the can't sleep one.
>>
>> I am making one big assumption here - that there is no way that one single
>> registration (like registering an interrupt handler or a call back, etc.)
>> won't call you sometimes in an interrupt context and sometimes not.
>>
>> Does that make sense?
>
> Yes. But the problem turns out to be that there are entry points
> which I *can't* vary that can, apparently, be called from interrupt
> context or not- and I'd been assuming that I could at least be the
> one to tell if they were in interrupt context because it couldn't
> have gotten there w/o going through me.  That turns out to not be
> the case.

Correct me if I'm wrong, but IIUC processes run with all interrupts
enabled.  All interrupts mask at least one interrupt, so you could
look at the interrupt mask to determine whether you're in interrupt
context.  Unfortunately, I don't know a portable way to find out the
interrupt mask.  Let me know what you do: I'm facing the same issue
with Vinum.  FWIW, FreeBSD uses the variable intr_nesting_level for
other purposes, but it's also a convenient way of determining whether
you're in interrupt context.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers