From nobody Sat Jun 03 18:29:00 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 4QYT0p2vcRz4ZJ4C for ; Sat, 3 Jun 2023 18:29:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 4QYT0p0JFNz3hsk for ; Sat, 3 Jun 2023 18:29:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5149c51fd5bso4677935a12.0 for ; Sat, 03 Jun 2023 11:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1685816952; x=1688408952; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fKxb1ivA5oLY1exm+agchfy3Man60hdH2oqSoo8NwEs=; b=sSBK9A8PJqhU1oA6bVgBZrFnP01l1JWrB6hl7rWIx4SGBzPJBU8ukYoo9ed+HBWp1H VmLJZGjvrsYTde1mMcmWb2ATc+Bnzq4xHymILfz5d3c01MSwUKdZl0Ob4O7SORzIeIwI YY/St/HgBT6IgvKhcg31l02DGC6Phqy/Rab65AsOruHGC25GAQqumNmLYKDNyCNgrs8o YSKRCSSSlxhSd10zDcuGXFNPEV75uDWTnZDj5gBVgS8slD7+jBz61FBMo0Sk6JtKSXHk uGlGgz2hoE1GJcHR2ihxlueOcjtkW+UBxCvDnezREMT0F+HUFQdBBCZtizvoGoJX/1jp 5A0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685816952; x=1688408952; 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=fKxb1ivA5oLY1exm+agchfy3Man60hdH2oqSoo8NwEs=; b=BPihyk4DlnNObIa0RBijPNSZdT0tTI64gi+HUkj3OlVDDzIUEEKMbra05luaBS+F2g GE+/otsLq1WCWByNNFo82VhsF6xe5oadTc42l962279H8Y5i1b+LX76vnAQ7CroerrNP C2zFeWHeg7Wz5MrszrLjzUqithUtGTJS/nmaFT4yck9EQwlG+WmVHlbbUlCVQJBxNyyc II8XyNhk2+3d6zbE04GzcJ0xeVtZ28kMGYUOea1ppIk9/pYYuIEW4dNPZ/PIiPev+ihk cBe9s2ifJLM25XOyL8wCuw69FgvdrglB7wfkeV5BWeBnU6P0902DUJAFWm6qy5F8AxST kgVQ== X-Gm-Message-State: AC+VfDwcVNxzC7rmXiNZEZk0c0Y4Fre8BN8NWXNnyvxUfSaegDemgTsn Xz1HHLIdJcJ3Ru9yqu8YIJPudyAwbOfaN3OMvMzcYA== X-Google-Smtp-Source: ACHHUZ5Xlqjgrc/9MPttJJBP1R1LIoCQz4qXwGi5SA//wMV/FoFcO7DXOyLd9oEcKBMZWYJGL66yZTWYN709YrVuSGg= X-Received: by 2002:aa7:c64d:0:b0:515:3103:631e with SMTP id z13-20020aa7c64d000000b005153103631emr5117497edr.25.1685816951895; Sat, 03 Jun 2023 11:29:11 -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: <00E63ECC-2E7B-4C9F-9903-A8BD67278C00.ref@yahoo.com> <00E63ECC-2E7B-4C9F-9903-A8BD67278C00@yahoo.com> <3D0FACB4-A356-4FB1-BB10-0232DEBB08C0@yahoo.com> In-Reply-To: <3D0FACB4-A356-4FB1-BB10-0232DEBB08C0@yahoo.com> From: Warner Losh Date: Sat, 3 Jun 2023 12:29:00 -0600 Message-ID: Subject: Re: Future of 32-bit platforms (including i386) To: Mark Millard Cc: Emmanuel Vadot , freebsd-arch Content-Type: multipart/alternative; boundary="000000000000930ae105fd3dd8f8" X-Rspamd-Queue-Id: 4QYT0p0JFNz3hsk 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 --000000000000930ae105fd3dd8f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 3, 2023, 10:44 AM Mark Millard wrote: > > On May 31, 2023, at 10:30, Warner Losh wrote: > > > On Sun, May 28, 2023 at 10:09=E2=80=AFAM Mark Millard wrote: > > Emmanuel Vadot wrote on > > Date: Wed, 24 May 2023 06:35:55 UTC : > > > > > . . . > > > > > > I personnaly see armv7 in "degraded maintainance mode" since 13.0, > > > nothing really intersting was added, no new SoC support even if there > > > was some interesting one that we could support, no new drivers for > > > supported platforms. We even lost TI BeagleBone support because no on= e > > > really have the time to keep support up to date. > > > I still have some little cute boards that I want to use from time to > > > time but the lack of proper porting of new language (like rust and ii= rc > > > go have problems too) is making new software unusable on those boards > > > (you can't even make some "smart speaker" for spotify as all the > > > spotify clients are in rust). > > > IMX6 support is stalled since ian@ passed away and mmel@ isn't very > > > active atm and they were both the most actives developers for armv7 l= ow > > > level code. > > > > One of the things for tier 2 is: > > (from https://docs.freebsd.org/en/articles/committers-guide/#archs > > 21.4. Tier 2 section) > > > > QUOTE > > Collectively, developers are required to provide the following > > to maintain the Tier 2 status of a platform: > > > > =E2=80=A2 Tier 2 architectures must have an active ecosystem of use= rs and > developers. > > END QUOTE > > > > Is there an implication that, even for 14, the "developers" > > part of that for armv7 has dropped off to the point that > > tier 2 would reasonably be in question? > > > > For the 14 branch, armv7 seems to be right on the edge. Some > > bugs do get fixed, but some of the SoCs are so poorly maintained > > that they don't work anymore (for whatever reason). So "degraded > > maintenance mode" is likely apt for 14: it will still work, mostly, but > > many cool new things that people want, both in terms of languages > > and new hardware support will be lacking in some way, shape or > > form. Tier 2 is likely still the best tier to keep it at, imho. > > > > One thing I was unsure of is how much the choice is driven > by things as they are at around releng/14.0 vs. what things > might be expected to be like around, say, releng/14.4 (a > number of years later). It appears that changing tier status > is normally avoided for the likes of 14.[1-4] . > A lot of it is sticking your finger in the air and projecting out 4 years. If nobody is going to be making any fixes and the code doesn't work at that point, we are better off killing it now. For armv7, I still see bug fixes happening, but anticipate that any bad bug that pops up may not het fixed. I see no new hardware support absent some unforeseen resurgence. I suspect when we branch 15, it's 4 years out prospects will be even worse. But I don't know that for sure. Warner =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > --000000000000930ae105fd3dd8f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jun 3, 2023, 10:44 AM Mark Millard <marklmi@yahoo.com> wrote:

On May 31, 2023, at 10:30, Warner Losh <imp@bsdimp.com> wrote:

> On Sun, May 28, 2023 at 10:09=E2=80=AFAM Mark Millard <marklmi@yahoo= .com> wrote:
> Emmanuel Vadot <manu_at_bidouilliste.com> w= rote on
> Date: Wed, 24 May 2023 06:35:55 UTC :
>
> > . . .
> >
> > I personnaly see armv7 in "degraded maintainance mode" = since 13.0,
> > nothing really intersting was added, no new SoC support even if t= here
> > was some interesting one that we could support, no new drivers fo= r
> > supported platforms. We even lost TI BeagleBone support because n= o one
> > really have the time to keep support up to date.
> > I still have some little cute boards that I want to use from time= to
> > time but the lack of proper porting of new language (like rust an= d iirc
> > go have problems too) is making new software unusable on those bo= ards
> > (you can't even make some "smart speaker" for spoti= fy as all the
> > spotify clients are in rust).
> > IMX6 support is stalled since ian@ passed away and mmel@ isn'= t very
> > active atm and they were both the most actives developers for arm= v7 low
> > level code.
>
> One of the things for tier 2 is:
> (from https://docs.freeb= sd.org/en/articles/committers-guide/#archs
> 21.4. Tier 2 section)
>
> QUOTE
> Collectively, developers are required to provide the following
> to maintain the Tier 2 status of a platform:
>
>=C2=A0 =C2=A0 =C2=A0=E2=80=A2 Tier 2 architectures must have an active = ecosystem of users and developers.
> END QUOTE
>
> Is there an implication that, even for 14, the "developers"<= br> > part of that for armv7 has dropped off to the point that
> tier 2 would reasonably be in question?
>
> For the 14 branch, armv7 seems to be right on the edge. Some
> bugs do get fixed, but some of the SoCs are so poorly maintained
> that they don't work anymore (for whatever reason). So "degra= ded
> maintenance mode" is likely apt for 14: it will still work, mostl= y, but
> many cool new things that people want, both in terms of languages
> and new hardware support will be lacking in some way, shape or
> form. Tier 2 is likely still the best tier to keep it at, imho.
>

One thing I was unsure of is how much the choice is driven
by things as they are at around releng/14.0 vs. what things
might be expected to be like around, say, releng/14.4 (a
number of years later). It appears that changing tier status
is normally avoided for the likes of 14.[1-4] .

A lot of it is sticking your= finger in the air and projecting out 4 years. If nobody is going to be mak= ing any fixes and the code doesn't work at that point, we are better of= f killing it now. For armv7, I still see bug fixes happening, but anticipat= e that any bad bug that pops up may not het fixed. I see no new hardware su= pport absent some unforeseen resurgence.=C2=A0

<= /div>
I suspect when we branch 15, it's 4 years out pr= ospects will be even worse. But I don't know that for sure.

Warner

<= /div>
=3D=3D=3D
Mark Millard
marklmi at yahoo.com

--000000000000930ae105fd3dd8f8--