intr/x86: replace use of vector in interface with intsrc

[ehem_freebsd_m5p.com]

Summary

Several x86 interrupt core functions were already operating on intsrc
structures. Now switch the remaining 4 to intsrc for consistency.

[ehem_freebsd_m5p.com]

Came up as part of guess what. Upon examination it turns out the Xen event channel (interrupt equivalent) code only needs to preserve the interrupt number for calling intr_add_handler() and intr_describe(). Add variants which instead accept the struct intsrc and the Xen code could simply discard the interrupt number.

The one issue is where the isrc == NULL check should be? Should the _intsrc variants be able to deal with being passed NULL sources?

[ehem_freebsd_m5p.com]

I should add, intr_bind() and intr_config_intr() also seem good candidates for this treatment. I though cannot cite any places which would currently benefit from the functionality.

[markj]

In D35386#802255, @ehem_freebsd_m5p.com wrote:

Came up as part of guess what. Upon examination it turns out the Xen event channel (interrupt equivalent) code only needs to preserve the interrupt number for calling intr_add_handler() and intr_describe(). Add variants which instead accept the struct intsrc and the Xen code could simply discard the interrupt number.

Given that the amount of churn involved looks to be minimal, and since some of the public functions here already operate on intsrcs, I would suggest simply changing the existing functions to take an intsrc, and then handle lookups in nexus. intr_lookup_source() is already used extensively in consumers.

The one issue is where the isrc == NULL check should be? Should the _intsrc variants be able to deal with being passed NULL sources?

Existing intr_* functions which take an intsrc do not perform such a check, so I would not attempt to handle NULL in the new variants either.

[ehem_freebsd_m5p.com]

Updating per @markj's comment. I'm unsure whether any portions of the nexus code can assume the interrupt number is valid and skip the == NULL check.

[markj]

Looks reasonable to me.

[ehem_freebsd_m5p.com]

Available in a form handy to git at https://gitlab.com/ehem/freebsd-src.git branches "D35386" and "D35406". I suspect I'll be asking @royger to push fairly soon though.

[ehem_freebsd_m5p.com]

Due to D36901 getting in first, intr_bind() has disappeared and the portion of D35386 adjusting the interface disappears.

I'm awfully tempted to switch the order of intr_add_handler()'s first two arguments to make the interface more consistent. This also moves x86 closer to INTRNG (the opposite could be done, but I feel INTRNG got this one right).

No activity since I don't have a commit bit of my own.

[ehem_freebsd_m5p.com]

Due to D36901 getting in first, intr_bind() disappeared. As threatened, I really like intr_add_handler()'s first two arguments being in the opposite order. Not only does this seem more consistent with the rest of the interface, but this also matches INTRNG (the domain argument is now the only difference).

[ehem_freebsd_m5p.com]

Update to better reflect current state of FreeBSD tree. My repository had several patches, one of which had modified intr_describe(). As such this better reflects current state.