Date: Fri, 10 May 2024 17:48:24 -0600 From: Warner Losh <imp@bsdimp.com> To: henrichhartzer@tuta.io Cc: Freebsd Arch <freebsd-arch@freebsd.org> Subject: Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations Message-ID: <CANCZdfrGYJPXsx22Y21=VW7C8c-U7Q6z%2BGPrWx48xNuxjnaCJA@mail.gmail.com> In-Reply-To: <NxZrrMD--3-9@tuta.io> References: <NxZrrMD--3-9@tuta.io>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000096ce070618222ca7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2024 at 5:38=E2=80=AFPM <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=3D231768 > > 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 possibl= e > (EOL-2 and EOL-3?). Getting out of the single digit FreeBSD versions shou= ld > 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 > > --00000000000096ce070618222ca7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Fri, May 10, 2024 at 5:38=E2=80=AF= PM <<a href=3D"mailto:henrichhartzer@tuta.io">henrichhartzer@tuta.io</a>= > wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi e= veryone,<br> <br> Warner suggested that I run this by the list. In 2018, a bug report was mad= e 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.<br> <br> Here's the bug report: <a href=3D"https://bugs.freebsd.org/bugzilla/sho= w_bug.cgi?id=3D231768" rel=3D"noreferrer" target=3D"_blank">https://bugs.fr= eebsd.org/bugzilla/show_bug.cgi?id=3D231768</a><br> <br> And a pull request in the spirit of the original patch: <a href=3D"https://= github.com/freebsd/freebsd-src/pull/1228" rel=3D"noreferrer" target=3D"_bla= nk">https://github.com/freebsd/freebsd-src/pull/1228</a><br>; <br> I imagine if this sounds like a good idea, it would land in 15.0. Users cou= ld always recompile kernels with the old ABI functionality as needed. I fee= l like we're all a little curious if anything still uses this, and maki= ng this kind of change is probably the best way to find out.<br> <br> In my opinion, if all goes well, it may be wise to remove the old code in t= he next major version. Could do the full list, or just FreeBSD 4 and 5 comp= atibility, for instance. Barring notable negative feedback, of course.<br> <br> 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: <a = href=3D"https://github.com/rust-lang/rust/issues/89058" rel=3D"noreferrer" = target=3D"_blank">https://github.com/rust-lang/rust/issues/89058</a><br></b= lockquote><div><br></div><div>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.<br></div><div>=C2=A0</d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord= er-left:1px solid rgb(204,204,204);padding-left:1ex"> Long term, it might be a good idea to enable support for EOL-1, and maybe r= emove 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!<br></blockquote><div><br></div><div>So one should = be able to update one's system from any supported release. But there= 9;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 t= heir 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 a= s safe as you can make it). So for 15, we'd want 12 support, I'd th= ink, 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 thi= ngs as loadable modules. That might be a bit tricky to do, but maybe someth= ing we could encourage longer term? Then it wouldn't matter so much... = I think today, though, it would be hard.<br></div><div>=C2=A0</div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= solid rgb(204,204,204);padding-left:1ex"> Appreciate any feedback on this and hopefully we can reach some kind of con= sensus on how to proceed in 2024.<br> <br> Thank you!<br></blockquote><div><br></div><div>Thank you for driving this i= ssue.</div><div><br></div><div>Warner<br></div><div>=C2=A0</div><blockquote= class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so= lid rgb(204,204,204);padding-left:1ex"> -Henrich<br> <br> </blockquote></div></div> --00000000000096ce070618222ca7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrGYJPXsx22Y21=VW7C8c-U7Q6z%2BGPrWx48xNuxjnaCJA>