Date: Thu, 3 Aug 2023 16:23:46 -0500 From: shurd@FreeBSD.org To: John Baldwin <jhb@FreeBSD.org>, freebsd-arch@freebsd.org Subject: Re: Future of 32-bit platforms (including i386) Message-ID: <980e0cba-4c44-c799-212f-a8bc4d1e3b81@FreeBSD.org> In-Reply-To: <10aef6b2-8414-dc8e-b6a4-9215bd30c222@FreeBSD.org> References: <aaa3e005-5f72-f422-56b1-932842379e15@FreeBSD.org> <5a08b091-a1a5-1928-18e1-16c3bddb1a7f@FreeBSD.org> <20230524083555.632d968778e2d1c05a04359f@bidouilliste.com> <cfaceafd-1230-d6a1-3ca5-3f245acc2c3f@FreeBSD.org> <10aef6b2-8414-dc8e-b6a4-9215bd30c222@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?980e0cba-4c44-c799-212f-a8bc4d1e3b81>