From nobody Wed May 24 21:33:10 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 4QRPYw34LRz4V2cJ for ; Wed, 24 May 2023 21:33:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 4QRPYw17X8z3G5t for ; Wed, 24 May 2023 21:33:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-96fa4a6a79bso218499566b.3 for ; Wed, 24 May 2023 14:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1684964001; x=1687556001; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=S8uUtQ9MxspNk80yFwsKzSP34mLo5tyF1+2a7I1EflY=; b=mApDHKGYZKCmsdy8XkyXtgFtGIXLhzc42cEIGpo42tA/+Er11AC7c0OfxWR6yAbin8 6XJ6VPUYAdn6rUr14W4zLwvWNmehcjiKeTGoIfAyYORuKEjupJiu1NLTqYJFh4ysqzsl eaYME9onCi2T3chuNQ/4hJkoljN4ae+e2WkteF/pSSiRKY/uNcRI/pozgjdSRtXrZR+s sJirOJLkDaqqM2NNmbewhbDaoGi53X9FHiEbhu6WaQDqWLYw1QWB6qVZLq8S68+tasgy RcdNWDPJX8EPYSB92b7zPQFe4l6bQN9sa7DnRpFgsDvZxZd8e9OwUehsFNmDFswS+Ci6 CMfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684964001; x=1687556001; 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=S8uUtQ9MxspNk80yFwsKzSP34mLo5tyF1+2a7I1EflY=; b=hO0xFMapHbIgkxxQPlGVhzn09TBn9bfF4/18V04ze3leD5kJsdWQrm5MBVbtDLj1UB Nr1x64JkRJz4Qdh5wDJMouXwC/TOdv8g9RlZlnEDt3V31W41wUMjbqskbTmnljlmLvEr L6ClE9VEQu9TjWPxcliqRNP3X4v4SBBwg/NZnUPuZCKAMJXGMQX9FWJDCF2EsXxo+R06 dl/+FbQvX8aLyqEf1Yd+bKitbsNLmJySlfOPYJwwa/0tzZWVAVKAsiqxn69AjJYzHfcw MobHdU5S4H0/mOzbVux15IfBy1ANaIoqb/kjdgiA5aBKZiCjFouDvCsNBX3TRou/XCKT uj7Q== X-Gm-Message-State: AC+VfDwrod2SK0n9W5QWfmBiicz6CaL8IS6zqtWMTSWXZxJPzWg/fT2t PqHf+KY8djPEhYB8d4Wru/y1Y5DGZALXlRnIZaVigA== X-Google-Smtp-Source: ACHHUZ4AVTnK+BwzrjT43xMkoI99QF4VBgL25GrhOpu8D9qzicMMqWMhE3Hcsih3+YtbN4qirVY7S3Y8QsI38eJjZEw= X-Received: by 2002:a17:907:70a:b0:966:2123:e0c3 with SMTP id xb10-20020a170907070a00b009662123e0c3mr18468529ejb.15.1684964001225; Wed, 24 May 2023 14:33:21 -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: <5a08b091-a1a5-1928-18e1-16c3bddb1a7f@FreeBSD.org> <9ad737e6-cf36-6411-b16e-4c5a191932de@freebsd.org> In-Reply-To: From: Warner Losh Date: Wed, 24 May 2023 15:33:10 -0600 Message-ID: Subject: Re: Future of 32-bit platforms (including i386) To: John Baldwin Cc: Charlie Li , Tomek CEDRO , freebsd-arch Content-Type: multipart/alternative; boundary="000000000000c0b49805fc7740e7" X-Rspamd-Queue-Id: 4QRPYw17X8z3G5t 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 --000000000000c0b49805fc7740e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 24, 2023, 2:42 PM John Baldwin wrote: > On 5/23/23 8:59 PM, Charlie Li wrote: > > Tomek CEDRO wrote: > >> On Wed, May 24, 2023 at 1:47=E2=80=AFAM John Baldwin wrote: > >>> On 4/27/23 10:19 AM, John Baldwin wrote: > >>>> For 13.0, i386 was demoted from Tier 1 to Tier 2. In the announceme= nt > >>>> of this for 13.0, the project committed to an update on i386's futur= e > >>>> around the time of 14.0. The announcement at the time suggested tha= t > >>>> i386 would be supported less in 14.x than in 13.x. > >>>> > >>>> 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 provid= ed > >>>> on a best-effort basis, and we would not guarantee providing them. = I > >>>> think we should also stop shipping binary updates for the base syste= m > >>>> (freebsd-update) for 14.x for i386. > >>>> > >>>> A larger question is what to do about 32-bit platforms moving forwar= d. > >>>> 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 a= n > >>>> input into the final decision for 15. > >>> > >>> We discussed this topic during the 15.0 developer summit and the > consensus > >>> among the folks present (which is only a subset of our community), is > >>> that there is still interest in supporting armv7 kernels in 15.0, but > not > >>> kernels for other platforms. In addition, no one expressed a need fo= r > >>> full 32-bit world support for i386 and powerpc, only for compat32 > support > >>> in the kernel, and lib32 (cc -m32) support in userland. > >>> > >>> One question for this is if we think we will have sufficient develope= r > >>> resources to maintain armv7 kernels for the life of stable/15. We ca= n > >>> largely punt on the final decision for that until close to the releas= e > of > >>> 15.0. I think for what we announce for 14.0 we can still say that we > >>> are generally planning to remove 32-bit kernel and world support in > 15.0, > >>> but may consider keeping armv7. > >> > >> I always think in terms of "Zombie Apocalypse"^TM on what to get > >> myself into.. if its not going to work in that kind of situation then > >> its not worth the time :-) :-) > >> > >> Will "lack of support" mean no binaries provided or removal of the > >> source code so FreeBSD is non-existent anymore on those platforms? > >> > > Both. The actual code would be removed, as there exists a > > not-insignificant cost on development of contemporary platform support > > (needing to keep i386 around significantly hinders amd64 development, > > for instance). > > I'm not sure it's accurate to say that i386 specifically hinders amd64, > it's more that 32-bit platforms in general are more limited and we > already have some features (e.g. KTLS) that only work on 64-bit platforms= . > That is only going to become more true over time. We also have a finite > set of developer resources, and it's best to concentrate those on modern > commodity platforms. > > > I had a much longer passage on this subject that was slated to be > > written and posted here prior to the devsummit, but the tl;dr was > > understood at the devsummit. Basically, the proposed general removal of > > 32-bit support is unfortunate but probably technically necessary. > > Investigations of certain use cases, like Wine, will need to happen to > > see how much 32-bit userland support need to remain whilst running on > > 64-bit kernel. There continue to exist production armv7 boards that > > enjoy long-term support, so removing kernel support would not only be a > > bad idea, but those who need that support the most are the least > > equipped to help on our end (unless some individuals can be nudged to > > learn). > > Just because boards exist and users are interested is not sufficient reas= on > to keep a platform alone. We also have to have sufficient developer > interest to maintain platforms in the tree. What we learned at the summi= t > is there is at least still some desire for 32-bit arm systems. > Maybe we need to put names next to this to retain it? If there is interest it will become clear. Althought most people use hardware to build, i still build my few packages i need with bsd-user. I can keep bsd-user going for armv7 at least for 14.. and although I have 2 armv7 boards in service today, I'd likely replace them with arm64 or riscv boards if they break either due to an update to FreeBSD not working or hardware failure. Warner > --000000000000c0b49805fc7740e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 24, 2023, 2:42 PM John Baldwin <jhb@freebsd.org> wrote:
On 5/23/23 8:59 PM, Charlie Li wrote:
> Tomek CEDRO wrote:
>> On Wed, May 24, 2023 at 1:47=E2=80=AFAM John Baldwin wrote:
>>> On 4/27/23 10:19 AM, John Baldwin wrote:
>>>> For 13.0, i386 was demoted from Tier 1 to Tier 2.=C2=A0 In= the announcement
>>>> of this for 13.0, the project committed to an update on i3= 86's future
>>>> around the time of 14.0.=C2=A0 The announcement at the tim= e suggested that
>>>> i386 would be supported less in 14.x than in 13.x.
>>>>
>>>> My proposal is that for 14.x we treat i386 like any other = Tier 2
>>>> platform.=C2=A0 That is, release images and packages would= only be provided
>>>> on a best-effort basis, and we would not guarantee providi= ng them.=C2=A0 I
>>>> think we should also stop shipping binary updates for the = base system
>>>> (freebsd-update) for 14.x for i386.
>>>>
>>>> A larger question is what to do about 32-bit platforms mov= ing forward.
>>>> My proposal for powerpc, i386, and armv[67] is that we say= publicly
>>>> that we anticipate not supporting them in 15.=C2=A0 That i= s, that we may
>>>> remove them outright from the tree, or we may leave them i= n 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 t= o remove
>>>> kernel support and only retain the ability to build userla= nd.=C2=A0 The
>>>> goal of saying this now-ish (or about the time 14.0 is goi= ng 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 resp= onses as an
>>>> input into the final decision for 15.
>>>
>>> We discussed this topic during the 15.0 developer summit and t= he consensus
>>> among the folks present (which is only a subset of our communi= ty), is
>>> that there is still interest in supporting armv7 kernels in 15= .0, but not
>>> kernels for other platforms.=C2=A0 In addition, no one express= ed a need for
>>> full 32-bit world support for i386 and powerpc, only for compa= t32 support
>>> in the kernel, and lib32 (cc -m32) support in userland.
>>>
>>> One question for this is if we think we will have sufficient d= eveloper
>>> resources to maintain armv7 kernels for the life of stable/15.= =C2=A0 We can
>>> largely punt on the final decision for that until close to the= release of
>>> 15.0.=C2=A0 I think for what we announce for 14.0 we can still= say that we
>>> are generally planning to remove 32-bit kernel and world suppo= rt in 15.0,
>>> but may consider keeping armv7.
>>
>> I always think in terms of "Zombie Apocalypse"^TM on wha= t to get
>> myself into.. if its not going to work in that kind of situation t= hen
>> its not worth the time :-) :-)
>>
>> Will "lack of support" mean no binaries provided or remo= val of the
>> source code so FreeBSD is non-existent anymore on those platforms?=
>>
> Both. The actual code would be removed, as there exists a
> not-insignificant cost on development of contemporary platform support=
> (needing to keep i386 around significantly hinders amd64 development,<= br> > for instance).

I'm not sure it's accurate to say that i386 specifically hinders am= d64,
it's more that 32-bit platforms in general are more limited and we
already have some features (e.g. KTLS) that only work on 64-bit platforms.<= br> That is only going to become more true over time.=C2=A0 We also have a fini= te
set of developer resources, and it's best to concentrate those on moder= n
commodity platforms.

> I had a much longer passage on this subject that was slated to be
> written and posted here prior to the devsummit, but the tl;dr was
> understood at the devsummit. Basically, the proposed general removal o= f
> 32-bit support is unfortunate but probably technically necessary.
> Investigations of certain use cases, like Wine, will need to happen to=
> see how much 32-bit userland support need to remain whilst running on<= br> > 64-bit kernel. There continue to exist production armv7 boards that > enjoy long-term support, so removing kernel support would not only be = a
> bad idea, but those who need that support the most are the least
> equipped to help on our end (unless some individuals can be nudged to<= br> > learn).

Just because boards exist and users are interested is not sufficient reason=
to keep a platform alone.=C2=A0 We also have to have sufficient developer interest to maintain platforms in the tree.=C2=A0 What we learned at the su= mmit
is there is at least still some desire for 32-bit arm systems.

Maybe we need= to put names next to this to retain it? If there is interest it will becom= e clear.

Althought most = people use hardware to build, i still build my few packages i need with bsd= -user. I can keep bsd-user going for armv7 at least for 14.. and although I= have 2 armv7 boards in service today, I'd likely replace them with arm= 64 or riscv boards if they break either due to an update to FreeBSD not wor= king or hardware failure.

Warner
--000000000000c0b49805fc7740e7--