Re: INTR_FILTER?

[Rui Paulo]

On 2 Feb 2009, at 12:01, Andriy Gapon wrote:

on 02/02/2009 13:53 Rui Paulo said the following:

On 2 Feb 2009, at 11:38, Andriy Gapon wrote:

on 30/01/2009 00:30 Rui Paulo said the following:

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

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

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

anything. The API and conventions seems to be the same too.
There could be some edge cases, of course.

I am not sure about this part. From the code it seems that INTR_FILTER is backward-compatible, i.e. it gives something and doesn't take away

INTR_FILTER is asmc?
There's not much point in enabling it now. Maybe in the future.

Ok, but why enable it in GENERIC right now if the only driver that uses

I may be wrong but this could auto-magically improve some cases where

I think, their interrupt handler would be run "in parallel" instead of
sequentially.

there are shared interrupts between drivers with ithreads. In this case,

I haven't read the details of the implementation yet, but how does that work?

Also, it would make it easier to write new drivers - one would not have

to code for !INTR_FILTER case.

--
Rui Paulo

Yes, but essentially, backporting needs the !INTR_FILTER case. And I don't know about !i386 && !amd64 archs.

PGP.sig
Description: This is a digitally signed message part