From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 29 22:30:33 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 524AB10656F9 for ; Thu, 29 Jan 2009 22:30:33 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id A5F4A8FC26 for ; Thu, 29 Jan 2009 22:30:32 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ewy14 with SMTP id 14so507484ewy.19 for ; Thu, 29 Jan 2009 14:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=qX0o1GoMif3YtD8c9mCruSXp1gkK2ioexaOp3ODsJqo=; b=VuHkOdmmxWhPg3g3UPtDSpNkD92MJfgnnZD4Zgen7pF6npNgRdmGdlzxwkBluGPiou ZhxZa7cbIrXq63w6KqhD+9ksKpXrJSljZyJEJO7OwHoktKfNAe62ndyWfj1PjJwtEF5X zJVhwo0UtqH7ka/0HfCbogZFNXRaMs4MlGeL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=lXHtkC+Sy5BC1svmkIU4sG1ntBtYrSn7u307HcmcPdFsMqwFSniBJaMrZ1jKYPQ5+J I96eFwiaMUri35HMUoh6OLjmKa8qzfEMC/3+6nuA/An+DTmtY+msE1ikfdUAKRFkYfw/ 8/ubkiBd25/V54Pc6Z9mCUIlb7ogIxLtCf5I0= Received: by 10.210.92.11 with SMTP id p11mr679112ebb.2.1233268231396; Thu, 29 Jan 2009 14:30:31 -0800 (PST) Received: from epsilon.lan (bl6-156-29.dsl.telepac.pt [82.155.156.29]) by mx.google.com with ESMTPS id d23sm579850nfh.28.2009.01.29.14.30.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Jan 2009 14:30:30 -0800 (PST) Sender: Rui Paulo Message-Id: From: Rui Paulo To: Andriy Gapon In-Reply-To: <4981EC95.1090002@icyb.net.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 29 Jan 2009 22:30:08 +0000 References: <49819757.2010002@icyb.net.ua> <8F669786-30A2-458C-8A6B-3272297ADE14@freebsd.org> <4981EC95.1090002@icyb.net.ua> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-hackers@freebsd.org Subject: Re: INTR_FILTER? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2009 22:30:34 -0000 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