History leaves me clueless about this. fd036deac1695 is simply moves it from one spot in the file to another, rG:ecee5704ed500 doesn't mention it at all. If this is simply lint then perhaps time to remove?

The one plausible alternative would be to leave the intrcnt_setname("???", 0); lines in-place to ensure there is always one nominally valid entry, and would then be overwritten when the first entry was allocated. This really looks like an early placeholder for something during bring-up testing, which was supposed to be removed once tested, but then never got removed.

@jhb any thoughts on D37869? As noted this seems to have mysteriously appeared, I've got no idea why this was here and no idea why it should remain.

Ping D37869? This does appear a remnant of something long forgotten which likely has no effects now. Just hoping for a confirmation and getting this done.

ehem_freebsd_m5p.com mentioned this in D36610: kern/intr: implement intrcnt/intrnames sysctl from event counters.Feb 9 2023, 1:43 AM

Ping D37869. Lack of response really does leave the impression both D37869 and the mystery interrupt entry have been forgotten.

ehem_freebsd_m5p.com abandoned this revision.Dec 13 2024, 3:32 AM

A more recent version of the series is now on Github as #1301. Note that is marked as a draft since something else is higher priority right now.

I suspect this was due to compatibility with something long ago. Perhaps during bring-up it was useful to guarantee the presence of at least one interrupt entry for experimentation. Yet this bring-up bit was never purged. This isn't urgent, just a WTF situation.