Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations

On Fri, May 10, 2024 at 5:38 PM <henrichhartzer@tuta.io> wrote:

> Hi everyone,
>
> Warner suggested that I run this by the list. In 2018, a bug report was
> made for disabling COMPAT_FREEBSD4/5/6/7/9 (there's no 8). 6 years later, I
> imagine this would be as good of a time as any to do this if there's no
> obvious problems doing so.
>
> Here's the bug report:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231768
>
> And a pull request in the spirit of the original patch:
> https://github.com/freebsd/freebsd-src/pull/1228
>
> I imagine if this sounds like a good idea, it would land in 15.0. Users
> could always recompile kernels with the old ABI functionality as needed. I
> feel like we're all a little curious if anything still uses this, and
> making this kind of change is probably the best way to find out.
>
> In my opinion, if all goes well, it may be wise to remove the old code in
> the next major version. Could do the full list, or just FreeBSD 4 and 5
> compatibility, for instance. Barring notable negative feedback, of course.
>
> There were some concerns about Rust, but it sounds like it uses (or used?)
> FreeBSD 10.X features, which this patch does not remove. On that topic:
> https://github.com/rust-lang/rust/issues/89058
>

I like this idea. I think leaving FreeBSD 10 in for now is good, but maybe
not completely necessary in -current. We can remove it and FreeBSD 11
support when we branch 15.


> Long term, it might be a good idea to enable support for EOL-1, and maybe
> remove code for EOL-2, of course a less aggressive policy is also possible
> (EOL-2 and EOL-3?). Getting out of the single digit FreeBSD versions should
> be a good start, though!
>

So one should be able to update one's system from any supported release.
But there's always stragglers, and sometimes they are stragglers because
there's issues with the latest release. If they can test-boot a new kernel
with their current userland, that would let them test the class of
'hardware broken on upgrade' issues to see if it is safe to update userland
(or as safe as you can make it). So for 15, we'd want 12 support, I'd
think, which is EOL-1. FreeBSD 11 support wouldn't bloat the kernel that
much for EOL-2. I think each compat is on the order of a few tens of k. One
thing that NetBSD does that's nice, though, is have these sorts of things
as loadable modules. That might be a bit tricky to do, but maybe something
we could encourage longer term? Then it wouldn't matter so much... I think
today, though, it would be hard.


> Appreciate any feedback on this and hopefully we can reach some kind of
> consensus on how to proceed in 2024.
>
> Thank you!
>

Thank you for driving this issue.

Warner


> -Henrich
>
>