From owner-freebsd-arch Mon Jul 17 8:55:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [206.168.13.65]) by hub.freebsd.org (Postfix) with ESMTP id E19BE37BC9A; Mon, 17 Jul 2000 08:54:00 -0700 (PDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.9.3/8.9.3) with ESMTP id JAA24715; Mon, 17 Jul 2000 09:53:50 -0600 (MDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Message-Id: <200007171553.JAA24715@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: Greg Lehey Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process In-reply-to: Your message of "Mon, 17 Jul 2000 16:30:38 +0930." <20000717163038.J26231@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jul 2000 09:53:49 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > I think I now understand how drivers register interrupts with newbus, > and it seems that some tidying up is in order. > ... > About fast interrupts, which currently seem to be used only by the sio > driver: they perform their entire work before reenabling interrupts, > and it's possible that we can keep them like that, though I haven't > looked at the code yet. Does anybody know any reason why we should > convert them to threaded interrupts? Its been quite awhile since I looked at this code, so forgive any inaccuracies on my part... I believe the sio FAST_INTR gets away with "they perform their entire work before reenabling interrupts" because it defers much of the work to the tty soft INTR level. In the ISR itself, it drains the hardware ASAP, then lets the soft INTR process the queues, etc. This method is used to prevent overflowing the sio fifos, which would otherwise occur if the INT were defered till spl() said it could proceed. If the new kernel model allows INTR threads to preempt, I would favor eliminating this sio 'special case', and use high priority for the sio ISR to get the same effect. I am a great fan of ISRs that look something like: sio_intr( struct threadStuff * s ) { ssignal( &(s->intrSem) ); } -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message