From nobody Thu Aug 3 21:23:46 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 4RH2035SQgz4V1rP for ; Thu, 3 Aug 2023 21:23:47 +0000 (UTC) (envelope-from shurd@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RH2034vZGz3RZf; Thu, 3 Aug 2023 21:23:47 +0000 (UTC) (envelope-from shurd@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691097827; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NmXjI33fRQjgGBoAgZKEMAszSQr/ACeKSw3QsXv9CdQ=; b=v2QziC6M+njh9qj4YObN7vUYrtwdKmWVJKya8MqwiC8IEXOQy7RdYLKxrMrf5/b9hyzIFQ 3Jdl6R8JJhVRpBLPQd3qT1/zcYhjFMM53jd1w2lTxYzqNAwhJJAvZOw5NTxW1ef0O0Vu2v g4x71I+WSkJn22AM3W6dZB8I2pGadmfVo9lj04vL9BYcn1e0l7d33/skdWmn+CEnKlawv8 InlSBbNNsepXX8ghBPA8N0cu8Jj/6hzF096OMwHpKWurBWaRFYz1zLqi9QL4jiSdEYRG+D ySCxYuNt4rKmFHLaCsOlr3DHboPVzQSnOlFKJ+QyBZOn3MYa5GF4KMI+MQdGJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691097827; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NmXjI33fRQjgGBoAgZKEMAszSQr/ACeKSw3QsXv9CdQ=; b=BucewD+ARk9EFxflYNGo18uaqLx1WwDkk1kjg8HMN98ndAYSm0i/HkJrSv06NPDBh5ONnN vOW89C6xmi4xr7awvJ8RVuaANbhu6n09LMAmRmJj95ZVElnyEMJ1u+TcSvaVdt8UyZ8VwF 5GPeTzwivvXTgocpoDSpYaq1tlnw3Iz/XuD1xkFvbCgCMHTQEXQAkO9becTAdhzCPrf0QF xoyl5DXMyg/zqGZz4vf7M8H8aguQ0IAcu1UV9+6HKWIoDVzyXEVj0zZL5FCy+9myHK5EWA JaCNsHAb1zCRpSOQK+l/S6dsH8Z2x0GDUTPg88bHx6ggZseAMqNlyKghBvKGRw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691097827; a=rsa-sha256; cv=none; b=IMke/M1Hi2U/6xB9bwagd9IgSdGEfq0e0VCt8qbdGvug9O4e4bLIg+ZIfQhefxVKLDeQbA zaiNqfSjimTfMkdRUsXKp9dInBVNpfTixaKLagxOh50E8pLF28pzguqdbgIq7YxoJpepfC C2zd/2PiFKctZQlGuTfYwV9ibXJjo5CxXuYppMiXWBLs1AIaeMAHV1WCIJFUx2YiGWhsbV Q1gmy2fTFRqFTK3qkRkDGGnhgkx5w3hAhxe0KxJ7GGG2OF5Y3WuFUKDUT2GxBG5Krcq9J0 nS5v5Z8mjSCpItjG/ioGR5tUIF5eYNJBLa5LUeAf9GD118+tL7oeoXI+/3oYLg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2601:404:d700:2120:ec4:7aff:fec4:ac4a] (unknown [IPv6:2601:404:d700:2120:ec4:7aff:fec4:ac4a]) (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 did not present a certificate) (Authenticated sender: shurd) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RH2032pHPzDYC; Thu, 3 Aug 2023 21:23:47 +0000 (UTC) (envelope-from shurd@FreeBSD.org) Message-ID: <980e0cba-4c44-c799-212f-a8bc4d1e3b81@FreeBSD.org> Date: Thu, 3 Aug 2023 16:23:46 -0500 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: Future of 32-bit platforms (including i386) Content-Language: en-US To: John Baldwin , freebsd-arch@freebsd.org References: <5a08b091-a1a5-1928-18e1-16c3bddb1a7f@FreeBSD.org> <20230524083555.632d968778e2d1c05a04359f@bidouilliste.com> <10aef6b2-8414-dc8e-b6a4-9215bd30c222@FreeBSD.org> From: shurd@FreeBSD.org In-Reply-To: <10aef6b2-8414-dc8e-b6a4-9215bd30c222@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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."