Date: Mon, 17 Jul 2000 09:53:49 -0600 From: Steve Passe <smp@csn.net> To: Greg Lehey <grog@lemis.com> Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <200007171553.JAA24715@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Mon, 17 Jul 2000 16:30:38 %2B0930." <20000717163038.J26231@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007171553.JAA24715>