From nobody Fri May 10 23:48:24 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VblvV4j8sz5Kg7Q for ; Fri, 10 May 2024 23:48:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VblvV06zBz4vTj for ; Fri, 10 May 2024 23:48:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a59a387fbc9so672470466b.1 for ; Fri, 10 May 2024 16:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1715384916; x=1715989716; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JsIWRzLF5P573QrPieEDjkAwzm9reTDHjRBJ06VO0hE=; b=SQa474qVDGr1BV2vmK9rB0ITTNm4fckTbuEw9QxINZhcXgjIhd+8G5gRhiplt8i0Ez DixrKjs3Pf3VsWBWaVS00rx6DZLLOD02Pd6PyU5vj7hEOmNZkbVvC/Pq05iX11REXfvY dSjYUrEi8hl+RpGTk+1b0SzAAjEg3mWLYJ9FEV95mRDQ5TCpN+LuakFhkGFr37xwBG1x kweWbqbf1rfyNxvM+2AWuU64MgHyjYllFBjqMaQa6isfn7wa6HzoD3iPu68tEQxPTl/o p4KSoJqycae2gnua90V0vWGt6wtvaegSYr0ospG8xeeTrDQMxmrwO2H10guWTpvle5gg x1uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715384916; x=1715989716; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JsIWRzLF5P573QrPieEDjkAwzm9reTDHjRBJ06VO0hE=; b=IAuFMviTA598Ay5X1GK1g8wFPtCXTq1rlfaXgY19OK8gcBsubT3SskU5yRwg5AGdlj PoLoEMFh4JDedgZRJMt8u+wk+E7K3dDBLtxNaWkppRn2cE4BP7W4DKHhHQsJoxzsIOoB GCLSlpx7UKndBcuE9kVDjUVH9kZj39WUMvdDnyKt8ScihljYKHNRKdorVlGl2y8/ypv4 q5WmeQpOYf+R2k5ljPIIGUMpJIeYWyfnnArlcPLgpKZWuKaGz5fLtcaDLvo6tloHBsEj GiUTv7ZfCJ3S1LTyoZuJxy14Ig2ITb4WlobO5cclBAWULFEsgQphsYXoVrVIfYGbGVf5 hreA== X-Gm-Message-State: AOJu0Yzw1IJv5F+DDG7S6aBtsOGVJkYSmFgzGNhTyP7NBGxTs28OErG4 olnm5HTvHt5AsW1e6gKWzoxtdKkvSafnR5QQwSbQG6hh7fCrM1ywEcEtGmwdeoNNQWifvbxy0LH gyk2d6nvY2NbjQHm73idx4srHQsM00lSuZIeGUZ2yB8xcYeM4 X-Google-Smtp-Source: AGHT+IH1Aswpq1AIgUbS7vSmvBWY5z2QQTpHlXIZvWg6ap/8rdDCC+tdOIv/jrVeUUqe/LE9n0zehv89IAU3aRNblmc= X-Received: by 2002:a17:906:4a42:b0:a59:ae6e:486f with SMTP id a640c23a62f3a-a5a2d68098fmr242322766b.65.1715384916289; Fri, 10 May 2024 16:48:36 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Fri, 10 May 2024 17:48:24 -0600 Message-ID: Subject: Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations To: henrichhartzer@tuta.io Cc: Freebsd Arch Content-Type: multipart/alternative; boundary="00000000000096ce070618222ca7" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4VblvV06zBz4vTj --00000000000096ce070618222ca7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2024 at 5:38=E2=80=AFPM 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


=
On Fri, May 10, 2024 at 5:38=E2=80=AF= PM <henrichhartzer@tuta.io= > wrote:
Hi e= veryone,

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.

Here's the bug report: https://bugs.fr= eebsd.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 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.

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.

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.
=C2=A0
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!

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.
=C2=A0
Appreciate any feedback on this and hopefully we can reach some kind of con= sensus on how to proceed in 2024.

Thank you!

Thank you for driving this i= ssue.

Warner
=C2=A0
-Henrich

--00000000000096ce070618222ca7--