Date: Thu, 29 Jan 2009 22:30:08 +0000 From: Rui Paulo <rpaulo@freebsd.org> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-hackers@freebsd.org Subject: Re: INTR_FILTER? Message-ID: <E61A19DE-0435-44EC-A24F-F9330F3DF1E6@freebsd.org> In-Reply-To: <4981EC95.1090002@icyb.net.ua> References: <49819757.2010002@icyb.net.ua> <8F669786-30A2-458C-8A6B-3272297ADE14@freebsd.org> <4981EC95.1090002@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E61A19DE-0435-44EC-A24F-F9330F3DF1E6>