Date: Sun, 30 Apr 2023 07:25:07 -0600 From: Warner Losh <imp@bsdimp.com> To: Rene Ladan <rene@freebsd.org> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: Future of 32-bit platforms (including i386) Message-ID: <CANCZdfrJgi9wDzY5mvpch8-bqFqgXDcrnAB6wxOgEqR5ySbv2A@mail.gmail.com> In-Reply-To: <ZE4w9S2sb2Lm1A55@freefall.freebsd.org> References: <aaa3e005-5f72-f422-56b1-932842379e15@FreeBSD.org> <CANCZdfozwP6oKbu3d_LvMu-g_3ddMg5uLQ=KeLp5Xf9HxorZ=A@mail.gmail.com> <20230428071612.16ca02bd@cschubert.com> <ZE4w9S2sb2Lm1A55@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Sun, Apr 30, 2023, 3:12 AM Rene Ladan <rene@freebsd.org> wrote: > 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. > Of course if we decouple the user land from the kernel, we'll have to carefully coordinate that... and that might also be a consideration for how quickly we move in base: the ability to build 32-bit ports with poudriere. Warner 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 > [-- Attachment #2 --] <div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 30, 2023, 3:12 AM Rene Ladan <<a href="mailto:rene@freebsd.org">rene@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Apr 28, 2023 at 07:16:12AM -0700, Cy Schubert wrote:<br> > On Thu, 27 Apr 2023 11:33:15 -0600<br> > Warner Losh <<a href="mailto:imp@bsdimp.com" target="_blank" rel="noreferrer">imp@bsdimp.com</a>> wrote:<br> > <br> > > On Thu, Apr 27, 2023 at 11:20 AM John Baldwin <<a href="mailto:jhb@freebsd.org" target="_blank" rel="noreferrer">jhb@freebsd.org</a>> wrote:<br> > > <br> > > > For 13.0, i386 was demoted from Tier 1 to Tier 2. In the announcement<br> > > > of this for 13.0, the project committed to an update on i386's future<br> > > > around the time of 14.0. The announcement at the time suggested that<br> > > > i386 would be supported less in 14.x than in 13.x.<br> > > > <br> > > <br> > > I like this. "In 14.0, i386 completes its journey to tier 2 status" maybe?<br> > > <br> > > <br> > > > My proposal is that for 14.x we treat i386 like any other Tier 2<br> > > > platform. That is, release images and packages would only be provided<br> > > > on a best-effort basis, and we would not guarantee providing them. I<br> > > > think we should also stop shipping binary updates for the base system<br> > > > (freebsd-update) for 14.x for i386.<br> > > > <br> > > <br> > > So no freebsd-update service for i386 for 14.x, but have it for arm64 and<br> > > amd64?<br> > > That seems reasonable (assuming that arm64 works).<br> > > <br> > > <br> > > > A larger question is what to do about 32-bit platforms moving forward.<br> > > > My proposal for powerpc, i386, and armv[67] is that we say publicly<br> > > > that we anticipate not supporting them in 15. That is, that we may<br> > > > remove them outright from the tree, or we may leave them in the tree,<br> > > > but we do not plan on building packages or release images. Another<br> > > > option to consider for 32-bit platforms perhaps in 15 is to remove<br> > > > kernel support and only retain the ability to build userland. The<br> > > > goal of saying this now-ish (or about the time 14.0 is going to ship)<br> > > > would be to give time for users and developers to respond in the<br> > > > window between 14.0 and 15.0 so we can evaluate those responses as an<br> > > > input into the final decision for 15.<br> > > > <br> > > <br> > > I like this idea. It states intent strongly enough that people aren't<br> > > surprised,<br> > > but weakly enough that people with strong interests can show up. One lesson<br> > > we've learned repeatedly in the past, though, is that we get a lot people<br> > > showing up saying they'll do something, but then doing nothing. The<br> > > threshold<br> > > of doing something will be actually doing it and being an active member of<br> > > the community or providing other material support rather than "Geeze, I'd<br> > > hate to see sparc64 go, so I'll fix a port or two". I'm not sure how you'd<br> > > set<br> > > that expectation, but maybe something like "we'll evaluate the responses and<br> > > the robustness, size and vitality of those communities as input into our<br> > > decision"<br> > > which would set the bar higher, and have something vaguely measureable to<br> > > point at.<br> > > <br> > > Side note: We should stop providing packages and re-built images for armv6<br> > > in 14, even if we don't completely decommission support for it right away.<br> > > That<br> > > might prove to be a good model here as well and give us some good experience<br> > > for how to do that with the other 32-bit platforms for 15.<br> > > <br> > > I generally favor this idea... It's also a natural evolution of what we've<br> > > been saying<br> > > about platforms, eg you need to provide 64-bit atomics and other operations,<br> > > even if they are relatively inefficient because the base system is starting<br> > > to use them.<br> > > <br> > > 32-bit going away is the long term trend, and the long term goal of the<br> > > project.<br> > > What remains in doubt is the timeline to accomplish this. Many 32-bit<br> > > platforms<br> > > still perform decently well, so we should expect to see some usage. But we<br> > > need<br> > > to weigh the size of that usage against the cost of providing it. We've<br> > > seen an increasing<br> > > cost to developers to provide this over the last few years. But as the<br> > > usage drops<br> > > the cost increases because unanticipated breakages become harder to fix as<br> > > they<br> > > are discovered further and further from the breaking point.<br> > <br> > Agreed. This brings us in line with virtually all major Linux<br> > distributions, Oracle Solaris (whatever is left of it), the other major<br> > commercial O/S out there (AIX), and the other major distributions of<br> > BSD (except NetBSD).<br> > <br> > I think we need to nudge the ports team in this direction, sooner than<br> > later, though in my experience, a good percentage of packages fail to<br> > build on i386 anymore here anyway, including all browsers in ports/www.<br> > <br> >From my testing chromium still builds on i386, but that platform needs some<br> more handholding than amd64. So sparc64 and arm4/5 (and base GCC) support<br> will be purged from the ports tree once 12 goes EOL in 2024, removing i386<br> and arm 6/7 should be a similar exercise.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Of course if we decouple the user land from the kernel, we'll have to carefully coordinate that... and that might also be a consideration for how quickly we move in base: the ability to build 32-bit ports with poudriere.</div><div dir="auto"><br></div><div dir="auto">Warner</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> René<br> > > <br> > > Warner<br> > <br> > <br> > <br> > -- <br> > Cheers,<br> > Cy Schubert <<a href="mailto:Cy.Schubert@cschubert.com" target="_blank" rel="noreferrer">Cy.Schubert@cschubert.com</a>><br> > FreeBSD UNIX: <cy@FreeBSD.org> Web: <a href="https://FreeBSD.org" rel="noreferrer noreferrer" target="_blank">https://FreeBSD.org</a><br>; > NTP: <<a href="mailto:cy@nwtime.org" target="_blank" rel="noreferrer">cy@nwtime.org</a>> Web: <a href="https://nwtime.org" rel="noreferrer noreferrer" target="_blank">https://nwtime.org</a><br>; > <br> > e^(i*pi)+1=0<br> </blockquote></div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrJgi9wDzY5mvpch8-bqFqgXDcrnAB6wxOgEqR5ySbv2A>