cvs commit: src/sys/amd64/amd64 intr_machdep.c src/sys/amd64/include intr_machdep.h src/sys/arm/arm intr.c src/sys/i386/i386 intr_machdep.c src/sys/i386/include intr_machdep.h src/sys/ia64/ia64 interrupt.c src/sys/kern kern_intr.c ...

[M. Warner Losh]

In message: <47DD7188.8000109 at freebsd.org>
            Sam Leffler <sam at FreeBSD.org> writes:
: Andrew Gallatin wrote:
: > John Baldwin [jhb at FreeBSD.org] wrote:
: >
: >   
: >>     MI code can currently (ab)use this by doing:
: >>   
: >>           intr_bind(rman_get_start(irq_res), cpu);
: >>   
: >>     however, I plan to add a truly MI interface (probably a bus_bind_intr(9))
: >>     
: >
: > Thank you very much for this!
: >
: > Do you plan to add a generic adminstrative interface to bind
: > interrupts, or may I add a driver specific sysctl to bind mxge's
: > interrupts in mxge?  If you plan to add a generic administrative
: > interface, I think we also need to add a way for drivers to label
: > their interrupts so that an administrator can differentiate between
: > the different MSI-X vectors.
: >   
: 
: Any idea where this should go?  Might be time to grow a tool that grok's 
: the newbus hierarchy and pushes requests to devices.  I've wanted 
: functionality like netbsd has recently added to control power to devices 
: and this would be seem to be similar.  Not sure if we can do something 
: that'd unify programs like atacontrol and camcontrol (or whether this is 
: a good idea).

I've wanted to maek devctl grow this sort of thing for a long time,
but never had time to implement this.  It wouldn't be hard, just a bit
tedious.  Also, there's two types of requests that would need to be
handled.  One is where you tell a device to do something directly.
The other is where you tell its parent to do it to the child (and
maybe do some cleanup afterwards).

Warner