Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Feb 2009 12:17:26 +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:  <86915A93-6023-465F-B937-E9905AFDA4B0@freebsd.org>
In-Reply-To: <4986E08F.2010305@icyb.net.ua>
References:  <49819757.2010002@icyb.net.ua> <8F669786-30A2-458C-8A6B-3272297ADE14@freebsd.org> <4981EC95.1090002@icyb.net.ua> <E61A19DE-0435-44EC-A24F-F9330F3DF1E6@freebsd.org> <4986DB28.6080503@icyb.net.ua> <3EAA1D8D-606B-4F59-81B6-644B56AE4831@freebsd.org> <4986E08F.2010305@icyb.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-3--280707313
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit


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 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.
>>>
>>> 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
>>> anything. The API and conventions seems to be the same too.
>>> There could be some edge cases, of course.
>>
>> Ok, but why enable it in GENERIC right now if the only driver that  
>> uses
>> INTR_FILTER is asmc?
>> There's not much point in enabling it now. Maybe in the future.
>
> I may be wrong but this could auto-magically improve some cases where
> there are shared interrupts between drivers with ithreads. In this  
> case,
> I think, their interrupt handler would be run "in parallel" instead of
> sequentially.

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.


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

--
Rui Paulo


--Apple-Mail-3--280707313
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkmG5FYACgkQfD8M/ASTygLeVQCcCAaPjIhR0ZN79fJR+ATNKIP6
qPUAnjOMxnESB/wVwjbHRhoeFkUEcCOy
=y1Q3
-----END PGP SIGNATURE-----

--Apple-Mail-3--280707313--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86915A93-6023-465F-B937-E9905AFDA4B0>