Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

bus_describe_intr(9) [freebsd man page]

BUS_DESCRIBE_INTR(9)					   BSD Kernel Developer's Manual				      BUS_DESCRIBE_INTR(9)

BUS_DESCRIBE_INTR, bus_describe_intr -- associate a description with an active interrupt handler SYNOPSIS
#include <sys/param.h> #include <sys/bus.h> int BUS_BIND_INTR(device_t dev, device_t child, struct resource *irq, void *cookie, const char *descr); int bus_describe_intr(device_t dev, struct resource *irq, void *cookie, const char *fmt, ...); DESCRIPTION
The BUS_DESCRIBE_INTR() method associates a description with an active interrupt handler. The cookie parameter must be the value returned by a successful call to BUS_SETUP_INTR(9) for the interrupt irq. The bus_describe_intr() function is a simple wrapper around BUS_DESCRIBE_INTR(). As a convenience, bus_describe_intr() allows the caller to use printf(9) style formatting to build the description string using fmt. When an interrupt handler is established by BUS_SETUP_INTR(9), the handler is named after the device the handler is established for. This name is then used in various places such as interrupt statistics displayed by systat(1) and vmstat(8). For devices that use a single inter- rupt, the device name is sufficiently unique to identify the interrupt handler. However, for devices that use multiple interrupts it can be useful to distinguish the interrupt handlers. When a description is set for an active interrupt handler, a colon followed by the description is appended to the device name to form the interrupt handler name. RETURN VALUES
Zero is returned on success, otherwise an appropriate error is returned. SEE ALSO
systat(1), vmstat(8), BUS_SETUP_INTR(9), device(9), printf(9) HISTORY
The BUS_DESCRIBE_INTR() method and bus_describe_intr() functions first appeared in FreeBSD 8.1. BUGS
It is not currently possible to remove a description from an active interrupt handler. BSD
October 14, 2009 BSD

Check Out this Related Man Page

BUS_SETUP_INTR(9)					   BSD Kernel Developer's Manual					 BUS_SETUP_INTR(9)

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
The BUS_SETUP_INTR() method will create and attach an interrupt handler to an interrupt previously allocated by the resource manager's BUS_ALLOC_RESOURCE(9) method. The flags are found in <sys/bus.h>, and give the broad category of interrupt. The flags also tell the inter- rupt 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 (``SMP safe''), and does not need to be protected by the ``Giant Lock'' mutex. INTR_ENTROPY marks the interrupt as being a good source of entropy - this may be used by the entropy device /dev/random. To define a time-critical handler (previously known as INTR_FAST) that will not execute any potentially blocking operation, use the filter argument. See the Filter Routines section below for information on writing a filter. Otherwise, use the ithread argument. The defined han- dler will be called with the value arg as its only argument. See the ithread Routines section below for more information on writing an interrupt handler. The cookiep argument is a pointer to a void * that BUS_SETUP_INTR() will write a cookie for the parent bus' use to if it is successful 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. The interrupt handler will be detached by BUS_TEARDOWN_INTR(). The cookie needs to be passed to BUS_TEARDOWN_INTR() in order to tear down the correct interrupt handler. Once BUS_TEARDOWN_INTR() returns, it is guaranteed that the interrupt function is not active and will no longer be called. Mutexes are not allowed to be held across calls to these functions. Filter Routines A filter runs in a context very similar to what was known as an INTR_FAST routine in previous versions of FreeBSD. In this context, normal mutexes cannot be used. Only the spin lock version of these can be used (specified by passing MTX_SPIN to mtx_init() when initializing the mutex). wakeup(9) and similar routines can be called. Atomic operations from machine/atomic may be used. Reads and writes to hardware through bus_space(9) may be used. PCI configuration registers may be read and written. All other kernel interfaces cannot be used. 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 gen- erally 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. The first strategy is to simply mask the interrupt in hardware and allow the ithread routine to 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. The second common approach is to 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 trans- mit and receive paths, this can reduce lock contention and increase performance. You should not malloc(9) from inside a filter. 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. In addition, 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 routine 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. RETURN VALUES
Zero is returned on success, otherwise an appropriate error is returned. SEE ALSO
random(4), device(9), driver(9), mtx_init(9), wakeup(9) AUTHORS
This manual page was written by Jeroen Ruigrok van der Werven <> based on the manual pages for BUS_CREATE_INTR() and BUS_CONNECT_INTR() written by Doug Rabson <>. BSD
December 18, 2007 BSD
Man Page