From owner-freebsd-questions@FreeBSD.ORG  Tue Apr 22 14:49:11 2003
Return-Path: <owner-freebsd-questions@FreeBSD.ORG>
Delivered-To: freebsd-questions@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 1B35F37B401
	for <freebsd-questions@FreeBSD.org>;
	Tue, 22 Apr 2003 14:49:11 -0700 (PDT)
Received: from aramis.rutgers.edu (aramis.rutgers.edu [128.6.4.2])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 56EC843FE5
	for <freebsd-questions@FreeBSD.org>;
	Tue, 22 Apr 2003 14:49:10 -0700 (PDT)
	(envelope-from bohra@cs.rutgers.edu)
Received: from cs.rutgers.edu (sirtaki.rutgers.edu [128.6.171.146])
	by aramis.rutgers.edu (8.11.7+Sun/8.8.8) with ESMTP id h3MLn9k26474
	for <freebsd-questions@FreeBSD.org>;
	Tue, 22 Apr 2003 17:49:09 -0400 (EDT)
Message-ID: <3EA5B8CF.7080803@cs.rutgers.edu>
Date: Tue, 22 Apr 2003 17:49:03 -0400
From: Aniruddha Bohra <bohra@cs.rutgers.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-questions@FreeBSD.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Interrupt threads
X-BeenThere: freebsd-questions@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: User questions <freebsd-questions.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-questions>,
	<mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions>
List-Post: <mailto:freebsd-questions@freebsd.org>
List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-questions>,
	<mailto:freebsd-questions-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Apr 2003 21:49:11 -0000

Hello
    Reading the implementation of interrupt handling on i386,
and reading Greg Lehey's Usenix paper on FreeBSD 5.0 SMP
implementation, I understand that interrupt handling is done in
process context. This is needed partly to support sleeping while
handling the interrupt because GIANT needs to be locked and
a sleep is possible there.

    My question is after all subsystems that lock giant are made
INTR_MPSAFE will the implementation go back to non-process
context interrupt handling (as in older versions) ?

    Moreover, will the locking be per-IRQ or there will be a
global IRQ lock for ensuring atomic access to the ISRs ?

    Finally why do we need to create a kernel thread for
each IRQ - why can't one kernel thread handle all the
IRQs ?

    Please cc me as I am not subscribed.

Thanks

Aniruddha