Remove 12.x ABI compat for kernel dump ioctls

[mhorne]

Summary

This code has been marked gone_in(14), so it can now be removed.

MFC after: never

[imp]

This too can be removed...
(1) They aren't part of a long-term standard ABI, but a rather specialized FreeBSD tool and the kernel
(2) they don't need to work in a jail because this ioctl doesn't make sense from jail.
(3) There's no upgrade / failed-upgrade scenarios we need to worry about with this.

There's just barely a scenario to keep these, and it likely isn't worth supporting: If I ran a 12 userland with a 14 kernel, I wouldn't be able to capture panics with this. However, one can selectively copy over a statically linked dumpon(8) to work around this should even that unlikely scenario arise. And I'm not sure how well the other administrative tools would cope anyway, so maybe that's no longer possible...

[mhorne]

In D34914#791369, @imp wrote:

This too can be removed...
(1) They aren't part of a long-term standard ABI, but a rather specialized FreeBSD tool and the kernel
(2) they don't need to work in a jail because this ioctl doesn't make sense from jail.
(3) There's no upgrade / failed-upgrade scenarios we need to worry about with this.

There's just barely a scenario to keep these, and it likely isn't worth supporting: If I ran a 12 userland with a 14 kernel, I wouldn't be able to capture panics with this. However, one can selectively copy over a statically linked dumpon(8) to work around this should even that unlikely scenario arise. And I'm not sure how well the other administrative tools would cope anyway, so maybe that's no longer possible...

Precisely. I assume this is why the gone_in() annotations were added, for all these reasons; the commit message will better reflect this.

You would need at least an updated libkvm if not more in order to read a minidump produced by a 14 kernel, so yeah, I bet one would encounter more glaring issues first with such a setup.