sys/intr: switch to index vars from table size vars

[ehem_freebsd_m5p.com]

Summary

Since all interrupt table implementations use the same index variable to
indicate current table size, use that instead of size variables.

[markj]

This seems reasonable to me overall.

sys/kern/kern_intr.c

1659 ↗

(On Diff #115288)

Shouldn't "MAXCOMLEN+1" be INTRNAME_LEN or so?

1715 ↗

(On Diff #115288)

Before we were iterating over the entire table, now we're iterating up to the last allocated index. Do we still need this check?

[ehem_freebsd_m5p.com]

sys/kern/kern_intr.c

1659 ↗

(On Diff #115288)

Unfortunately, INTRNAME_LEN is INTRNG-only whereas this is shared by the distinct architectural interrupt subsystems. As a result MAXCOM + 1 must be used. This is also why D38116 depends upon D38115 (without D38115 the entry lengths vary by architecture and this doesn't work).

1715 ↗

(On Diff #115288)

I agree, I'll adjust this.

[ehem_freebsd_m5p.com]

Update db_show_intrcnt() rather more than suggested, fully adjust to match how all architectures have been handling intrnames for some time.

Testing identified trouble with watchdog_fire(), do similar work there.

[ehem_freebsd_m5p.com]

sys/kern/kern_intr.c

1659 ↗

(On Diff #115288)

I should add. I could do a second commit (which may or may not work as part of D38116) which moves INTRNAME_LEN from sys/sys/intr.h to sys/sys/interrupt.h and modifies sys/powerpc/powerpc/intr_machdep.c/sys/x86/x86/intr_machdep.c to use that instead of MAXCOMLEN + 1.

If that was done then it would be appropriate to use INTRNAME_LEN instead and I would do so.

[ehem_freebsd_m5p.com]

Update in light of D38116. The impact was interesting to figure out.