INTR_FILTER?

[Rui Paulo]

On 29 Jan 2009, at 17:51, Andriy Gapon wrote:

> on 29/01/2009 19:17 Rui Paulo said the following:
>>
>> On 29 Jan 2009, at 11:47, Andriy Gapon wrote:
>>
>>> INTR_FILTER - what does it do?
>>> It doesn't seem to be documented anywhere, but seems to affect  
>>> interrupt
>>> code.
>>
>> INTR_FILTER allows you to skip the FILTER+ITHREAD headache.
>
> Could you please explain a little bit what is this headache?

Basically, you use filter + ithread (intr_filter) when you want to do  
more than basic things in your interrupt handler routine. For example,  
allocating memory must be done in a ithread, it can't be done on the  
interrupt routine.

> I thought, similarly to what Ed said, that in filter one could quickly
> check for a stray interrupt (or shared interrupt from other device)  
> and
> in ithread one could perform meaningful work.

That's right. But INTR_FILTER does all the filter + ithread setup for  
you via FILTER_SCHEDULE_THREAD.

> But I also had some doubts about what is legal and what is illegal in
> ithread. E.g. could I take a non-spin mutex or wait on a condvar? I
> guess not - because in the case of shared interrupts the same  
> ithread is
> used to handle everything.
>
>> See dev/asmc/asmc.c for an example.
>
> Thank you, the example is enlightening. But also one has to look into
> how "the framework" works (or just know it) to understand why things  
> are
> done this way but not the other. E.g. why you have to use a  
> taskqueue in
> non-INTR_FILTER case.

I needed a taskqueue because devctl_notify() calls malloc and you  
can't call malloc (which holds some type of lock, I can't remember)  
from an interrupt context (asmc_sms_intrfast())


> BTW, INTR_FILTER seems quite useful. Why, then, it is not the default?

The drivers would have to be ported to INTR_FILTER. Right now, only  
asmc is using INTR_FILTER, so I don't think there is much gain in  
making it the default.

--
Rui Paulo