Re: Future of 32-bit platforms (including i386)

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
>