sys: move handling of hw.intrnames/hw.intrcnt to architecture

[ehem_freebsd_m5p.com]

Summary

The tables of interrupt names and counts are a layering violation. Let
architecture code handle these as this form causes trouble for
architecture interrupt implementations.

[ehem_freebsd_m5p.com]

Since I presently have no reviewer for D38454, @mhorne, would you be up for the job. Simply the first step of dealing with the layering issue, temporarily dump everything on architecture.

@imp I figure you should be aware to check. My understanding is the symbol table used by libkvm includes non-global variables, therefore this removes the need for the interrupt table variables to be global. Please advise if this belief is wrong, since that would require an adjustment.

(if this is so, I would move the global declaration to the architecture file to discourage other accesses to the variables)

[mhorne]

As I expressed out-of-band, I do not think the correspondence between you and I on these interrupt reviews has been productive. Out of respect for my own time and energy, and yours, I will withdraw here.

[ehem_freebsd_m5p.com]

Since I'm not getting any other reviews, @mjg up for doing this one too?

Hmm, brought in the wrong person. @kib should know more about libkvm and whether making these static already means rework of vmstat.

[mjg]

So this change copy-pastes the code to 3 places, 2 of which are platform-specific? What's up with the move to subr_intr and why the existing platforms can't just use that code?

If you have a design where the existing code is indeed a problem, you need to demonstrate it as such. At the same time, I don't see any arguments why the new design can't be the standard and thus reside in MI places.

[ehem_freebsd_m5p.com]

All 3 places have roughly the same level of platform specificity. subr_intr.c is INTRNG which is ARM(64)/RISC-V (nominally it could accumulate other arches, but PowerPC and x86 still have their own versions).

If you look at D38448/D36610 most of this ends up MI. For those pieces though this is needed as an intermediate step. I expect there to be further cleanup later. Notably I suspect INTRNG will soon have all the data needed for a better IPI hw.intrnames implementation in subr_intr.c, but that isn't there yet.