Date: Thu, 27 Apr 2023 11:33:15 -0600 From: Warner Losh <imp@bsdimp.com> To: freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: Future of 32-bit platforms (including i386) Message-ID: <CANCZdfozwP6oKbu3d_LvMu-g_3ddMg5uLQ=KeLp5Xf9HxorZ=A@mail.gmail.com> In-Reply-To: <aaa3e005-5f72-f422-56b1-932842379e15@FreeBSD.org> References: <aaa3e005-5f72-f422-56b1-932842379e15@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000ffeede05fa54c03c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 27, 2023 at 11:20=E2=80=AFAM John Baldwin <jhb@freebsd.org> wro= te: > 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 an= d 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 experienc= e 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. Warner --000000000000ffeede05fa54c03c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Thu, Apr 27, 2023 at 11:20=E2=80= =AFAM John Baldwin <<a href=3D"mailto:jhb@freebsd.org">jhb@freebsd.org</= a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p= x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Fo= r 13.0, i386 was demoted from Tier 1 to Tier 2.=C2=A0 In the announcement<b= r> of this for 13.0, the project committed to an update on i386's future<b= r> around the time of 14.0.=C2=A0 The announcement at the time suggested that<= br> i386 would be supported less in 14.x than in 13.x.<br></blockquote><div><br= ></div><div>I like this. "In 14.0, i386 completes its journey to tier = 2 status" maybe?<br></div><div>=C2=A0</div><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex"> My proposal is that for 14.x we treat i386 like any other Tier 2<br> platform.=C2=A0 That is, release images and packages would only be provided= <br> on a best-effort basis, and we would not guarantee providing them.=C2=A0 I<= br> think we should also stop shipping binary updates for the base system<br> (freebsd-update) for 14.x for i386.<br></blockquote><div><br></div><div>So = no freebsd-update service for i386 for 14.x, but have it for arm64 and amd6= 4?</div><div>That seems reasonable (assuming that arm64 works).<br></div><d= iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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.=C2=A0 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.=C2=A0 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.=C2=A0 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></blockquote><div><br></div><div>I= like this idea. It states intent strongly enough that people aren't su= rprised,</div><div>but weakly enough that people with strong interests can = show up. One lesson</div><div>we've learned repeatedly in the past, tho= ugh, is that we get a lot people</div><div>showing up saying they'll do= something, but then doing nothing. The threshold</div><div>of doing someth= ing will be actually doing it and being an active member of</div><div>the c= ommunity or providing other material support rather than "Geeze, I'= ;d</div><div>hate to see sparc64 go, so I'll fix a port or two". I= 'm not sure how you'd set</div><div>that expectation, but maybe som= ething like "we'll evaluate the responses and</div><div>the robust= ness, size and vitality of those communities as input into our decision&quo= t;</div><div>which would set the bar higher, and have something vaguely mea= sureable to</div><div>point at.</div><div><br></div><div>Side note: We shou= ld stop providing packages and re-built images for armv6</div><div>in 14, e= ven if we don't completely decommission support for it right away. That= </div><div>might prove to be a good model here as well and give us some goo= d experience</div><div>for how to do that with the other 32-bit platforms f= or 15. <br></div><div><br></div><div>I generally favor this idea... It'= s also a natural evolution of what we've been saying</div><div>about pl= atforms, eg you need to provide 64-bit atomics and other operations,</div><= div>even if they are relatively inefficient because the base system is star= ting to use them.</div><div><br></div><div>32-bit going away is the long te= rm trend, and the long term goal of the project.</div><div>What remains in = doubt is the timeline to accomplish this. Many 32-bit platforms</div><div>s= till perform decently well, so we should expect to see some usage. But we n= eed</div><div>to weigh the size of that usage against the cost of providing= it. We've seen an increasing</div><div>cost to developers to provide t= his over the last few years. But as the usage drops</div><div>the cost incr= eases because unanticipated breakages become harder to fix as they</div><di= v>are discovered further and further from the breaking point.<br></div><div= ><br></div><div>Warner<br></div></div></div> --000000000000ffeede05fa54c03c--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfozwP6oKbu3d_LvMu-g_3ddMg5uLQ=KeLp5Xf9HxorZ=A>