Re: Future of 32-bit platforms (including i386)

On 2023-08-03 14:57, John Baldwin wrote:
> On 7/27/23 10:49 AM, shurd@FreeBSD.org wrote:
>> On 2023-05-24 01:35, Emmanuel Vadot wrote:
>>> On Tue, 23 May 2023 16:46:51 -0700
>>> John Baldwin <jhb@FreeBSD.org> 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 
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>> 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 developer
>>>> 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 
>>>> release 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 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 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 and iirc
>>> 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 low
>>> level code.
>>>
>>>    So I'm really interested in who wants to keep armv7 and why, is it
>>> just "I'm using my RPI2 and wants to continue using it" ?
>>>
>>>    Cheers,
>>
>> I realize I'm late to the party, but I just posted this:
>> https://reviews.freebsd.org/D41201 which led to me discovering this
>> thread.
>>
>> The reason I did this was because I need to hack up a thing to go
>> between the internet and a 1984 vintage computer with a 111,840bps
>> serial port, and I want to integrate a supercap UPS into the design.
>>
>> Initially, I had thought to just use Linux on the device since it came
>> with it, but for some reason, Linux couldn't receive at 111840 without
>> dropping characters.  The Z80 system in question doesn't have flow
>> control, so rather than fight with Linux, I decided to fight with
>> something I like.  As it happens, FreeBSD has no issue with the serial
>> port.
>>
>> So what's left that I'll need for my project is getting the ADC driver
>> usable (it doesn't look like it's exposed outside of the kernel
>> currently) to monitor/control the supercap UPS hardware.  I grabbed a
>> few of these boards since they're so cheap ($20 each), so I'll likely be
>> using more of them for various things.
>>
>> Doing the same development using NetBSD or OpenBSD would be a bit more
>> painful since I'm running FreeBSD on all my systems, am familiar with
>> building and installing it, and have the source laying around
>> everywhere.
>>
>> I was actually quite surprised that there's packages available, but I'm
>> not sure I would understand what a statement that we may not support
>> them in 15 would actually mean.  armv7 is already Tier 2, which is
>> explicitly not supported by secteam, releng, and ports.  If that just
>> means moving it to Tier 3, that wouldn't bother me much, though I'm not
>> sure how often universe fails because of it due to something that
>> doesn't need to be fixed anyway.  If it means open season on deleting
>> any armv7-specific "stuff" you happen across, it would bother me, and if
>> it means someone taking a couple days to find all the armv7 stuff and
>> removing it, it would feel spiteful.
>>
>> If armv7 is actually causing universe to fail in weird arm-specific ways
>> that actually distract Tier 1 developers with irrelevant minutia, a move
>> to Tier 3 is clearly warranted.  Maybe I just don't understand how much
>> effort is being wasted on the level of support armv7 is currently
>> getting.
>>
>> TL:DR: I want to keep armv7 because you can still do some cool things
>> with it, but I don't insist anyone else do work beyond not breaking
>> universe to keep it running (and if not breaking universe is a problem,
>> I don't even insist on that).
>
> It's not just about make tinderbox, it is also about keeping platforms
> viable.  One big example is that we probably need to start supporting the
> use of rust in the base system in some form in the not too distant
> future, but rust isn't supported on armv7 on FreeBSD (and someone would
> need to do the work to make that happen).  This is already starting to be
> a problem in ports because some 3rd party software (like py-cryptography)
> is requiring rust for modern versions, but we are currently holding that
> port back to cater to armv7.  Platforms have to have enough active
> developers supporting them to remain viable.

Yeah, Rust-in-base would certainly be an excellent reason to drop platforms
without Rust support to Tier 3 at best.

I guess my confusion is simply that I thought that it being Tier 2 was 
already
a public statement 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."