While I agree on the counter I am not yet sure I entirely want to lose all these messages.
Some are helpful in that they tell us things. If you are on multiple network as most of my devices are it can become a pain otherwise to retroactively debug.
Given none of them are logged by default (nd6_debug = 0 unless -DND6_DEBUG is used at compile time and nd6.h:#define nd6log(x) do { if (V_nd6_debug) log x; } while (/*CONSTCOND*/ 0) ) can we not just do both?

On the other hand I've had one of them (maybe not in this list) on my screens for months which were entirely unhelpful:
"RA with a lower CurHopLimit sent from fe80:... on em0 (current = 255, received = 64). Ignored."
It's been unhelpful as (a) I had to figure out how to reset it, and (b) I had no idea where the original limit change came from anymore.
So I wished that was a ndlog rather than a direct log() call.

In D26578#592011, @bz wrote:

While I agree on the counter I am not yet sure I entirely want to lose all these messages.
Some are helpful in that they tell us things. If you are on multiple network as most of my devices are it can become a pain otherwise to retroactively debug.
Given none of them are logged by default (nd6_debug = 0 unless -DND6_DEBUG is used at compile time and nd6.h:#define nd6log(x) do { if (V_nd6_debug) log x; } while (/*CONSTCOND*/ 0) ) can we not just do both?

Certainly we can, I forgot that nd6log() is disabled by default. In this case though I am skeptical that the messages are really useful - if hlim != 255 then presumably something is forwarding ND6 packets and so is quite broken. I can't find any reports of this on mailing lists for forums. It made sense to have verbose logging during earlier days of ND6, but it doesn't seem particularly useful anymore. The extra buffers also waste stack space, at least in principle - maybe the compiler is clever enough to avoid that.

If you prefer to keep these particular log messages I'll re-add them. Otherwise as I add other counters we can consider whether it makes sense to keep various log messages. Errors that might arise as a result of misconfiguration seem worth logging.

On the other hand I've had one of them (maybe not in this list) on my screens for months which were entirely unhelpful:
"RA with a lower CurHopLimit sent from fe80:... on em0 (current = 255, received = 64). Ignored."
It's been unhelpful as (a) I had to figure out how to reset it, and (b) I had no idea where the original limit change came from anymore.
So I wished that was a ndlog rather than a direct log() call.

In D26578#592014, @markj wrote:

The extra buffers also waste stack space, at least in principle - maybe the compiler is clever enough to avoid that.

In some modified functions the stack usage appears identical, in others it decreased by 16 bytes, so stack usage is not a compelling reason to remove the nd6log() calls.

While I'm all up for more statistic counter, I'd suggest keeping nd6log calls. They're turned off by default, but useful for debugging.

In D26578#592282, @melifaro wrote:

While I'm all up for more statistic counter, I'd suggest keeping nd6log calls. They're turned off by default, but useful for debugging.

Ok, I will re-add them.

Any objection to committing the patch as it is? While having a backwards-compatible solution here would be nice, I don't think it should block the addition of new counters. As I pointed out, the ABI for icmpv6 stats is already broken with respect to stable/12.

To followup on the discussion: I raised D27035, which introduces a generic mechanism to solve such issues. It also unbreaks FreeBSD12 compat for net.inet6.icmp6.stats.