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.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 45162 Build 42050: arc lint + arc unit
Event Timeline
Comment Actions
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.
| 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 | |
Comment Actions
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).
Comment Actions
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.
Comment Actions
Yep, just suggesting that this could be removed even under a more conservative notion of backwards compatibility.
| 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. | |