intr/x86: identify IRQ 0 by intsrc instead of vector

[ehem_freebsd_m5p.com]

Summary

The uses of vector in intr_execute_handlers() seem a bit out of place.
Since the intsrc can be checked for whether it is IRQ 0, do that
instead.

[ehem_freebsd_m5p.com]

In case you hadn't guessed from D35386, I'm trying to remove all uses of the interrupt number from the interface aside from intr_register_source() and intr_lookup_source() (those two require it by their very nature). intr_execute_handlers() is trickier than the other uses.

I'm looking at one software PIC-like driver which doesn't really operate on proper IRQs (the Xen event channel) and the interface of intr_execute_handlers() is a bit of a mismatch. I'm now wondering if switching to vlog() would be plausible.

[markj]

This seems ok, but I wonder how we can get rid of this hack altogether. clkintr_pending is only used when the intel 8254 timer is used as the system eventtimer (i.e., sc->period != 0) and timecounter, so it's entirely unused on contemporary hardware.

WRT to vlog(), I don't see any problem with using that here...

[ehem_freebsd_m5p.com]

Yeah I was wondering about that. My goal though is getting rid of references to vector, not getting rid of the hack. Ideally this could be handled in a filter function. Perhaps that approach wasn't used in 2003 (ecee5704ed50) since the situation with filters versus handlers wasn't in a stable state.

[ehem_freebsd_m5p.com]

The value of doing this may simply be to mitigate bugs if someone tries to use an incompletely initialized struct intsrc and mistakenly passes 0. Also during bring-up a driver might use 0 as a placeholder and this could make early bring-up easier. Even though the real issue should be fixed, this still has value.