From nobody Fri May 10 23:38:38 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 4Vblh02Zflz5KfWT for ; Fri, 10 May 2024 23:38:40 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits)) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vblgz3pMWz4t8T for ; Fri, 10 May 2024 23:38:39 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tuta.io header.s=s1 header.b=wWE1Zpw1; dmarc=pass (policy=quarantine) header.from=tuta.io; spf=pass (mx1.freebsd.org: domain of henrichhartzer@tuta.io designates 81.3.6.162 as permitted sender) smtp.mailfrom=henrichhartzer@tuta.io Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w1.tutanota.de (Postfix) with ESMTP id 8C53EFBFB61 for ; Fri, 10 May 2024 23:38:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1715384318; s=s1; d=tuta.io; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=Imoh66QlFiy5Nh2lSMq9XZh7r4kuE76ZxpmKxuakNgk=; b=wWE1Zpw1WM7rAyPL/1Du6Evfq4JTHqFdEum38oqPa7S9uqOeNqVzNHIAXK+TdEEt 9p9JV6re52WPExJlV25FtY4tF79kGAunjhh3nV32kH+ievqsk8Yr7hYwHaFaB5XGOvB c0dm+02wxvRrLWtsZtVIsxu/gEud8QJYXhoHgSkVBknCHIBfryF0lf9VVF5WB03N4cr oyki9vONkUZxytIvp2Pno/ugisJw2c1UOOIV2QDHxS6gVHE7FpnmE/D0LO6uSIn2fOs 0ePCIgI+SihqWrv9xaigOeh8cQ2VlKRZKivGKG4i7GcCn9m3nACnqqclzKWHWrWUmgt J51PkBx52g== Date: Sat, 11 May 2024 01:38:38 +0200 (CEST) From: henrichhartzer@tuta.io To: Freebsd Arch Message-ID: Subject: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.06 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.955]; DMARC_POLICY_ALLOW(-0.50)[tuta.io,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; R_DKIM_ALLOW(-0.20)[tuta.io:s=s1]; RWL_MAILSPIKE_VERYGOOD(-0.20)[81.3.6.162:from]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; FROM_NO_DN(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[tuta.io:+] X-Rspamd-Queue-Id: 4Vblgz3pMWz4t8T 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 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! Appreciate any feedback on this and hopefully we can reach some kind of consensus on how to proceed in 2024. Thank you! -Henrich