From nobody Sun Apr 30 09:12:21 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 4Q8LFx2nc7z46Y0m for ; Sun, 30 Apr 2023 09:12:21 +0000 (UTC) (envelope-from rene@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q8LFx2DSkz40Sv; Sun, 30 Apr 2023 09:12:21 +0000 (UTC) (envelope-from rene@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682845941; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zMR89dN8oPxJPRIuAgoJyiQ/qKx28Wc1VpW4y98h5dI=; b=HaygFjZ0y9cyxzWkDMgmVAAKdBrVU3wq3TKl5kDxrsZMH8awDdkSH7fOb54aXlr7XGKyiG +vZnzgY60FsAG+TqM4IDlthmEGioWYWwLmukf0zQkMeV/UoQROVJV/Brq8up/2jUddeNwU 5iegWftL3jvZcy/ZvkNwH5HIFiyiPbV1SV6sl8Ecb6OdQ4tCn3sq3/JGwcnyUOcOkIyo0X g9gR04Bfd/xev5YL4NRSZlA6CGI7vgMdJBPNuXNTvQySQGDPdDAD+GJ6AMGi0lMbUZmp4s Y3xDr75jveHeupPQpBsVUZYvl9a/xWlXJluAdzy0zbyk7i4jdb3uAVzyCALdng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682845941; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zMR89dN8oPxJPRIuAgoJyiQ/qKx28Wc1VpW4y98h5dI=; b=Dx18aC625kkhXBwd6vVohr3+a8pHsqZBttjjl65XvVRQcrmXqPAJdgmDeP1fkhTvBLNivR BGr3YEVxZ1olwcp4GieofAA3hVNCfuu0w4OHRoolfCFv+pFnWkrQa4tI40tlN2TOCRI+r3 BDR8B3nZVd6hzRNChFZLDwTzZNGR8tdHcPQmLxLrTLU+zjjxRthjjdYLw0XE4+a5Q/GxbF SvXUv+yUuvJraXSJZpUdtFZT92CVNBwuouZtZSIAHuwkAlo8sG5jv4l0AmTOZP7aQUdxIW 8cKue0csfQ3xsoNjL5J2X4y2wcardbUHxuIoXafMXmSr/XdgLxjJEl9DvLSgNg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682845941; a=rsa-sha256; cv=none; b=G3YfmJefacIbfSUphTFg/oCnuXCBkD4L3Xg54C4taO3JcuVIOUGODp/uKL329mX2wBDSbw UzvBk8b6PtqimFySwSKmvbH1YfqfmaZyKZxjMNxdaN9ZfSy53IrFoEev8QcjyxDqex0B1U djpxsFv0cqOQWtJEPtrh6oNigfWmfLOSHYB+cgdkaFlSFajnQ4+NYKbORdDIp9be5YOXF1 z0G8F2X+jNYH2Q3M3J5IYdp4Pyca82Doi5Wtto5rvR9FLbPaiKKY0SVz4GTAJkoB6SV2iY STFcKPIr9pPBRvnkN/lJrEOltGqpHhpeW8z2BOHy9HEPkziyGzvpFCRncqEqTQ== Received: by freefall.freebsd.org (Postfix, from userid 1185) id 3B3A26107; Sun, 30 Apr 2023 09:12:21 +0000 (UTC) Date: Sun, 30 Apr 2023 09:12:21 +0000 From: Rene Ladan To: Cy Schubert Cc: Warner Losh , freebsd-arch Subject: Re: Future of 32-bit platforms (including i386) Message-ID: References: <20230428071612.16ca02bd@cschubert.com> 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230428071612.16ca02bd@cschubert.com> X-ThisMailContainsUnwantedMimeParts: N On Fri, Apr 28, 2023 at 07:16:12AM -0700, Cy Schubert wrote: > On Thu, 27 Apr 2023 11:33:15 -0600 > Warner Losh wrote: > > > On Thu, Apr 27, 2023 at 11:20 AM John Baldwin wrote: > > > > > 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. > > > > > > > I like this. "In 14.0, i386 completes its journey to tier 2 status" maybe? > > > > > > > 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. > > > > > > > So no freebsd-update service for i386 for 14.x, but have it for arm64 and > > amd64? > > That seems reasonable (assuming that arm64 works). > > > > > > > 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. > > > > > > > I like this idea. It states intent strongly enough that people aren't > > surprised, > > but weakly enough that people with strong interests can show up. One lesson > > we've learned repeatedly in the past, though, is that we get a lot people > > showing up saying they'll do something, but then doing nothing. The > > threshold > > of doing something will be actually doing it and being an active member of > > the community or providing other material support rather than "Geeze, I'd > > hate to see sparc64 go, so I'll fix a port or two". I'm not sure how you'd > > set > > that expectation, but maybe something like "we'll evaluate the responses and > > the robustness, size and vitality of those communities as input into our > > decision" > > which would set the bar higher, and have something vaguely measureable to > > point at. > > > > Side note: We should stop providing packages and re-built images for armv6 > > in 14, even if we don't completely decommission support for it right away. > > That > > might prove to be a good model here as well and give us some good experience > > for how to do that with the other 32-bit platforms for 15. > > > > I generally favor this idea... It's also a natural evolution of what we've > > been saying > > about platforms, eg you need to provide 64-bit atomics and other operations, > > even if they are relatively inefficient because the base system is starting > > to use them. > > > > 32-bit going away is the long term trend, and the long term goal of the > > project. > > What remains in doubt is the timeline to accomplish this. Many 32-bit > > platforms > > still perform decently well, so we should expect to see some usage. But we > > need > > to weigh the size of that usage against the cost of providing it. We've > > seen an increasing > > cost to developers to provide this over the last few years. But as the > > usage drops > > the cost increases because unanticipated breakages become harder to fix as > > they > > are discovered further and further from the breaking point. > > Agreed. This brings us in line with virtually all major Linux > distributions, Oracle Solaris (whatever is left of it), the other major > commercial O/S out there (AIX), and the other major distributions of > BSD (except NetBSD). > > I think we need to nudge the ports team in this direction, sooner than > later, though in my experience, a good percentage of packages fail to > build on i386 anymore here anyway, including all browsers in ports/www. > From my testing chromium still builds on i386, but that platform needs some more handholding than amd64. So sparc64 and arm4/5 (and base GCC) support will be purged from the ports tree once 12 goes EOL in 2024, removing i386 and arm 6/7 should be a similar exercise. René > > > > Warner > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=0