From nobody Thu Apr 27 18:18:55 2023 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 4Q6kX73tgBz47lvB for ; Thu, 27 Apr 2023 18:19:03 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "fuz.su", Issuer "fuz.su" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q6kX71GWvz41tW for ; Thu, 27 Apr 2023 18:19:03 +0000 (UTC) (envelope-from fuz@fuz.su) Authentication-Results: mx1.freebsd.org; none Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.16.1/8.16.1) with ESMTPS id 33RIIt0Z042217 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 27 Apr 2023 20:18:55 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.16.1/8.16.1/Submit) id 33RIItP1042216 for freebsd-arch@freebsd.org; Thu, 27 Apr 2023 20:18:55 +0200 (CEST) (envelope-from fuz) Date: Thu, 27 Apr 2023 20:18:55 +0200 From: Robert Clausecker To: "'freebsd-arch'" Subject: Re: Future of 32-bit platforms (including i386) Message-ID: References: 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=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Q6kX71GWvz41tW X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N I would very much appreciate if lib32 support stays in (or is completed in the case of aarch64). Without it, FreeBSD becomes a lot less useful as a well rounded development system as you can no longer test code for 32 bit platforms. I also have a need for armv7 user space code in particular as I participate in and maintain the FreeBSD port of a Forth system written in armv7 assembly. Being able to run the same code you run on a microcontroller on a hosted platform makes it a lot easier to test and develop. As for running 32 bit kernels, I do not really have an opinion. Yours, Robert Clausecker Am Thu, Apr 27, 2023 at 10:19:59AM -0700 schrieb John Baldwin: > For 13.0, i386 was demoted from Tier 1 to Tier 2. In the announcement > of this for 13.0, the project committed to an update on i386's future > around the time of 14.0. The announcement at the time suggested that > i386 would be supported less in 14.x than in 13.x. > > My proposal is that for 14.x we treat i386 like any other Tier 2 > platform. That is, release images and packages would only be provided > on a best-effort basis, and we would not guarantee providing them. I > think we should also stop shipping binary updates for the base system > (freebsd-update) for 14.x for i386. > > A larger question is what to do about 32-bit platforms moving forward. > My proposal for powerpc, i386, and armv[67] is that we say publicly > that we anticipate not supporting them in 15. That is, that we may > remove them outright from the tree, or we may leave them in the tree, > but we do not plan on building packages or release images. Another > option to consider for 32-bit platforms perhaps in 15 is to remove > kernel support and only retain the ability to build userland. The > goal of saying this now-ish (or about the time 14.0 is going to ship) > would be to give time for users and developers to respond in the > window between 14.0 and 15.0 so we can evaluate those responses as an > input into the final decision for 15. > > -- > John Baldwin > -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments