Remove 11.x ABI compat for kernel dump ioctls
ClosedPublic
Actions

Authored by mhorne on Apr 14 2022, 5:06 PM.

Details

Reviewers

markj
cem
emaste

Commits

rGd15267582d6e: Remove 11.x ABI compat for kernel dump ioctls
rG9c90bfcd319c: Remove 11.x ABI compat for kernel dump ioctls

Summary

It was marked gone_in(13), so its time has passed. There is no need to
maintain backwards compatibility with old versions of dumpon(8), the
host's (presumably up-to-date) version should be used to configure this.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

mhorne created this revision.Apr 14 2022, 5:06 PM

Herald added subscribers: glebius, melifaro, imp. · View Herald TranscriptApr 14 2022, 5:06 PM

mhorne requested review of this revision.Apr 14 2022, 5:06 PM

Harbormaster completed remote builds in B45162: Diff 104997.Apr 14 2022, 5:06 PM

mhorne added a child revision: D34914: Remove 12.x ABI compat for kernel dump ioctls.Apr 14 2022, 5:06 PM

These definitely can go.
(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.

(4) FreeBSD 11.x is EOL

This revision is now accepted and ready to land.Apr 14 2022, 6:33 PM

emaste added inline comments.Apr 14 2022, 6:36 PM

sys/sys/disk.h
61	I wonder if we should leave a note here that 133 was DIOCSKERNELDUMP_FREEBSD11. I guess we're not going to run out of `'d'` ioctls any time soon and someone can do some archaeology in the future if we need to reuse a number. Oh, and 132 and 134 are also already gone. OK

In D34913#791466, @emaste wrote:

(4) FreeBSD 11.x is EOL

FreeBSD 4.x is too, yet we have have COMPAT_FREEBSD_4 still. I think it's a little more nuanced though... I think it's more relevant that this is a type of interface that we generally only keep stable within a branch and that we discard compatibility for current (and within current).

I agree that the usual compatibility concerns don't really apply here, and it's worth making the dumper configuration code less hairy than it is. Plus, any users will have gotten a nice warning in the dmesg for the past year and a bit.

Yep, just suggesting that this could be removed even under a more conservative notion of backwards compatibility.

mhorne added inline comments.Apr 14 2022, 7:36 PM

sys/sys/disk.h
61	These were my thoughts exactly. Even accidental re-use should not cause a problem assuming there is a `__FreeBSD_version` bump between then and now.