BUS_SETUP_INTR(9)

💅 BUS_SETUP_INTR, bus_setup_intr, BUS_TEARDOWN_INTR, bus_teardown_intr — the manual page for creating, attaching and tearing down an interrupt handler ✨

okay bestie, welcome to BUS_SETUP_INTR(9), a page straight out of the Kernel Developer's Manual 💖 this is the group chat where we learn how to make your driver's interrupt handler happen, and then how to make it stop happening, no cap 🫶

---

🌸 NAME 🌸

BUS_SETUP_INTR, bus_setup_intr, BUS_TEARDOWN_INTR, bus_teardown_intr — create, attach and teardown an interrupt handler 👑

---

✨ SYNOPSIS ✨

#include <sys/param.h>
#include <sys/bus.h>

int
BUS_SETUP_INTR(device_t dev, device_t child, struct resource *irq,
    int flags, driver_filter_t *filter, driver_intr_t *ithread,
    void *arg, void **cookiep);

int
bus_setup_intr(device_t dev, struct resource *r, int flags,
    driver_filter_t filter, driver_intr_t ithread, void *arg,
    void **cookiep);

int
BUS_TEARDOWN_INTR(device_t dev, device_t child, struct resource *irq,
    void *cookiep);

int
bus_teardown_intr(device_t dev, struct resource *r, void *cookiep);

---

💖 DESCRIPTION 💖

so the BUS_SETUP_INTR() method is literally the moment you create and attach an interrupt handler to an interrupt that some resource manager already handed out earlier via the BUS_ALLOC_RESOURCE(9) method 🌈 you don't get to just grab an interrupt out of thin air, bestie, it has to be allocated first, iykyk.

the flags live in <sys/bus.h>, and they tell you the broad category of the interrupt. they also spill the tea to the interrupt handlers about certain device driver characteristics 👀:

• INTR_EXCL — marks the handler as being an exclusive handler for this interrupt 🔒
• INTR_MPSAFE — tells the scheduler that the interrupt handler is well behaved in a preemptive environment (that's SMP safe''</purple> babe), and does **not** need to be protected by the <purple>Giant Lock'' mutex 💪
• INTR_ENTROPY — marks the interrupt as being a good source of entropy, and this may be used by the entropy device /dev/random 🎲

now, if you wanna define a time-critical handler that will not execute any potentially blocking operation, use the filter argument 🧚 and go read the “Filter Routines” section below for how to write one. otherwise? use the ithread argument 💫 the handler you define gets called with the value arg as its only argument. and yeah, hit up the “ithread Routines” section below for more on writing an interrupt handler 📖

the cookiep argument is a pointer to a void * that BUS_SETUP_INTR() will write a cookie into for the parent bus' use — but only if it succeeds in establishing an interrupt 🍪 driver writers may assume that this cookie will be non-zero. the nexus driver will write 0 on failure to cookiep 💀

your interrupt handler gets detached by BUS_TEARDOWN_INTR() 🫡 the cookie needs to be passed to BUS_TEARDOWN_INTR() so it tears down the correct interrupt handler, not some random one. and once BUS_TEARDOWN_INTR() returns, it is guaranteed that the interrupt function is not active and will no longer be called ✅ periodt.

⚠️ mutexes are NOT allowed to be held across calls to these functions. not even a little. don't do it 🙈

---

🦋 Filter Routines 🦋

a filter runs in primary interrupt context ⚡ in this context, normal mutexes cannot be used. only the spin lock version of these can be used — and that's specified by passing MTX_SPIN to mtx_init() when initializing the mutex 🌀

what you can call in here:

• wakeup(9) and similar routines 💤
• atomic operations from machine/atomic ⚛️
• reads and writes to hardware through bus_space(9) 🔧
• PCI configuration registers may be read and written 🖥️

everything else in the kernel interface world? cannot be used. nope. nada. 🚫

in this restricted environment, care must be taken to account for all races 😭 a careful analysis of races should be done as well. it is generally cheaper to take an extra interrupt, for example, than to protect variables with spinlocks 💸 read, modify, write cycles of hardware registers need to be carefully analyzed if other threads are accessing the same registers 👁️👁️

generally, a filter routine will use one of two strategies:

1. mask the interrupt in hardware and let the ithread routine read the state from the hardware and then reenable interrupts 🎀 the ithread also acknowledges the interrupt before re-enabling the interrupt source in hardware. most PCI hardware can mask its interrupt source 🌟
2. use a filter with multiple taskqueue(9) tasks 📚 in this case, the filter acknowledges the interrupts and queues the work to the appropriate taskqueue. where one has to multiplex different kinds of interrupt sources — like a network card's transmit and receive paths — this can reduce lock contention and increase performance 🚀

you should not malloc(9) from inside a filter. and you may not call anything that uses a normal mutex. Witness may complain about these. 👀

---

🌈 ithread Routines 🌈

you can do whatever you want in an ithread routine… except sleep 😴 care must be taken not to sleep in an ithread. also, one should minimize lock contention in an ithread routine, because contested locks ripple over to all other ithread routines on that interrupt 🌊

---

😭 Sleeping 😭

sleeping is voluntarily giving up control of your thread 💤 all the sleep routines found in msleep(9) sleep. waiting for a condition variable described in condvar(9) is sleeping. calling any function that does any of these things is sleeping 🛌 so like… if you're in a context where you can't sleep, don't call those. fr fr.

---

🎀 RETURN VALUES 🎀

zero is returned on success ✅ otherwise, an appropriate error is returned 🚨

---

👑 SEE ALSO 👑

random(4), device(9), driver(9), locking(9) 🔗

---

💜 AUTHORS 💜

this manual page was written by Jeroen Ruigrok van der Werven <asmodai@FreeBSD.org> based on the manual pages for BUS_CREATE_INTR() and BUS_CONNECT_INTR() written by Doug Rabson <dfr@FreeBSD.org> 🫶 legends, honestly.

---

and that's the whole page bestie, you ate 💅 this one came from the Debian crew, dated November 3, 2010, and it's filed under BUS_SETUP_INTR(9) — go forth and interrupt responsibly, no cap 🌸✨🦋