intr/x86: remove ->pic_vector() from x86 interrupt framework

[ehem_freebsd_m5p.com]

Summary

Retrieving the interrupt number from isrcs via a ->pic_vector() function
made sense when the current x86 interrupt framework was implemented.
Now having ->pic_vector() serves to unnecessarily increase complexity,
rather than adding useful functionality as all callers have the valua
readily available.

[ehem_freebsd_m5p.com]

Taking a look due while considering something else. I'm wondering about the argument order for intr_execute_handlers(). Should the vector argument be last instead of first? The thought is to mimic the argument order of intr_event_handle(). Issue is whether this reduces confusion or increases confusion?

[royger]

sys/x86/include/intr_machdep.h

156

I would add a new field to struct intsrc in order to store the passed vector in intr_register_source(), so that the caller doesn't need to pass it again in intr_execute_handlers().

[ehem_freebsd_m5p.com]

Having considered things in various places I'm no longer so sure of this being a good idea. There is merit, but due to a certain case I could see this being reused for major gain. As such marking this as on hold.

[ehem_freebsd_m5p.com]

Having examined things more, an appropriate place to store the value already exists, but has been underutilized. Mainly isrc->is_event->ie_irq.

I had been pushing trying to remove the interrupt number from intr_event (D32504) since it doesn't work for all architectures. Thing is, it doesn't work for the INTRNG architectures because INTRNG is lazy about allocating the event structure. If INTRNG followed PowerPC and x86, and allocated the event structure during interrupt registration (D40166), I would be in favor of using it for all platforms.

Problem is I'm pretty sure someone (mmel) would be against this since it would conflict with "INTR_SOLO". Issue there is "INTR_SOLO" is stillborn (D35607), yet mmel still wants to keep this future-less blob.

So a decision needs to be made, push the interrupt number towards a common location (D40166) or towards the architecture (D32504). Right now I would tend to favor D40166, but in order to make progress a decision is needed and then potentially pushed over objections.

(note if the D40166 approach wins, then D32504 still has the value of removing the redundant interrupt number lookup)

[ehem_freebsd_m5p.com]

Change the approach and use ->is_event->ie_irq for places besides intr_register_source(). Since D35386 is now a parent, the vector value can disappear from xen_arch_isrc_t. msi_irq can also disappear, but that is more involved.