Date: Sun, 30 Apr 2023 09:12:21 +0000 From: Rene Ladan <rene@freebsd.org> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Warner Losh <imp@bsdimp.com>, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: Future of 32-bit platforms (including i386) Message-ID: <ZE4w9S2sb2Lm1A55@freefall.freebsd.org> In-Reply-To: <20230428071612.16ca02bd@cschubert.com> References: <aaa3e005-5f72-f422-56b1-932842379e15@FreeBSD.org> <CANCZdfozwP6oKbu3d_LvMu-g_3ddMg5uLQ=KeLp5Xf9HxorZ=A@mail.gmail.com> <20230428071612.16ca02bd@cschubert.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 28, 2023 at 07:16:12AM -0700, Cy Schubert wrote: > On Thu, 27 Apr 2023 11:33:15 -0600 > Warner Losh <imp@bsdimp.com> wrote: > > > On Thu, Apr 27, 2023 at 11:20 AM John Baldwin <jhb@freebsd.org> 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 <Cy.Schubert@cschubert.com> > FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org > NTP: <cy@nwtime.org> Web: https://nwtime.org > > e^(i*pi)+1=0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZE4w9S2sb2Lm1A55>