From nobody Sun Apr 30 13:25:07 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 4Q8Rss1TVFz47pL8 for ; Sun, 30 Apr 2023 13:25:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q8Rsr40h9z3CwM for ; Sun, 30 Apr 2023 13:25:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-50bc394919cso600643a12.2 for ; Sun, 30 Apr 2023 06:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682861119; x=1685453119; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Cbb5BDEX5VVXcw+41w9RwQKkfo9LBXRtiCKJxv9nmdo=; b=0YMvoGx1mmQ6VNXvmRfyI/5cAt/AokZPWgEphBcBoF7Ht40/vs84OreEWqP3zLI2Ig pY8IEdgSzaXqp3FCETMLU3BqZzMgZmbwDkhE1NUizXIAaOUss61n9NBLw+sFLA2706nf eWcwf/9bQhfWU5nNh/ObzgrEigTlYymt4t+knD4Zd0edvQeGU7cisCLQupXOxCJWdcg2 f8zdjeDsVxK8bPqT+xOSsFVXPZxqa1rT8fuufbXc0HNsCvLr6iiAWiHG6QDYAITXsU29 DxqgfolIFiatRHBeJlw0YpjSJOS6RRgS/HkEk0Fybs27TlTAAL37FyirD24WEs+XPNkn 4hAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682861119; x=1685453119; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Cbb5BDEX5VVXcw+41w9RwQKkfo9LBXRtiCKJxv9nmdo=; b=K723almbzNCH1dqZBJm5v9zSf5kByCA2TFP+g9LpoOUrgrnajpl2wDT60WryPrerEM CTmJTCfhSjOTyB39ZeBRj9KyGbSf5HZzPE+kXjBWjadjnteZSqkXRA3e66O9PemIhJVn cjIgFJ2q3eYitIlKPTRKk40NOYw1PpoHtGwneC4G9/FsE5DYNxrHldbOxl7Fpks7hC/2 G+oKJWUjDGXZSMhHkQAokDR3u3yya6BHHq12E7UKICvMXOaMowbSrYO/pmEqAd7MQmX5 aIBKjRJsMz8X5oX6J6OwRfZ2xkKGz+2/Ze0PA44KU9we7Hqq1bA/QTCBVWhLcNtyRbS8 wM6w== X-Gm-Message-State: AC+VfDzn8lPKPctYkeSh8gigikfS75UpTAvbkEfZa+euSTfeT+YkL/Qi PmRN2T6cUzszi9Bv8ySlj2xqLDokxjKkPy7UdQeCJw== X-Google-Smtp-Source: ACHHUZ41hhxs5GDJGPN+bjYrG+BwtZosIk5sMyUrkYNlqpKC3U73y0aQuOPvviTRueL0MBpq7FFRIF6utbFwRVH14Yc= X-Received: by 2002:aa7:da5a:0:b0:506:c3c8:59cc with SMTP id w26-20020aa7da5a000000b00506c3c859ccmr3724144eds.27.1682861119014; Sun, 30 Apr 2023 06:25:19 -0700 (PDT) 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 References: <20230428071612.16ca02bd@cschubert.com> In-Reply-To: From: Warner Losh Date: Sun, 30 Apr 2023 07:25:07 -0600 Message-ID: Subject: Re: Future of 32-bit platforms (including i386) To: Rene Ladan Cc: Cy Schubert , freebsd-arch Content-Type: multipart/alternative; boundary="000000000000349f2b05fa8da3c8" X-Rspamd-Queue-Id: 4Q8Rsr40h9z3CwM X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000349f2b05fa8da3c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 30, 2023, 3:12 AM Rene Ladan 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 wrote: > > > > > On Thu, Apr 27, 2023 at 11:20=E2=80=AFAM 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 futu= re > > > > around the time of 14.0. The announcement at the time suggested th= at > > > > 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 syst= em > > > > (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 tre= e, > > > > 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 shi= p) > > > > 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 measureabl= e > 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 t= he > > > 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 th= e > > > 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 so= me > 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 i38= 6 > 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=C3=A9 > > > > > > Warner > > > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: https://FreeBSD.org > > NTP: Web: https://nwtime.org > > > > e^(i*pi)+1=3D0 > --000000000000349f2b05fa8da3c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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 Schu= bert wrote:
> On Thu, 27 Apr 2023 11:33:15 -0600
> Warner Losh <imp@bsdimp.com> wrote:
>
> > On Thu, Apr 27, 2023 at 11:20=E2=80=AFAM John Baldwin <jhb@freebs= d.org> wrote:
> >
> > > For 13.0, i386 was demoted from Tier 1 to Tier 2.=C2=A0 In t= he announcement
> > > of this for 13.0, the project committed to an update on i386= 's future
> > > around the time of 14.0.=C2=A0 The announcement at the time = suggested that
> > > i386 would be supported less in 14.x than in 13.x.
> > >=C2=A0
> >
> > 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 Ti= er 2
> > > platform.=C2=A0 That is, release images and packages would o= nly be provided
> > > on a best-effort basis, and we would not guarantee providing= them.=C2=A0 I
> > > think we should also stop shipping binary updates for the ba= se system
> > > (freebsd-update) for 14.x for i386.
> > >=C2=A0
> >
> > So no freebsd-update service for i386 for 14.x, but have it for a= rm64 and
> > amd64?
> > That seems reasonable (assuming that arm64 works).
> >
> >
> > > A larger question is what to do about 32-bit platforms movin= g forward.
> > > My proposal for powerpc, i386, and armv[67] is that we say p= ublicly
> > > that we anticipate not supporting them in 15.=C2=A0 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.= =C2=A0 Another
> > > option to consider for 32-bit platforms perhaps in 15 is to = remove
> > > kernel support and only retain the ability to build userland= .=C2=A0 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 respon= ses as an
> > > input into the final decision for 15.
> > >=C2=A0
> >
> > I like this idea. It states intent strongly enough that people ar= en'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 nothin= g. 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 &qu= ot;Geeze, I'd
> > hate to see sparc64 go, so I'll fix a port or two". I= 9;m not sure how you'd
> > set
> > that expectation, but maybe something like "we'll evalua= te the responses and
> > the robustness, size and vitality of those communities as input i= nto our
> > decision"
> > which would set the bar higher, and have something vaguely measur= eable 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 i= t 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 i= s 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 usag= e. 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 a= s 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 majo= r
> 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<= br> > 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<= br> 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 th= at might also be a consideration for how quickly we move in base: the abili= ty to build 32-bit ports with poudriere.

<= div dir=3D"auto">Warner

=
Ren=C3=A9
> >
> > Warner
>
>
>
> --
> Cheers,
> Cy Schubert <Cy.Schubert@cschubert.com>
> FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://FreeBSD.org
> NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cy@nwtime.org>=C2= =A0 =C2=A0 Web:=C2=A0 https://nwtime.org
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0e^(i*pi)+1=3D0
--000000000000349f2b05fa8da3c8--