Date: Mon, 17 Jul 2000 16:30:38 +0930 From: Greg Lehey <grog@lemis.com> To: arch@FreeBSD.org, smp@FreeBSD.org Subject: Tidying up the interrupt registration process Message-ID: <20000717163038.J26231@wantadilla.lemis.com>
next in thread | raw e-mail | index | archive | help
I think I now understand how drivers register interrupts with newbus,
and it seems that some tidying up is in order.
Currently the handlers call BUS_SETUP_INTR with flags intr_type
(defined in sys/bus.h):
enum intr_type {
INTR_TYPE_TTY = 1,
INTR_TYPE_BIO = 2,
INTR_TYPE_NET = 4,
INTR_TYPE_CAM = 8,
INTR_TYPE_MISC = 16,
INTR_TYPE_FAST = 128
};
At least in nexus_setup_intr (sys/i386/i386/nexus.c), and possibly
elsewhere as well, these flags get converted into an interrupt mask
and flags for struct intrec, defined in sys/i386/isa/intr_machdep.h:
#define INTR_FAST 0x00000001 /* fast interrupt handler */
#define INTR_EXCL 0x00010000 /* exclusive interrupt */
INTR_EXCL comes from the r_flags field in struct resource
(sys/rman.h), where it is the complement of RF_SHAREABLE:
#define RF_ALLOCATED 0x0001 /* resource has been reserved */
#define RF_ACTIVE 0x0002 /* resource allocation has been activated */
#define RF_SHAREABLE 0x0004 /* resource permits contemporaneous sharing */
#define RF_TIMESHARE 0x0008 /* resource permits time-division sharing */
#define RF_WANTED 0x0010 /* somebody is waiting for this resource */
#define RF_FIRSTSHARE 0x0020 /* first in sharing list */
These flag bits are all lightly used, and there's confusing
duplication of functionality. For example, in nexus_setup_intr we
have:
case (INTR_TYPE_TTY | INTR_TYPE_FAST):
mask = &tty_imask;
icflags |= INTR_FAST;
In sys/pci/pci_compat.c we have
if (intflags & INTR_FAST)
flags |= INTR_TYPE_FAST;
It seems to me that we should define the flags to the *setup_intr
functions to match those in struct intrec. Probably the RF_* flags
are different enough in purpose that we shouldn't do the same thing
there.
In addition, these flags will have to change a lot in the change to
threaded interrupts. First, I intend to add two additional flags to
struct intrec:
#define INTR_HEAVY 0x00000002 /* heavyweight interrupt process */
#define INTR_LIGHT 0x00000004 /* light weight interrupt thread */
#define INTR_THREADED (INTR_LIGHT | INTR_HEAVY) /* any kind of interrupt thread */
This will allow us to let traditional interrupts, lightweight threads
and heavyweight processes to coexist; when the change is complete, we
may be able to let them go away. The INTR_TYPE_TTY and friends are a
different issue; at the moment I don't know if they're enough, but
probably we should replace them with a process priority. I'd be
grateful for any thoughts on these subjects.
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?
Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers
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?20000717163038.J26231>