From nobody Tue Jul 25 05:10:51 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 4R94qd41vkz4pcsN for ; Tue, 25 Jul 2023 05:10:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 4R94qd1KVHz3lXT for ; Tue, 25 Jul 2023 05:10:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-4fdddf92b05so7431453e87.3 for ; Mon, 24 Jul 2023 22:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1690261851; x=1690866651; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3keEhGvOLgO71wXC9zzk0rmJuCCrlP6mdNWwJmZRbEE=; b=utEp45QgdCvMGbwzb3ghQviANgGZwDcR9cEc8oK5yobRC+MZN8iaaIE9y0z3sKaUUQ QtO8Fj8hKrFI0xpbSw3VONkJNspdoaZvhNoOAHupKbEAeSs6kW+tZ7zCEGQIh9pC2z64 Cfh9Aja+/Oj8fPS73sjOXdJQjKG3ZanUwKQCR27qeEC1RfRsDrIr1yIL3m393+dbptEy bhQoMy5JgeND846bWT7tkqwMl0aBnHnucGmHtKBb4KRCqKxS1mq1l+liKeElezPgQY5O xrJbsdwzTcfNqdyvvwB2Zp/P9AJDPvSfMZMPgCKUYbxhyLx8i/cirvna2ZZA5wrjIzxU bmAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690261851; x=1690866651; 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=3keEhGvOLgO71wXC9zzk0rmJuCCrlP6mdNWwJmZRbEE=; b=Z0DiUZAobK5WL3P3IVNXWPa3fYpQpSv01M7IjwjrGnAgwtQfuqhrXy+IvZ7F7dt7N2 5AJJ5YgXrca7UAQkSdzaQuMSh8avE3wNa6waV9KxBwnW3UHdPxtVPQooZ3E/n61M2YMj /7sYT1JePcWZBd1kL8Uq2LIfnRV+kdDnmcR+JBwWMPDNbBqPNoWt6rTITwBgXuHVgVK1 RFNVuE93JbRVCwmGu/kwXufkCItG1zitYxJo6fZ1Nmc8ZBA/o4NvM4saXqaSrg+PcXXI lT6hTx/APS3M2z0D397ExGw7wIHYdE8A1tuHaG2PALYSJmDu48ngk6EQ5iB+rJYtiN/C BzSg== X-Gm-Message-State: ABy/qLZZB7Ar45TzuX1ZXwQ1N6AqB0GzR6NfFVz373Rv95CemLAqKGwj Q7bdKvFmjui+/CPzdi/8Gspc2+OFC343tC23xs0BkHwkLjEVNZ86NbA= X-Google-Smtp-Source: APBJJlFW7k0qbGnnwuZPJ7EQMHj/TLMdwU6u/UwkhmJI1Mj5oZJPiaRDgNfPASQR2iUBeJYJ/sRpCFoY+xOjBQ+QPu8= X-Received: by 2002:a05:6512:3ca1:b0:4fa:a0c3:efa1 with SMTP id h33-20020a0565123ca100b004faa0c3efa1mr8552196lfv.7.1690261851142; Mon, 24 Jul 2023 22:10:51 -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: In-Reply-To: From: Warner Losh Date: Mon, 24 Jul 2023 23:10:51 -0600 Message-ID: Subject: Re: Future of 32-bit platforms (including i386) To: Mark Millard Cc: John Baldwin , freebsd-arch Content-Type: multipart/alternative; boundary="00000000000037165f060148c1c0" X-Rspamd-Queue-Id: 4R94qd1KVHz3lXT 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 --00000000000037165f060148c1c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 24, 2023 at 2:59=E2=80=AFPM Mark Millard wr= ote: > John Baldwin wrote on > Date: Mon, 24 Jul 2023 19:33:57 UTC : > > > On 5/23/23 4:46 PM, 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 announcemen= t > > >> 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 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. That is, release images and packages would only be provide= d > > >> 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 for > > > 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 can > > > 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've posted a couple of reviews to add a WARNING to dmesg during the bo= ot > > of 32-bit kernels as well as to add a note to RELNOTES to serve as the > > starting point for the note in the release notes: > > > > https://reviews.freebsd.org/D41163 > > https://reviews.freebsd.org/D41164 > > > > Also, Mike Karels has been working on lib32 support for aarch64 that > should > > be included in 14.0. > > I see no wording about armv6 being removed earlier. > > At one time Warner had written: > > >> On Tue, Dec 13, 2022 at 11:48 AM Mark Millard > wrote: > >> FYI: The old 2021-Oct-28 message related to armv6 removal > >> sequencing/timing has a new follow up finally: > >> > >> > https://lists.freebsd.org/archives/freebsd-arch/2022-December/000313.html > >> > >> (Nothing about this changes the armv7 status.) > > > > Nope. > > > > tl;dr: armv6 packages will stop, we'll stop doing -current armv6 > snapshots, we'll move armv6 to > > an 'extra' architecture in universe for stable/14. post stable/14 we'll > tear down support for armv6 > > in base and later in ports. Ports mention armv6 ~500 times, maybe 1/4 o= f > them also mention armv7, > > and the vast majority of them mark things as broken in some way (though > there are exceptions). > > > > Warner > I'm still hoping to get to this... I think it's the last time on my 'wanna get done before 14' checklist. It is orthogonal to the 32-bit stuff. Warner --00000000000037165f060148c1c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 24, 2023 at 2:59=E2=80=AF= PM Mark Millard <marklmi@yahoo.com<= /a>> wrote:
J= ohn Baldwin <jhb_at_FreeBSD.org> wrote on
Date: Mon, 24 Jul 2023 19:33:57 UTC :

> On 5/23/23 4:46 PM, 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 anno= uncement
> >> of this for 13.0, the project committed to an update on i386&= #39;s future
> >> around the time of 14.0. The announcement at the time suggest= ed 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 Tie= r 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 bas= e system
> >> (freebsd-update) for 14.x for i386.
> >>
> >> 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 pu= blicly
> >> that we anticipate not supporting them in 15. That is, that w= e may
> >> remove them outright from the tree, or we may leave them in t= he tree,
> >> but we do not plan on building packages or release images. An= other
> >> option to consider for 32-bit platforms perhaps in 15 is to r= emove
> >> 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 respons= es as an
> >> 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= for
> > 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 deve= loper
> > resources to maintain armv7 kernels for the life of stable/15. We= can
> > largely punt on the final decision for that until close to the re= lease 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've posted a couple of reviews to add a WARNING to dmesg during t= he boot
> of 32-bit kernels as well as to add a note to RELNOTES to serve as the=
> starting point for the note in the release notes:
>
> https://reviews.freebsd.org/D41163
> https://reviews.freebsd.org/D41164
>
> Also, Mike Karels has been working on lib32 support for aarch64 that s= hould
> be included in 14.0.

I see no wording about armv6 being removed earlier.

At one time Warner had written:

>> On Tue, Dec 13, 2022 at 11:48 AM Mark Millard <marklmi@yahoo.com> wrote:
>> FYI: The old 2021-Oct-28 message related to armv6 removal
>> sequencing/timing has a new follow up finally:
>>
>> https://lists.free= bsd.org/archives/freebsd-arch/2022-December/000313.html
>>
>> (Nothing about this changes the armv7 status.)
>
> Nope.
>
> tl;dr: armv6 packages will stop, we'll stop doing -current armv6 s= napshots, we'll move armv6 to
> an 'extra' architecture in universe for stable/14. post stable= /14 we'll tear down support for armv6
> in base and later in ports. Ports mention armv6 ~500 times, maybe 1/4 = of them also mention armv7,
> and the vast majority of them mark things as broken in some way (thoug= h there are exceptions).
>
> Warner

I'm still hoping to get= to this... I think it's the last time on my 'wanna get done before= 14' checklist. It
is orthogonal to the 32-bit stuff.

Warner
--00000000000037165f060148c1c0--