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 ...

[John Baldwin]

On Sunday 16 March 2008 02:52:59 pm 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.

I already have in my tree an amd64/i386-specific sysarch request to bind an 
IRQ to a CPU, but it's sort of a pain to use since we don't expose interrupt 
info to userland very well so the sysadmin can't tell which CPU an IRQ is 
already connected to w/o a verbose dmesg.  The first thing I plan to 
implement is the aforementioned bus_bind_intr(9) for device drivers to use.

I'm not sure what the sysadmin interface will look like.  Probably the ideal 
is to make the UI do what my existing little tool does 'ibind <irq> <cpu>'.  
However, the MI code doesn't actually know anything about IRQ values.  
Probably would need some sort of MD helper routine to that takes the 
requested 'IRQ' value and maps it to an interrupt event.  Also, the code does 
not currently differentiate between a userland (administrative) bind request 
vs. a driver bind request.  My guess is that the administrative requests 
should have precedence over the driver request.  I also think driver requests 
need to fail with EBUSY like they do now if the interrupt is already bound 
whereas administrative requests should maybe fail with EBUSY if the driver 
has bound it unless the sysadmin uses a force option (ibind -f or some such).

-- 
John Baldwin