From nobody Sun Apr 23 16:49:10 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 4Q4DkP3bHxz4690D for ; Sun, 23 Apr 2023 16:49:17 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4DkN1q1jz4M4l for ; Sun, 23 Apr 2023 16:49:16 +0000 (UTC) (envelope-from gnn@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 2001:4b98:dc4:8::225 is neither permitted nor denied by domain of gnn@freebsd.org) smtp.mailfrom=gnn@freebsd.org; dmarc=none Received: (Authenticated sender: gnn@neville-neil.com) by mail.gandi.net (Postfix) with ESMTPSA id F10591C0003 for ; Sun, 23 Apr 2023 16:49:13 +0000 (UTC) From: George Neville-Neil To: Arch Subject: Has there been any work or thought put into Heterogeneous Memory Management? Date: Sun, 23 Apr 2023 09:49:10 -0700 X-Mailer: MailMate (1.14r5937) Message-ID: <49ECC9C7-7BC1-4C55-B595-FDF68DE34F96@freebsd.org> 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 Content-Type: text/plain; markup=markdown X-Spamd-Result: default: False [-0.58 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; NEURAL_HAM_SHORT(-0.96)[-0.962]; NEURAL_SPAM_LONG(0.58)[0.575]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::225:from]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:29169, ipnet:2001:4b98::/32, country:FR]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[gnn]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; ARC_NA(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Rspamd-Queue-Id: 4Q4DkN1q1jz4M4l X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N Howdy, A project I'm working with is looking at this feature of Linux: https://www.kernel.org/doc/html/v5.0/vm/hmm.html Has anyone on the project put any thought into a similar system for FreeBSD? Best, George From nobody Mon Apr 24 14:33:39 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 4Q4ngS6Zlpz46v0v for ; Mon, 24 Apr 2023 14:33:40 +0000 (UTC) (envelope-from vishwin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4Q4ngS5mMQz3nlv; Mon, 24 Apr 2023 14:33:40 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682346820; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ou2/F0+3c7QDiXxceUYI42AemPCTNruMOCnq4Bb/9Fw=; b=CMh192LDVbWr5UhwTXOTb6hPf9NGYs2ugYDw6wVpTP0OjqSp06HJZPl5MEPfoBJqRhWwE4 5fjn3Xr85ClzQzt7aZ9TH8nzQWlZvhsfS7e0Wy2ivZKWBiESWkQ48w0FYdDbfpX9fi0W6t BarsqmzFyLP58KsdLM6JdIpOIirfyjvh6vrtFYAEbKAq65WaeFL8nHDqO2Qjcm+cL0r7/L hdRRvQ+384SVd4gDcPjJvwk+ssZF80mBH0jXz3Vvzs6YZgPa1rV+ymW+0nR05VYCJoih6U x7veKdkcnYc+jDM9Q//qQN27wuY2yWsbysWa8ygF5RxqlBrTHO4u7//sTEk/AA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682346820; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ou2/F0+3c7QDiXxceUYI42AemPCTNruMOCnq4Bb/9Fw=; b=IcgE4guJYCyNrCgTt2ZxR/6mmOmxC/zdmBujNUTpSMBEe/AR0qevUsUZqn6akm6StR5Z0X 0EYbzk2TyPw/v42i5LUFqGtGywnfRCj8J4T5kdR4P/3bnesV08kYCQayfnUitITH/ymmim TJywFUy05/gV5hKd204qtMzdmc2LuDZaQSiZz4hqecWajO81R8+Z9xwy5sMMYrklAPIsSu lvoX273+6SSrVG31zkLgBth08CP1asFw/x78MLDrBIjBJQ3c8th7rLOPBDok65j62G8r3H d77AU3qkjH3HlACZgjj72+cNDnRveEYwd6x1nn62BhJlTh+dk7Qy6qCKdBpeiw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682346820; a=rsa-sha256; cv=none; b=iSXeJdtlARLQb2BwO5ZaaTgkokMU6wEWsZKcddYXXWj/J79XzC8maGWDzjTBHdlmFUfCyF VhmgzDDwAKYqYksynDThuTUKYKSmLBe1kfyeT4w9mpaU2TTGH8rgHQDpA+1spFf6eSLuUv AaEEfCZCJU+l1Bc0TU1IyX9aSl+5zEe1XdzukKG1ADY+grGak70Ims+aQDnBh/WAJtQAP/ zv3zEC5w4aNhrKdGmnRZM631mWSda2CdwcXNibxHh2eO9CBSdJkDn0svinEi5aDCeBgsC4 PCAymXyQv+ujcConivjAl1aTcACnW2VPapwVlHEiooHOCyBe+gzosNxMFvLLYg== Received: from [IPV6:2601:98a:602:da0:56ee:75ff:fe50:69b5] (unknown [IPv6:2601:98a:602:da0:56ee:75ff:fe50:69b5]) (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: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q4ngS3gVzzg6l; Mon, 24 Apr 2023 14:33:40 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> Date: Mon, 24 Apr 2023 10:33:39 -0400 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.10.1 To: Ed Maste , Joerg Pulz Cc: freebsd-arch References: Content-Language: en-GB From: Charlie Li Organization: FreeBSD Project Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------STXvGQVWQqGN5kJcDfIq0eoJ" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------STXvGQVWQqGN5kJcDfIq0eoJ Content-Type: multipart/mixed; boundary="------------N82ZoLbuKcskP55LW0X5dayu"; protected-headers="v1" From: Charlie Li To: Ed Maste , Joerg Pulz Cc: freebsd-arch Message-ID: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 References: In-Reply-To: --------------N82ZoLbuKcskP55LW0X5dayu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 RWQgTWFzdGUgd3JvdGU6DQo+IFRoZSBwcm9ibGVtIGlzIHRoYXQgd2UgaGF2ZSBjb25mbGlj dGluZyBjb25zdHJhaW50czogT3BlblNTTCAxLjEuMSBpcw0KPiBFT0wgc2hvcnRseSBhZnRl ciAxNC4wIHJlbGVhc2VzLCBhbmQgdGhlcmUgYXJlIHBvcnRzIHRoYXQgZG8gbm90IHlldA0K PiBidWlsZCBhZ2FpbnN0IE9wZW5TU0wgMy4gSSBhbSBub3Qgc3VyZSBob3cgbXVjaCB3aWxs IGJlIGJyb2tlbiBpZiB3ZQ0KPiB1cGRhdGUgdGhlIGJhc2Ugc3lzdGVtIHRvIE9wZW5TU0wg MyBidXQgbGVhdmUgdGhlIHByaXZhdGVsaWIgYXNpZGUNCj4gKGkuZS4sIGhhdmUgdGhlIGJh c2Ugc3lzdGVtIHByb3ZpZGUgT3BlblNTTCAzIHRvIHBvcnRzKS4NCj4gDQpPcGVuU1NMIDMg aXMgYSBtYWpvciwgZXZlbiBsYXJnZXIgdGhhbiAxLjEsIEFQSS9BQkkgY2hhbmdlLiBRdWl0 ZSBhIGJpdCANCm9mIHN0dWZmIHdpbGwgYmUgYnJva2VuIHRvZGF5LiBUaGUgZWZmb3J0IGhl cmUgaGFzIHRvIGluY2x1ZGUgd29ya2luZyANCndpdGggYXMgbWFueSBwb3J0IHVwc3RyZWFt cyBhcyBwb3NzaWJsZSB0byBmb3JjZSB0aGUgaXNzdWUsIGFzIHRoZXkgbWF5IA0Kbm90IGhv bGQgT3BlblNTTCAzIGNvbXBhdGliaWxpdHkgdG8gYmUgYW4gaW1tZWRpYXRlIHByaW9yaXR5 OyBwYXRjaGluZyANCnBvcnRzIG9uIGEgbGFyZ2Ugc2NhbGUgbGlrZSB0aGlzIGlzIG5vdCBz dXN0YWluYWJsZS4NCg0KLS0gDQpDaGFybGllIExpDQrigKZub3BlLCBzdGlsbCBkb24ndCBo YXZlIGFuIGV4aXQgbGluZS4NCg0K --------------N82ZoLbuKcskP55LW0X5dayu-- --------------STXvGQVWQqGN5kJcDfIq0eoJ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmRGk0MFAwAAAAAACgkQ/reFK+KbPocZ Cg//RyqsIXaUJOtxO7Tnx9Rn4LtA5IpBM3UWk+hTCIFtx+7jUj/+dVVOkrUNr2vlr4ueaPShevme 7ckUFgz5JloUHg3PWsP0M/L3AgNRV61Dklg1EZEPv/CTk0pyxAWdYukPkLecuLn9L4ATvPiAH78W 0lV11JqpmXf6fHKBJ3WvgPUT+NFiM97ciGV18VBWonLAJD34Ibya7/gCWpb+YhQr2voFs7XnkN9z hJy8tIZU6u0ITyNZWMK5SUlx9+m09SPYbiX7MPqW5KjWAByBE/3BTpk2TLc3hYW+KlisW3TlGdIv x9flhOA2k/xILqykL1vbwRT3SX/c1A+3uktCKZpSZf1/TUSGCecUsLMghOAQNiw73Ig8tSApbOsY Hd5359ABjTwEM2Av5dgDote5Zu8oIrS7snBI5/3XKlMB4M5/wRSzski/ZumqHZ0WBOEcanU53DUW sTWg/Z54SppAHh18wzYoe516hMSktz8sRQhfqapG2WQqAE8/oy2+zApRAsCzY1sqCHHgce6BDwka /vVf/vIaz1LmaeF5HIj/1OZghMA0qhrzFfNy35XD+oOtXz9hi9/r73ArRqpY2dtZzUmKinOkcZcC BHTEnaxwaIlSRy83NM9z1ZGgntDpiynjz8SFGr6f+B7X0NmKcylVREKkxbwsLVYC5egOnQ80Q8QE VS4= =LjEw -----END PGP SIGNATURE----- --------------STXvGQVWQqGN5kJcDfIq0eoJ-- From nobody Mon Apr 24 14:39:12 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 4Q4np73rP9z46vhv for ; Mon, 24 Apr 2023 14:39:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (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 4Q4np721Lhz3nrR for ; Mon, 24 Apr 2023 14:39:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-xa2e.google.com with SMTP id 71dfb90a1353d-44048c2de31so2827451e0c.0 for ; Mon, 24 Apr 2023 07:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682347165; x=1684939165; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=akqKJ3XnswWzxoN/mF7TCXfR1B6bzy20R/Jexb2VpZk=; b=0u68qK6KKS2XEBcIB8rmtW+u6oS9XqybgKXnu6zTzialgvi/Om3LtGV4WzTRsPedDI nOKvw221uUlI3ygsLtLbFNOFdQ/xqBb8+PbzoXwPmgpTzKXdga6QDgRxzNuOE0LR9poo sqhpkdNjahWKT7tJDCzahuKlO9qYovSQn27kk9lbPgiEuQizGjgu3fRaTIqkC4dCddu/ LHCfqZhPvvlIYmkXUqh2ksxtQOGIIcD7tqtXxHpZUndR3kZxxJCSCQnAE7tFXxtKIx6B eVNMZysNCLJ+j+Oh1Jtp6U8705to+IT3P2HhEKHmwkOu/Gq1buvfkrhSa11kDg8syTi6 YxHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682347165; x=1684939165; 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=akqKJ3XnswWzxoN/mF7TCXfR1B6bzy20R/Jexb2VpZk=; b=e1WMSzOhn6G+QNkeg5Rt9aleXxy8QDsS0MzOeQ2ZxkEXy+hJuZsiNNb5GB6c5j3xR1 BBUerQqpAJaazM+xCkXgRnp7ybLeAFM8C+7v8CKUJWjTkPL5Rsotl0m8FBIdkPOwOKBq L8Bv5kYtBvKs1TmQd6kL3Ffn7ecrCP3ecJkvIbbp1Iteuwy9WbE/X0hs0kPl49VWE+36 rQUPphVfOsL6B4jxdvBL9WWQyv9IOu/wT7tcLkEwHVL1YIYyethNR+yyOqz+tR+IK1Ow D33JqOgWRjcIrqcQpYRU1YgpNHl5CixarzhAcAcDJOLVYGxe3oMLarrd7pEGEXE+mI4o ePjA== X-Gm-Message-State: AAQBX9dknx0PRLY4SqPDOdUCljpDv/oAISn++PpMpDL90OpCsx4Svqkr jNC6Fgc3zo0AGCxfEdsJjJhnjhB2x+EvppQRnLzQxw== X-Google-Smtp-Source: AKy350YOKM3E3s+dFdMO+tpdeVxtUJj7Vi17BdbA36CXtA0ylogs/0gBEOdZ0Nhv6eHHQr2+Mily4DWgwNPJ4fTNfyg= X-Received: by 2002:a1f:5ed0:0:b0:440:6152:fb75 with SMTP id s199-20020a1f5ed0000000b004406152fb75mr4394513vkb.13.1682347165473; Mon, 24 Apr 2023 07:39:25 -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: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> In-Reply-To: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> From: Warner Losh Date: Mon, 24 Apr 2023 08:39:12 -0600 Message-ID: Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 To: Charlie Li Cc: Ed Maste , Joerg Pulz , freebsd-arch Content-Type: multipart/alternative; boundary="0000000000002ff4f505fa15f951" X-Rspamd-Queue-Id: 4Q4np721Lhz3nrR X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000002ff4f505fa15f951 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 24, 2023, 8:33 AM Charlie Li wrote: > Ed Maste wrote: > > The problem is that we have conflicting constraints: OpenSSL 1.1.1 is > > EOL shortly after 14.0 releases, and there are ports that do not yet > > build against OpenSSL 3. I am not sure how much will be broken if we > > update the base system to OpenSSL 3 but leave the privatelib aside > > (i.e., have the base system provide OpenSSL 3 to ports). > > > OpenSSL 3 is a major, even larger than 1.1, API/ABI change. Quite a bit > of stuff will be broken today. The effort here has to include working > with as many port upstreams as possible to force the issue, as they may > not hold OpenSSL 3 compatibility to be an immediate priority; patching > ports on a large scale like this is not sustainable. > So why can't ports like this use 1.1 as a port rather than from base? Warner --=20 > Charlie Li > =E2=80=A6nope, still don't have an exit line. > > --0000000000002ff4f505fa15f951 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 24, 2023, 8:33 AM Charlie Li <vishwin@freebsd.org> wrote:
Ed Maste wrote:
> The problem is that we have conflicting constraints: OpenSSL 1.1.1 is<= br> > EOL shortly after 14.0 releases, and there are ports that do not yet > build against OpenSSL 3. I am not sure how much will be broken if we > update the base system to OpenSSL 3 but leave the privatelib aside
> (i.e., have the base system provide OpenSSL 3 to ports).
>
OpenSSL 3 is a major, even larger than 1.1, API/ABI change. Quite a bit of stuff will be broken today. The effort here has to include working
with as many port upstreams as possible to force the issue, as they may not hold OpenSSL 3 compatibility to be an immediate priority; patching
ports on a large scale like this is not sustainable.
=

So why can't ports = like this use 1.1 as a port rather than from base?
<= br>
Warner

--
Charlie Li
=E2=80=A6nope, still don't have an exit line.

--0000000000002ff4f505fa15f951-- From nobody Mon Apr 24 14:49:43 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 4Q4p2T3sKsz46wQN for ; Mon, 24 Apr 2023 14:50:09 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4Q4p2T3HLGz3qSp; Mon, 24 Apr 2023 14:50:09 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682347809; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tcTEwzrrWB4P+Mmv4PkgbZWLAjcreBun0h/1Z/My4fk=; b=COimbT2Q4C1h2VWEguskl8aryvm3QP/2mI/5LfnEmp4gY/FtRNpu13yT9JmM9Kj1wG9jgQ hIktYpXlLfLPwiZ+FwpLn9/5ClDbnRy3PbwzgDHon6LxTdKlmkalm7BXAn2TKu9CBgcW+Y 8sinLgfghYCCbarxfNgMsX1fDBpI402ts4+jXr371rmPz6o8vublh1bQO/qpxw04BDd7bi DTCCoTPOCYMNVLGXrVcGLHGcs/aq8L1pXG5Tc++9eMNAi7FTVjqYuAhZB+k3uqlFAua9p5 8MVJnJovfeAda9TDuBUluyid6itqI9GQeT/UqmP7qzXlVMchk1e0KhsBiPtCBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682347809; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tcTEwzrrWB4P+Mmv4PkgbZWLAjcreBun0h/1Z/My4fk=; b=RBnVmdtzgWQSv8o+XZgfcuyo+H1+FM6XyKWh1kqa4hz1+MRu8UYZ410+7WmKVn91OboVMv O5JMGAGAkunyj0xQJbBgN/V5gScYRUgsVNlTcm5tFEwXHonC/kw/RS5oFB5CJNPNVkUfe2 Hbn+uFfiKUZhL0DJL+CRLjPZ6+N8GxGancMtwrVff9wLoDmqk+8lvSB3u3fFSLBMIOJCnn 8ZyxhvvdnQcJHWZXoythcplIhi4baofkRaWPNUt47xCcu6SbL7ohhRZh5lLTR03k4oB/Bk 2+KrWHtCuzouqoSJZETuPnBnaTlbqm5M4P4GDh9Q/k0e5ePO5XgvE+KOH9nCkA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682347809; a=rsa-sha256; cv=none; b=IrBKwbXBAlbxPRrpa9pzjNU9qgcoLpknjHUtaMprx5l1oT0lgF1ISI0kfAQkJ3h8+qn+ge aiAhXZYuB/7W5iuVTbvbd4DeFsoe74fn3qfZHsK13wszUMmFQWLOAOag+xWege51rjVrw4 Z5mYMPjNO1Ds7Hztx/FtVZqpfrUvlYzGSMQhl65TwgNz9s3OXu98kT7DJIHnSC9N5Tx0bp HrlvW38YMuuaSnGIVrruAgljCV9mrzcvK17luXAZIqyTukiQb33UTQNqXpDAmCbm49qQrt CISd8faSk5pE0QEQanECvegSeeax9t4ks0lqJERaGth6e7gA/b8wUC5qJnF34A== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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 (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q4p2T1cjdzgT8; Mon, 24 Apr 2023 14:50:09 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 961D634FF0; Mon, 24 Apr 2023 16:50:07 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_28A2C80C-3CFA-46F5-9F0C-28D749B9F214"; protocol="application/pgp-signature"; micalg=pgp-sha1 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 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 From: Dimitry Andric In-Reply-To: Date: Mon, 24 Apr 2023 16:49:43 +0200 Cc: Charlie Li , Ed Maste , Joerg Pulz , freebsd-arch Message-Id: References: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> To: Warner Losh X-Mailer: Apple Mail (2.3731.500.231) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_28A2C80C-3CFA-46F5-9F0C-28D749B9F214 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 24 Apr 2023, at 16:39, Warner Losh wrote: > > On Mon, Apr 24, 2023, 8:33 AM Charlie Li wrote: > Ed Maste wrote: > > The problem is that we have conflicting constraints: OpenSSL 1.1.1 is > > EOL shortly after 14.0 releases, and there are ports that do not yet > > build against OpenSSL 3. I am not sure how much will be broken if we > > update the base system to OpenSSL 3 but leave the privatelib aside > > (i.e., have the base system provide OpenSSL 3 to ports). > > > OpenSSL 3 is a major, even larger than 1.1, API/ABI change. Quite a bit > of stuff will be broken today. The effort here has to include working > with as many port upstreams as possible to force the issue, as they may > not hold OpenSSL 3 compatibility to be an immediate priority; patching > ports on a large scale like this is not sustainable. > > So why can't ports like this use 1.1 as a port rather than from base? Trouble starts when you attempt to mix openssl 1.1 and 3.0 libraries (both dynamic and static!) in dependent ports, because symbol names will collide. This is not an easily solvable problem, apart from the fact that an openssl 1.1 port would have the same basic issue that openssl 1.1 in the base system has: it will no longer be supported (at least without paying up) after $CUTOFF_DATE. The rest of the open source world has exactly the same problem of course, so either all abandoned openssl-1.x using programs have to be completely ditched, or you have to keep openssl-1.x on life support somehow. Guess what will happen. :) I think it is likely that this will be a repeat of the Python 2.x debacle, e.g. against better judgement everybody will just keep on using the deprecated version for years, and it may never fade out completely... -Dimitry --Apple-Mail=_28A2C80C-3CFA-46F5-9F0C-28D749B9F214 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCZEaXBwAKCRCwXqMKLiCW oxQ1AJ9U6zTPM4/wbvC6PB/5BioVtXLEhwCeIIy/oQbAp+QxMSkN/D2JXxKBfLs= =5xzF -----END PGP SIGNATURE----- --Apple-Mail=_28A2C80C-3CFA-46F5-9F0C-28D749B9F214-- From nobody Mon Apr 24 15:37:55 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 4Q4q5b6q22z47061 for ; Mon, 24 Apr 2023 15:37:55 +0000 (UTC) (envelope-from vishwin@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 4Q4q5b6G7Rz3vwh; Mon, 24 Apr 2023 15:37:55 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682350675; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=t0w1b9UnvuvIpHanZ0CRwJ5/lpqNt/elxJYp+2ZTaQ8=; b=GgvX+wAOcfRWEc8TGLZgWD+Xlv9xxM3qZKGZJul3v2oza5Txf6VyQ+RdROfiBYNpmtov7c fNoI2pOoAsq0Ey9xQC2XYkEI28vyzBLh7E1zL4XrddmAhy+gw4cAThF9cdUZvDP5M8g2ah 0peCKKJAAGNu1UflYXjn4c8xQyyCKgt/Tq53FEaQc63JhBk7ng44+Lxq8aN/BRGfQSRFxM d7fPj38olXPpJtVU7W1HxkzD1+UVmjbu5ZhdOgT9swx7M0J/AgxRsErzVF5ktgshPiy3Il KkACKkaOB3F8ouZ0MGtN7mBA8sYPN30swKmPkdC7pUmDS152M7NM5aTQYAhQmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682350675; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=t0w1b9UnvuvIpHanZ0CRwJ5/lpqNt/elxJYp+2ZTaQ8=; b=xc7XYrZUYbIYZdKtP15Uct052riZVicRFBBQ34r0f+v8Lz5zXXuHrH5p/xxMHTdQe+Ccqb LLdoOuY/BHAgLiA1e/Kk4EwSCRgIKUsJqu9C8S9jmTNSY8U9J6gvdfS73JVlOGdA/Mjw/N aebwYYCGaLQ041A35yufmzgJazGOpM4qCptx9r4XTZkm9P5SQJC3yYn8RIziM/7ZEwSxt0 PvaSZPH8I4tBT8BSNzOtr0xPSWOtvQCYV6GijAVebM5dy1LBLDgazvzR6WpUsfPc0TVVYx lcXKIjMkdcQbUA6hlOwlrvtiq6uyQu466fxQfOIqbt7MrTVL45aMwZ/AinFEMw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682350675; a=rsa-sha256; cv=none; b=MjX9t0PhmRIRAVj1dLAtkwH6uy1VPwMBYiHrJoLxnpCgJ4SdljSuR9oC3wSj6Q3MVaA0fh uSkJ24HfwCa7yorq/EdD+4Qmg/CgLMCqr2QSYqiiGwsAB9R+3hbajf3+fyJHgDhPtin847 uwtNZGxiMmzirLK0o9udD2j0XMvXIItgPpiMUm0kMprTnl7aKw1a2Of4GZt9S17jTxJkeI sx/RNE6ObGbusomjhYm6K0JBkTlDV8HoVwF43jCwuAymnndkk+1iN49o5K/K+ORx0BJSIW I+2d7Zw5eh0EQoOsMuYMdm1UwN1wy7KQI1QNWEYnFf2sBh2ny/+EmSGm03v2oA== Received: from [IPV6:2601:98a:602:da0:56ee:75ff:fe50:69b5] (unknown [IPv6:2601:98a:602:da0:56ee:75ff:fe50:69b5]) (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: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q4q5b3gZgzhVJ; Mon, 24 Apr 2023 15:37:55 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: <0d9dbf90-2592-c7b0-e27e-8b2d6ad836ba@freebsd.org> Date: Mon, 24 Apr 2023 11:37:55 -0400 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.10.1 Content-Language: en-GB To: Dimitry Andric , Warner Losh Cc: Ed Maste , Joerg Pulz , freebsd-arch References: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> From: Charlie Li Organization: FreeBSD Project Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------OX20apOUrGY4Q0mo6txRuWEG" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------OX20apOUrGY4Q0mo6txRuWEG Content-Type: multipart/mixed; boundary="------------hvv36PVvA4Q0Ch0YE65a90Xu"; protected-headers="v1" From: Charlie Li To: Dimitry Andric , Warner Losh Cc: Ed Maste , Joerg Pulz , freebsd-arch Message-ID: <0d9dbf90-2592-c7b0-e27e-8b2d6ad836ba@freebsd.org> Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 References: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> In-Reply-To: --------------hvv36PVvA4Q0Ch0YE65a90Xu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 RGltaXRyeSBBbmRyaWMgd3JvdGU6DQo+IE9uIDI0IEFwciAyMDIzLCBhdCAxNjozOSwgV2Fy bmVyIExvc2ggd3JvdGU6DQo+Pg0KPj4gT24gTW9uLCBBcHIgMjQsIDIwMjMsIDg6MzMgQU0g Q2hhcmxpZSBMaSB3cm90ZToNCj4+IE9wZW5TU0wgMyBpcyBhIG1ham9yLCBldmVuIGxhcmdl ciB0aGFuIDEuMSwgQVBJL0FCSSBjaGFuZ2UuIFF1aXRlIGEgYml0DQo+PiBvZiBzdHVmZiB3 aWxsIGJlIGJyb2tlbiB0b2RheS4gVGhlIGVmZm9ydCBoZXJlIGhhcyB0byBpbmNsdWRlIHdv cmtpbmcNCj4+IHdpdGggYXMgbWFueSBwb3J0IHVwc3RyZWFtcyBhcyBwb3NzaWJsZSB0byBm b3JjZSB0aGUgaXNzdWUsIGFzIHRoZXkgbWF5DQo+PiBub3QgaG9sZCBPcGVuU1NMIDMgY29t cGF0aWJpbGl0eSB0byBiZSBhbiBpbW1lZGlhdGUgcHJpb3JpdHk7IHBhdGNoaW5nDQo+PiBw b3J0cyBvbiBhIGxhcmdlIHNjYWxlIGxpa2UgdGhpcyBpcyBub3Qgc3VzdGFpbmFibGUuDQo+ Pg0KPj4gU28gd2h5IGNhbid0IHBvcnRzIGxpa2UgdGhpcyB1c2UgMS4xIGFzIGEgcG9ydCBy YXRoZXIgdGhhbiBmcm9tIGJhc2U/DQpGb3IgQVBJIGNvbXBhdGliaWxpdHksIHlvdSBtaWdo dCBhcyB3ZWxsIHVzZSBwb3J0cyBMaWJyZVNTTCBhcyB0aGUgDQpmYWxsYmFjay4gRnJvbSBk aXJlY3QgZXhwZXJpZW5jZSBoZWxwaW5nIHZhcmlvdXMgT3BlblNTTC10eXBlIGNvbnN1bWVy cyANCm1haW50YWluIExpYnJlU1NMIHN1cHBvcnQsIHByZXR0eSBtdWNoIGV2ZXJ5IGlzc3Vl IHN0ZW1tZWQgZnJvbSB0d28gDQpjYXVzZXM6IE9wZW5TU0wgaW1wbGVtZW50aW5nICpuZXcq IGZlYXR1cmVzIHRoYXQgTGlicmVTU0wgd2FzIG5vdCB5ZXQgDQpyZWFkeSBmb3IsIG9yIExp YnJlU1NMIGludGVudGlvbmFsbHkgbm90IGltcGxlbWVudGluZyBjZXJ0YWluIGZlYXR1cmVz IA0KZHVlIHRvIGdvdmVybm1lbnRhbCBleHBvcnQgY29udHJvbCBsYXdzIGFuZCByZWd1bGF0 aW9ucy4NCj4gDQo+IFRyb3VibGUgc3RhcnRzIHdoZW4geW91IGF0dGVtcHQgdG8gbWl4IG9w ZW5zc2wgMS4xIGFuZCAzLjAgbGlicmFyaWVzDQo+IChib3RoIGR5bmFtaWMgYW5kIHN0YXRp YyEpIGluIGRlcGVuZGVudCBwb3J0cywgYmVjYXVzZSBzeW1ib2wgbmFtZXMgd2lsbA0KPiBj b2xsaWRlLg0KPiANCkV4YWN0bHkuIFRoaXMgYWxzbyBhcHBsaWVzIHRvIExpYnJlU1NMLg0K PiBUaGlzIGlzIG5vdCBhbiBlYXNpbHkgc29sdmFibGUgcHJvYmxlbSwgYXBhcnQgZnJvbSB0 aGUgZmFjdCB0aGF0IGFuDQo+IG9wZW5zc2wgMS4xIHBvcnQgd291bGQgaGF2ZSB0aGUgc2Ft ZSBiYXNpYyBpc3N1ZSB0aGF0IG9wZW5zc2wgMS4xIGluIHRoZQ0KPiBiYXNlIHN5c3RlbSBo YXM6IGl0IHdpbGwgbm8gbG9uZ2VyIGJlIHN1cHBvcnRlZCAoYXQgbGVhc3Qgd2l0aG91dCBw YXlpbmcNCj4gdXApIGFmdGVyICRDVVRPRkZfREFURS4NCj4gDQpBbmQgSSBleHBlY3QgdGhl IE9wZW5TU0wgMS4xIHBvcnQgdG8gYmUgcmVtb3ZlZCBhcm91bmQgdGhhdCB0aW1lLg0KPiBU aGUgcmVzdCBvZiB0aGUgb3BlbiBzb3VyY2Ugd29ybGQgaGFzIGV4YWN0bHkgdGhlIHNhbWUg cHJvYmxlbSBvZg0KPiBjb3Vyc2UsIHNvIGVpdGhlciBhbGwgYWJhbmRvbmVkIG9wZW5zc2wt MS54IHVzaW5nIHByb2dyYW1zIGhhdmUgdG8gYmUNCj4gY29tcGxldGVseSBkaXRjaGVkLCBv ciB5b3UgaGF2ZSB0byBrZWVwIG9wZW5zc2wtMS54IG9uIGxpZmUgc3VwcG9ydA0KPiBzb21l aG93LiBHdWVzcyB3aGF0IHdpbGwgaGFwcGVuLiA6KQ0KPiANCj4gSSB0aGluayBpdCBpcyBs aWtlbHkgdGhhdCB0aGlzIHdpbGwgYmUgYSByZXBlYXQgb2YgdGhlIFB5dGhvbiAyLngNCj4g ZGViYWNsZSwgZS5nLiBhZ2FpbnN0IGJldHRlciBqdWRnZW1lbnQgZXZlcnlib2R5IHdpbGwg anVzdCBrZWVwIG9uDQo+IHVzaW5nIHRoZSBkZXByZWNhdGVkIHZlcnNpb24gZm9yIHllYXJz LCBhbmQgaXQgbWF5IG5ldmVyIGZhZGUgb3V0DQo+IGNvbXBsZXRlbHkuLi4NCj4gDQpUaGUg T3BlblNTTCBzaXR1YXRpb24gaXMgYSBiaXQgbW9yZSBtYW5hZ2VhYmxlIHRoYW4gdGhlIHRy YW5zaXRpb24gYXdheSANCmZyb20gUHl0aG9uIDIuIENvbXBhcmVkIHRvIGFuIGVudGlyZSBs YW5ndWFnZSBpbmNvbXBhdGliaWxpdHkgDQoocGFydGljdWxhcmx5IHdpdGggc3RyaW5nIGhh bmRsaW5nKSwgbWFueSBPcGVuU1NMLXR5cGUgY29uc3VtZXJzIHVzZSANCnNtYWxsIHBpZWNl cyBvZiBmdW5jdGlvbmFsaXR5IChhcmNoaXZlcnMvbGliemlwIGNvbWVzIHRvIG1pbmQpLg0K DQotLSANCkNoYXJsaWUgTGkNCuKApm5vcGUsIHN0aWxsIGRvbid0IGhhdmUgYW4gZXhpdCBs aW5lLg0KDQo= --------------hvv36PVvA4Q0Ch0YE65a90Xu-- --------------OX20apOUrGY4Q0mo6txRuWEG Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmRGolMFAwAAAAAACgkQ/reFK+KbPodU eA//c22sOFyDgR+pC1ZZKv1mrjzGPcOiTaDSFPxzwiSOavEIshTzaaetkOh6Zz9YVQVx4nTVEoZ8 DA29wYWlIbCKVqcE9pyldrl7QEhQnV0Zfw3QlXh7FXDTGvYGO0bgmmwusx8NUvXAee4rVf7T12Qx gxEf9grg6f8otsJOI6GvQQ15jZ0BHxaShSSPIRY2GHmUmyOmPoUNIhmtL4PNm9VcHQ0e2gO1LA6u REJSGx2OqgkFK4v3HTDn2tSPFeqC/Il/prOlD0fYo+leaUu4krsCbRt8EZUtlsHRIMJr92BpcFZc CoX4CjakKrEVKScTUYMenGJg6D31i5sAwotzz/hC392ujLnVd3cwWrkrP9O8W79+njgAd07N9G8E 6zcXfLGJ3Cof87Nls0AcTQMiRtf6P2EB2yly1B84yEhJcGSMIAshDZlCcpOmF1Mjd9YD4/6o4Gha O9fSwgiAYHosTxqKCDK5sT7TAFFvNOuuNSiRMPxJ1Nc+Bqoi0gEZY8UQ6p4tHMusB///mGutvS+t 9RGRIztB+rxLyjdyv93ODHwyU3TefCgz6B9/T09nAspYFehZo9AB73vzk+5ggVZB/gvTp0vY2xCo s5oyVjM0DU/LGwkdp2GlQSnJtH9pMq90JkIonmitidC6Re0ExRUYd4I1sKPIB6cBAhky4S6mVwy4 8sA= =7w9Y -----END PGP SIGNATURE----- --------------OX20apOUrGY4Q0mo6txRuWEG-- From nobody Mon Apr 24 17:06:14 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 4Q4s3m4Rsjz475gx for ; Mon, 24 Apr 2023 17:06:28 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) (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 4Q4s3l66j2z4Gcm for ; Mon, 24 Apr 2023 17:06:27 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.208.175 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com; dmarc=none Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-2a7ac89b82dso44661481fa.1 for ; Mon, 24 Apr 2023 10:06:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682355986; x=1684947986; 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=cL6+X4+9gwolbvgl91hBw1Xso3YAlcaHwxpjOQlVLhE=; b=ae+t4VkZKaBRrO0wOG3x4yit2NbnWZTORZqXuDfgs2o+N6bhLNo0TBvPNRa1Pw5vER uH9m+EOpgcS6PNHEdw6MgSTJQ0CyadEyl61Nv8DUavlfTiDJ/vuBdeBlBHdF/jgeNgVB rcDV4/xS/2WABpJPVTYz/X6MxPK4N/XKgk+TmWLvNWunSjRJAFKNRYTbHwjkc34aIbLK HDJFjrGiHI9pAbKaHBG4pYq68JwDpthcpxWkXtHC+G9IAOzYhcm3CbBoiV6zri/d17Km HvJ7V6S4tZicMdYxyXE8Z1Emoi0pRzMtH92k4XygeLYOwzFx0iCQEUsrdgkV/c2F08dC xFOA== X-Gm-Message-State: AAQBX9feCgS50MEga1SNQH0PrtUYkVW8tOlCvxwLSBVljAuY/66MAnEA vARC5uAMfp0/hOLfyipUAnfe4kH36YpCTTWrEh+syrAvjEs= X-Google-Smtp-Source: AKy350Y3l09KVKtVuPyWbcHOgXz7OZl6tZu3q/VDfDPdCDLx8dl+M+g9Tauj+A20GOVskho2K7i78Fr4p35Ox2Cf6Rg= X-Received: by 2002:a2e:2e0e:0:b0:2a8:c32d:1238 with SMTP id u14-20020a2e2e0e000000b002a8c32d1238mr2874677lju.15.1682355985498; Mon, 24 Apr 2023 10:06:25 -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: Ed Maste Date: Mon, 24 Apr 2023 13:06:14 -0400 Message-ID: Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 To: Konstantin Belousov Cc: freebsd-arch Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-2.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.98)[-0.981]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.175:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.175:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Q4s3l66j2z4Gcm X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On Wed, 19 Apr 2023 at 18:08, Konstantin Belousov wrote: > > On Wed, Apr 19, 2023 at 12:50:59PM -0400, Ed Maste wrote: > > A related issue is base system libraries that depend on OpenSSL would > > also need to be made private. This includes gssapi, heimdal, and > > libfetch. > Does ssh and pam in the base depend on the base openssl? > If yes, then it still leaks into the applications despite being private. Yes, I see the following libraries which bring in libssl: /usr/lib/libprivateldns.so.5 /usr/lib/libprivatessh.so.5 /usr/lib/libprivateunbound.so.5 /usr/lib/pam_ssh.so.6 /usr/lib/libfetch.so.6 and libcrypto (privatelibs excluded): /lib/libzfsbootenv.so.1 /lib/libbe.so.1 /lib/libzfs.so.4 /usr/lib/pam_zfs_key.so.6 /usr/lib/libkafs5.so.11 /usr/lib/libgssapi_ntlm.so.10 /usr/lib/libarchive.so.7 /usr/lib/libkdc.so.11 /usr/lib/libradius.so.4 /usr/lib/libgssapi_krb5.so.10 /usr/lib/libkrb5.so.11 /usr/lib/libhx509.so.11 /usr/lib/pam_radius.so.6 /usr/lib/libssl.so.111 /usr/lib/libkadm5srv.so.11 /usr/lib/libkadm5clnt.so.11 /usr/lib/libhdb.so.11 /usr/lib/pam_ssh.so.6 /usr/lib/libheimntlm.so.11 /usr/lib/libfetch.so.6 /usr/lib/libmp.so.7 /usr/lib/pam_krb5.so.6 /usr/lib/libbsnmp.so.6 /usr/lib/pam_ksu.so.6 Baptiste reported elsewhere that libfetch's use in ports is very limited, so it could easily be made into a private lib. From nobody Tue Apr 25 09:30:03 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 4Q5Gtj27nRz46w9d for ; Tue, 25 Apr 2023 09:30:05 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4Q5Gtj1Gk4z3tY7; Tue, 25 Apr 2023 09:30:05 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682415005; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=I6bSLzSvse3oNGnHTxmbkyh7zPGygvUKosbOsChL+7c=; b=jn274JUisvI/wzwVp+f29dFdAU1/xF7FLy1+xyyIyT0A+ybb2/jBB7VpbBpupxggNAjI3k 4h9VqfQElWQe9g5oN3z23OMnc0XkIRFceSOR6NM9L/ms0gVagjOug5+wOMi6W9l2Er+FbB MEeV3pCxWwLcTdmKWbPkMBNJ5mCVEN/XnaF0uyl/KZwx+hHCsY03CeJaB2zPZovHwCB0sq qizT7KAGzPLq7hEWH2qMixGbF6F5RbasUv5m1M+YydNsqUTCqkNopiTTVHmJ4/PC+N5WUI u38PFzg5gXogTE/ZizX2pwlJ9OCSGlrLXgvHkcGbOf5ss88/OEIuVjOTblvHtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682415005; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=I6bSLzSvse3oNGnHTxmbkyh7zPGygvUKosbOsChL+7c=; b=sxQEFiF8/fjIK6TlJStEvlmISa9JDZ/+3EmpX2udblUPB3BSrknpaNgxIlVlUJOqn2f8/b Of9T4g+CL8bH89CgAz6S2D3I/ckjQ0m11aMtm1xybzuFl2CoCCUA4jR85kUzDz56hMQso4 oeVgwu9cN82DBfS2Ml4diCX1QSrYxJat9R8wvhJq545CmqS2TsmiVehMeZHRCxm4SrmNqk YhSzdlBktRUHMrGruvivjWxOuOQq/q6TzcM6BLi9Bic3t+ZYjZ6uA5gp8Z1H75it4lU24P 3rdt/Owj95vCkdcUvjrAJkfhN6TMXD5/zhjCIlYiAXx+hWHcyNDaHfJ6cI2oZw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682415005; a=rsa-sha256; cv=none; b=jnGN0072b3NjwKkY7qI36pyC6qXIFXZ7cn5zuIylAa4vzpKP2+keGI7293cV+myX0BHxAo hbg/PGNRa78Oa8w7ZYKi6JQUhX8VwPLdNcB/7g0T2G0CPap4QQ9BClWf56faCi+l0mV73g 6A+oN3txei9auNk1lb5O4VD1YnrFbpa3MUcciesLeP3aU4GErb2U1QS1ERwrth9YhdBOzm g8MZcDEfqqsnmzSLzNL90l54VkW8oSzhNGu9KBjyRj1dodtWv80Trp0osWr+LBFpRZMOzN aF8tLxhK3QbW/v52U5qtq7PjfJ8uWw4NqliqYl1V2G1/6qgTFnt+GRyWYmkZcg== Received: from aniel.nours.eu (nours.eu [176.31.115.77]) (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 did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q5Gth6n7Yz13vC; Tue, 25 Apr 2023 09:30:04 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 7E3051D77A2; Tue, 25 Apr 2023 11:30:03 +0200 (CEST) Date: Tue, 25 Apr 2023 11:30:03 +0200 From: Baptiste Daroussin To: Ed Maste Cc: Konstantin Belousov , freebsd-arch Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 Message-ID: References: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N On Mon, Apr 24, 2023 at 01:06:14PM -0400, Ed Maste wrote: > On Wed, 19 Apr 2023 at 18:08, Konstantin Belousov wrote: > > > > On Wed, Apr 19, 2023 at 12:50:59PM -0400, Ed Maste wrote: > > > A related issue is base system libraries that depend on OpenSSL would > > > also need to be made private. This includes gssapi, heimdal, and > > > libfetch. > > Does ssh and pam in the base depend on the base openssl? > > If yes, then it still leaks into the applications despite being private. > > Yes, I see the following libraries which bring in libssl: > > /usr/lib/libprivateldns.so.5 > /usr/lib/libprivatessh.so.5 > /usr/lib/libprivateunbound.so.5 > /usr/lib/pam_ssh.so.6 > /usr/lib/libfetch.so.6 > > and libcrypto (privatelibs excluded): > > /lib/libzfsbootenv.so.1 via inheritance from libzfs.so.4 not directly linked to libcrypto > /lib/libbe.so.1 via inheritance from libzfs.so.4 not directly linked to libcrypto > /lib/libzfs.so.4 "only used" for libzfs_crypto > /usr/lib/pam_zfs_key.so.6 > /usr/lib/libkafs5.so.11 > /usr/lib/libgssapi_ntlm.so.10 > /usr/lib/libarchive.so.7 Ports already uses libarchive from ports unconditionnaly so not a pb here. I was due to the fact that libarchive was linked to libmd instead on libcrypto in the past, and was causing issues when libmd symbols where in collision with libcrypto (which is fixed since but the ports tree did not move). So not a problem here. > /usr/lib/libkdc.so.11 > /usr/lib/libradius.so.4 > /usr/lib/libgssapi_krb5.so.10 > /usr/lib/libkrb5.so.11 > /usr/lib/libhx509.so.11 > /usr/lib/pam_radius.so.6 > /usr/lib/libssl.so.111 > /usr/lib/libkadm5srv.so.11 > /usr/lib/libkadm5clnt.so.11 > /usr/lib/libhdb.so.11 > /usr/lib/pam_ssh.so.6 > /usr/lib/libheimntlm.so.11 > /usr/lib/libfetch.so.6 > /usr/lib/libmp.so.7 > /usr/lib/pam_krb5.so.6 > /usr/lib/libbsnmp.so.6 > /usr/lib/pam_ksu.so.6 > > Baptiste reported elsewhere that libfetch's use in ports is very > limited, so it could easily be made into a private lib. > Or even an internallib considering there will be do consumer left but fetch(1) best regards, Bapt From nobody Tue Apr 25 10:30:16 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 4Q5JDS15vWz470hf for ; Tue, 25 Apr 2023 10:30:32 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5JDR3XSJz41C3 for ; Tue, 25 Apr 2023 10:30:31 +0000 (UTC) (envelope-from Alexander@leidinger.net) Authentication-Results: mx1.freebsd.org; none Date: Tue, 25 Apr 2023 12:30:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1682418618; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zpP7gPYWyPQHjDO5s/WET9cK5D3YzeG0CLfmGYiNr5A=; b=exh+8WuElUVzjBeIpmBX0MTb3OpQ7GjvEzzVj5eqVJ6vDFjuAGSoaqBFPwdx38/sqWTXjt ozLuu1f4ApXp/M7E1fbVuFUYjXyjsGcrqZccQ7cFwECs5WtA3BfSQqPA+IAtvHXDi5eHCw 0dQz720cAGpedl5UNp3/P4AplOmD39uqzXKeg09+bQSRAwSsQ33pL7w41L1ch+dgHXoudS TIBLJNlq/l3wZX6a6IFBICw+vD/AO/EbGMuIAhOPXvhrYwRihWfIXspW699TL7FW0w1AFN tqscuoL5/i8ny2DkuW8lPMVnSMtCansFWRWPE1afK+traKkfMBZl+6TF8GXmTA== Message-ID: <20230425123016.Horde.YqdbqxIwT9cc_qCUq1zhsfj@webmail.leidinger.net> From: Alexander Leidinger To: Charlie Li Cc: Ed Maste , Joerg Pulz , freebsd-arch Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 References: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> In-Reply-To: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_2534iIRQQ2aqQWEes438_4Z"; protocol="application/pgp-signature"; micalg=pgp-sha256 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 X-Rspamd-Queue-Id: 4Q5JDR3XSJz41C3 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_2534iIRQQ2aqQWEes438_4Z Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Charlie Li (from Mon, 24 Apr 2023=20=20 10:33:39=20-0400): > Ed Maste wrote: >> The problem is that we have conflicting constraints: OpenSSL 1.1.1 is >> EOL shortly after 14.0 releases, and there are ports that do not yet >> build against OpenSSL 3. I am not sure how much will be broken if we >> update the base system to OpenSSL 3 but leave the privatelib aside >> (i.e., have the base system provide OpenSSL 3 to ports). >> > OpenSSL 3 is a major, even larger than 1.1, API/ABI change. Quite a=20=20 >=20bit of stuff will be broken today. The effort here has to include=20=20 >=20working with as many port upstreams as possible to force the issue,=20= =20 >=20as they may not hold OpenSSL 3 compatibility to be an immediate=20=20 >=20priority; patching ports on a large scale like this is not=20=20 >=20sustainable. OpenSSL is a major part of the security infrastructure worldwide. Once=20= =20 1.1.1=20is EOL, it is "burnt" and should not be used anymore. Any 0-day=20= =20 exploit=20will cause havoc and software would need to be switched to 3.x=20= =20 before=20that if you take it seriously. So from a security perspective, I rather switch now (while 14.0 is=20=20 still=20called -current instead of -rc or -stable) to 3.x and live with=20= =20 the=20collateral damage in ports, which will naturally get smaller over=20= =20 time=20as people have more pressure to fix it soon to get something they=20= =20 need=20get up and running. From a stability point of view, this is off course a bad way of handling i= t. As -current is not -stable, I could imagine a split view on this: - announce to -stable users to switch to the quarterly branch for a while - warn -current users about collateral damage for a while (e.g.=20=20 UPDATING=20entry in src and ports) - switch -current to 3.x (quick and easy, not as a private lib) - let port maintainers and users work together on fixes for the=20=20 broken=20ports (in each port: if OSVERSION >=3D 14000x use 3.x patch) ... - ... while work is underway to switch openssl to a private lib in -curre= nt. Maybe also halt the package distribution to the official download=20=20 sites=20while the main branch of the ports tree has too much collateral=20= =20 damage,=20and resume it once "enough" ports build. That's maybe not nice, but at least something which a volunteer=20=20 project=20is able to handle. It divides the problem into smaller pieces=20= =20 which=20can be worked on in parallel. For 13-stable I consider the train to have already left the station.=20=20 We=20can not fix existing releases to use openssl 3.x in parallel to the=20= =20 existing=201.1.1 libs. Anything we do to ports to use openssl 3.x, no=20=20 matter=20if as a private lib in base or not, has to be gated with=20=20 OSVERSION=20conditionals. As such 13.x is a train wreck from a security=20= =20 perspective=20as soon as openssl is EOL and IMO we need to highlight in=20= =20 the=20release notes in 14.0 that it is highly recommended to switch to=20= =20 it=20as soon as possible. My main point is, that we can not only look at 14.0, but we need to=20=20 have=20a look at the big picture, including 13.x and the global security=20= =20 implications.=20And from my point of view, we (as a volunteer effort)=20=20 are=20not able to deliver a solution which works for the entire big=20=20 picture.=20We have to accept some kind of collateral damage in the big=20= =20 picture.=20And my suggestion is to think about which collateral damage=20= =20 we=20are willing to accept. The above is one way of accepting a=20=20 particular=20collateral damage. There are other scenarious which have=20=20 different=20kinds of collateral damage, and as a project we need to=20=20 decide=20which one we are willing to accept, we need to realistically=20=20 think=20about which one we able to work on (and personally I would value=20= =20 the=20voice of those people which will provide a halping hand a bit=20=20 higher=20than the opinion of others). I agree that ideally all upstreams have to be included, but if we are=20=20 realistic,=20it means we fix our stuff and provide patches to upstream,=20= =20 and=20some of those may even be included upstream (yes, there are off=20=20 course=20also upstreams which will do the right thing, but we can not=20=20 depend=20on this on a global scale). Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_2534iIRQQ2aqQWEes438_4Z Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmRHq7cACgkQEg2wmwP4 2Ib12w//V6dYneaon4zzNuPcCrfrjp605qjVCnwWEJizj2g9kPX9LzaTMOgHQNZp Xpw8ev8qHu6YWh9ssTwkIXmbzFXeGXB9oFcZrzbBcjt0LSEeY6I5ZaQlqwrmVgfo VilZ+bUaEZHASp8LtbVX2fJzF+aGrdPzvjEhPLmBDZNsQYImv33o6jkmfHKdD06k VMmoKViaJUYy+5JMkOlk12f3U0m/QLQQFsgbRzCBHgfe98r3XXEJLfmiOSH/POyU 1RvrlZZ29ZocRlyDZUkbZNnpBO9uQTIxETN7BIpmbnTSrxYtFq4pA0Q7yCnA83kf oJ7odK/UAZktrjlzfOUIJ0/0Q7+osGzphy9/AIMFXnGfNeswIouEYHVipG3LVLjh 7nVMiM7YY24YKhH57ZsYkjIN4BGU+nn0mIbTl6AQQD+Gv9H9rf8hc1r7NlPirijp HcJeqbfH+uJO5yUY3JlhxVBHnRxclSPxsp59yR6LcZ07COGQTMMr799ajL+qx0Aw /zx+nIXw341rCECEqveNthKXHN32w7R67bg6l4nUiPYUWP+33z3PCACAJV97JViv BEVePBav31i7cok0pcDdacBgx9CMbMxUAQYc5smqlba7RLvrl5VCB8/jVj9mYX9Z z4iqqZ3Oeaa9y1lc7jLF4yje0vyGkye6jwIex0RTtqJHoxwT6tI= =TMCH -----END PGP SIGNATURE----- --=_2534iIRQQ2aqQWEes438_4Z-- From nobody Thu Apr 27 17:19:59 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 4Q6jD12TdJz47hNJ for ; Thu, 27 Apr 2023 17:20:01 +0000 (UTC) (envelope-from jhb@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 4Q6jD11v0Gz3r52; Thu, 27 Apr 2023 17:20:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682616001; h=from:from:reply-to: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; bh=lOl3ZlFJG5xIj7VoSgMcYmRZj/yPnZLjSl3an8A9NFc=; b=yzwr4F+2aD8VtOxu7jTsNLaimSjZPClse7q4xpPnrggyaiLi2M5B5qr+RaVEiOn5fUFIrX mAvoWxFSVPukvRhcdkvFqhwlob+tJuHJsYPkC0fe4nCizM0EP87rhk28mSueODug92+/Vp Lgfq4DztCxAhqt9vVuc7HMfqnKO3DjdmkAaNst53yHhuGf3nLvUi1pBo5/MWeynQHBdI69 gO0RsJd5/uIZ2DBtLnu8h0Q1aIKFT9fTTsgYpiXgz1Tilfot9K8koMwY33DpBY/q9KpO+8 ou0QJCmEO2HjREg+AwxEtsqBl27tZ3ggjYfRCFzXuLNyohtZJVnKkxBCchpixA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682616001; h=from:from:reply-to: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; bh=lOl3ZlFJG5xIj7VoSgMcYmRZj/yPnZLjSl3an8A9NFc=; b=hKmmMWqtoNOECVg3rqq2o4yjxzH3JzA5xcDnjicGrxy2b80abzdLBPLcdB92Hic4K1fzVl I5pmgEGhCC0CSod+lY9sHgCShajWy6dyURTx2Us47qlBomKGrXhW4vnlg6nTvFbvf1haan N51Ml2b1W36CFe4GbZMnbMamvpwrSl1GmlbD9Z8CbZNiFPJ0rFlbfa6GujaHKSgOC4eYYo MAba1j3dZE2LOwuZ41BTIbjcvJVHDlxzRApoQAZOGbNh80anOd3ZllouIdsNbRmXN7DeS+ v2SGx3l33AGO9e7zeD0gSPHArdNXclIcQBVTpuwBS0ooPaZMSnJxM4cTCLiOHw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682616001; a=rsa-sha256; cv=none; b=tqf+SMNI2XplzK8rZbjdnd6VVNJRKdPip4LU5hArQdKWCXTQT1+yySx24BnkIyHqoxeOH8 aFjLmIcDGuXmdeq5ozs4wPk2N46MDD74CzgFetebFVBlbFa093IBfBsptM7zLy6e/YDk32 WY1Ff+NqO/hnk56p5OTiDxNHbI09W0y9sjnY2pTiZg1EJyA3aakHgwuWd2oEKAOk9U0OQ0 6c7yvVadELYHk7VeGDnkefo//PrBD/jLyjZzC2CMwLBQa87gXdwn77NUzEzwq9gQcRdpw+ 9SGiICzwo3tnElGojdSxCATr8wHbu44a+syHzd97YY84ok3nHuvOPSzg2yvLrA== Received: from [IPV6:2601:648:8680:16b0:4873:5c14:f13a:ffd7] (unknown [IPv6:2601:648:8680:16b0:4873:5c14:f13a:ffd7]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q6jD04mm4z18SB; Thu, 27 Apr 2023 17:20:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Thu, 27 Apr 2023 10:19:59 -0700 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 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US From: John Baldwin To: 'freebsd-arch' Reply-To: 'freebsd-arch' Subject: Future of 32-bit platforms (including i386) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N 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. -- John Baldwin From nobody Thu Apr 27 17:32:21 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 4Q6jVQ5SD8z47j01 for ; Thu, 27 Apr 2023 17:32:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q6jVQ3FT6z3v6c; Thu, 27 Apr 2023 17:32:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 9347189281; Thu, 27 Apr 2023 17:32:22 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.17.1/8.16.1) with ESMTPS id 33RHWLQS069783 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 27 Apr 2023 17:32:21 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.17.1/8.16.1/Submit) id 33RHWLrw069782; Thu, 27 Apr 2023 17:32:21 GMT (envelope-from phk) Message-Id: <202304271732.33RHWLrw069782@critter.freebsd.dk> To: "'freebsd-arch'" , John Baldwin Subject: Re: Future of 32-bit platforms (including i386) In-reply-to: From: "Poul-Henning Kamp" References: 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 Content-Type: text/plain; charset="us-ascii" Content-ID: <69780.1682616741.1@critter.freebsd.dk> Date: Thu, 27 Apr 2023 17:32:21 +0000 X-Rspamd-Queue-Id: 4Q6jVQ3FT6z3v6c X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N -------- John Baldwin writes: > 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. If we do, the first two questions we will get back are: 1. When does 15 happen ? 2. How long time will some branch of 14 be supported ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Thu Apr 27 17:33:15 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 4Q6jWW60F5z47hwt for ; Thu, 27 Apr 2023 17:33:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 4Q6jWW4FQKz3vpt for ; Thu, 27 Apr 2023 17:33:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-5066ce4f490so13081811a12.2 for ; Thu, 27 Apr 2023 10:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682616806; x=1685208806; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=rUhEj50t42UkePkq/ECNkjq5Sq2eUa0JFcxKE741d7Y=; b=AI3nufA8qKcLe1E62nQijw2gQVOin48chq/FvyUwDUdVWxUw9vb1Cf1EN+G7XjXB3i 3jZx0wF9BFbQpCVu9evCC7XhrwqWzfpzuv1rmCd9QY20bAPtjxhNVwyV1GHMl4IxSgf2 AJafIbHzBRC2k8cugLxlEhIj1J+TryKMjRBSX4UOxC/9k7D4TpnRwY52RHEzGPyNgdut rCUfsmmuN8V6obYfgjGpdlPX5V782SxSpi4qsX9rJmjLwZ3f6d8wYtXhudyctmG6xha0 Np69g61F3WGA37kO5eAoU3K+bKsrpZ3UkP1Qv+GPE1HHhE3O7ZTn/IF4JzJzpmxvy6ii FREw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682616806; x=1685208806; h=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=rUhEj50t42UkePkq/ECNkjq5Sq2eUa0JFcxKE741d7Y=; b=lLILrw5qySOBCSp1oQe1zxMRdGZNc9H3uaBNVEFxyqGUsD4AIERU3yEfT1o8N+rvFi Twap1qdwql9J/L3edoPj3sATgb287544FJYqA0Y5J7lkOH+JjkU8CiWWkMfZjAS6zzIN kYSInGLRgv0A1d+EGcMQk22Grud0siC/wcjHPqC9cZfLdAaoYwsL4O2jCPKKk9+/aiXD DltuzxJdzVQNGRxujIsIDJcZdhdpdB7snAmL6X1CG2bgXCi5w8s2Ji+wWWMtdgSzvhxz 0D25YJj9BvoAO6K36dhFX9a9pDVfyQLNDPMw6Www6B783+6wnAeCxTyCv7eX3zUUJXH1 CMtA== X-Gm-Message-State: AC+VfDwjtLChW3BnTZOOml1fyjR+NIXeliO48yu5RpAGRDn0hzsJcnIq s2oWgm8onoKBWccR+SzjnUjrDEM0DloN61NhuIDaabUlB2W57P03 X-Google-Smtp-Source: ACHHUZ4i89klC2AcUH1/BNS1hTfSy2emAsZOd+rRNVhMTugDf+ZcZkFihg3eQ/OU9/97gHa+P3KEbtNgKZOS3rp4cMU= X-Received: by 2002:a05:6402:419:b0:50a:14e6:b9bc with SMTP id q25-20020a056402041900b0050a14e6b9bcmr2455215edv.17.1682616805740; Thu, 27 Apr 2023 10:33:25 -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: Thu, 27 Apr 2023 11:33:15 -0600 Message-ID: Subject: Re: Future of 32-bit platforms (including i386) To: freebsd-arch Content-Type: multipart/alternative; boundary="000000000000ffeede05fa54c03c" X-Rspamd-Queue-Id: 4Q6jWW4FQKz3vpt 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 --000000000000ffeede05fa54c03c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 27, 2023 at 11:20=E2=80=AFAM John Baldwin wro= te: > 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. > I like this. "In 14.0, i386 completes its journey to tier 2 status" maybe? > 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. > So no freebsd-update service for i386 for 14.x, but have it for arm64 and amd64? That seems reasonable (assuming that arm64 works). > 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. > I like this idea. It states intent strongly enough that people aren't surprised, but weakly enough that people with strong interests can show up. One lesson we've learned repeatedly in the past, though, is that we get a lot people showing up saying they'll do something, but then doing nothing. The threshold of doing something will be actually doing it and being an active member of the community or providing other material support rather than "Geeze, I'd hate to see sparc64 go, so I'll fix a port or two". I'm not sure how you'd set that expectation, but maybe something like "we'll evaluate the responses an= d the robustness, size and vitality of those communities as input into our decision" which would set the bar higher, and have something vaguely measureable to point at. Side note: We should stop providing packages and re-built images for armv6 in 14, even if we don't completely decommission support for it right away. That might prove to be a good model here as well and give us some good experienc= e for how to do that with the other 32-bit platforms for 15. I generally favor this idea... It's also a natural evolution of what we've been saying about platforms, eg you need to provide 64-bit atomics and other operations= , even if they are relatively inefficient because the base system is starting to use them. 32-bit going away is the long term trend, and the long term goal of the project. What remains in doubt is the timeline to accomplish this. Many 32-bit platforms still perform decently well, so we should expect to see some usage. But we need to weigh the size of that usage against the cost of providing it. We've seen an increasing cost to developers to provide this over the last few years. But as the usage drops the cost increases because unanticipated breakages become harder to fix as they are discovered further and further from the breaking point. Warner --000000000000ffeede05fa54c03c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 27, 2023 at 11:20=E2=80= =AFAM John Baldwin <jhb@freebsd.org> wrote:
Fo= r 13.0, i386 was demoted from Tier 1 to Tier 2.=C2=A0 In the announcement of this for 13.0, the project committed to an update on i386's future around the time of 14.0.=C2=A0 The announcement at the time suggested that<= br> 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.=C2=A0 That is, release images and packages would only be provided=
on a best-effort basis, and we would not guarantee providing them.=C2=A0 I<= br> think we should also stop shipping binary updates for the base system
(freebsd-update) for 14.x for i386.

=C2=A0
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.=C2=A0 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.=C2=A0 Another option to consider for 32-bit platforms perhaps in 15 is to remove
kernel support and only retain the ability to build userland.=C2=A0 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.



<= div>even if they are relatively inefficient because the base system is star= ting to use them.

are discovered further and further from the breaking point.

Warner
--000000000000ffeede05fa54c03c-- From nobody Thu Apr 27 17:40:55 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 4Q6jhM2c9Lz47jXf for ; Thu, 27 Apr 2023 17:41:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 4Q6jhM0zPtz3wmp for ; Thu, 27 Apr 2023 17:41:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-506b8c6bc07so14884070a12.2 for ; Thu, 27 Apr 2023 10:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682617265; x=1685209265; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cJewukmMAeWFTNb+263FskfsBfM9hFodRdx8+fOZV/A=; b=Rfiv5KgnDbDT4OVLRdleDualvzZ/+EoWenzyI3Ogy22oacCQnqxnha3VX3gk8z6KLG khXup0qUwXMQL1+9La3uG0KwfeHDX3fzYY8IZV4i2vZ3K+xj+lAs1YAob53tMIZjkQY/ OH6n5UDWkGteNRKMMfIJSnuyQtWLw7MDlv3mKa8HYmm2Wo/gu576HeVgdruW7MokMxoq iOCekevrlHFSVyPfDeinXf+BnkfE4MVRsU4bpM5/D24qdEc2M7h4fjvawJBcaXRnrtH/ gAmiT+/1DchADlaBxoxZaQlHm1UjYxIUePDBgiQOcn0Xo4c+miR0KmI/1wBlDBkbzT6A jiyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682617265; x=1685209265; 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=cJewukmMAeWFTNb+263FskfsBfM9hFodRdx8+fOZV/A=; b=YyUAkIV3sC+v2yWkXigEKYObzIZj/yPb7Lo2zIqFZ1ueMCOEMUcaDeYVLSZus3/wEk TQE1u6rFn2BttFi0B5g56mBDZTbc39NWrjtYW5VGWtpiJ9KdUCy0kijVBMOXcIT2C29m QAYCgovvekej25hd2lmsg2Y4w/FwqHhAIws6DhpkYpL/r5smCJEKIpnBETeUoNvj4IZx Q4kXDyDl9zFeS0d1BVE9po6RmpjO8lbHbz8008TVPS8x7EIwOoddFk+A6pBaHWGxNXwz z0zROvAiiHk9yjFtKec8prfYwXPKzlbfdyWyg6e6wiBamU+lMXIeshtgSCO4ADui0Ayb s4hQ== X-Gm-Message-State: AC+VfDzjELEAgiPzi5uqU90vmfFk1cLEDTAXqwi/voidxuyp2gXnTwfB MROvbWNxm4+rIW5ipoHbiaZ517o65pWEhdOKpVVY/Fi6MXoV+pXt X-Google-Smtp-Source: ACHHUZ4Tp2wRB7AwLzDzh2YoLAuBMlMDEP/MpDa4Im5z644KRClMIQfoPBT5D3Qz2DAmD8KFG8c/B4KoB3MX8Ske3x0= X-Received: by 2002:a50:ff0b:0:b0:504:923f:e657 with SMTP id a11-20020a50ff0b000000b00504923fe657mr2139619edu.35.1682617265415; Thu, 27 Apr 2023 10:41:05 -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: <202304271732.33RHWLrw069782@critter.freebsd.dk> In-Reply-To: <202304271732.33RHWLrw069782@critter.freebsd.dk> From: Warner Losh Date: Thu, 27 Apr 2023 11:40:55 -0600 Message-ID: Subject: Re: Future of 32-bit platforms (including i386) To: Poul-Henning Kamp Cc: freebsd-arch , John Baldwin Content-Type: multipart/alternative; boundary="00000000000065fd2705fa54dc72" X-Rspamd-Queue-Id: 4Q6jhM0zPtz3wmp 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 --00000000000065fd2705fa54dc72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 27, 2023 at 11:32=E2=80=AFAM Poul-Henning Kamp wrote: > -------- > John Baldwin writes: > > > 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. > > If we do, the first two questions we will get back are: > > 1. When does 15 happen ? > Late 2025, give or take 6 months would be our recent cadence. while we might want to change this cadance, any decision here should likely assume that cadence and we can make adjustments to the plan based on a hypothetically changed cadence would bring. So we'd plan on removing the 32-bit platforms sometime in 2024 or early 2025 at the latest, but as soon as the end of this year. So you'd no longer be able to run 'main' on these platforms after a year or two. > 2. How long time will some branch of 14 be supported ? > At least until 2027 if history is a guide (de-facto is about 2 years after the next major branch) with fading levels of support. I think the 'support model' would place it around June 2028 somewhere assuming we release 14 in June. There's clearly some fuzziness here, but for planning purposes one should expect updates to trail off in late 2026 or early 2027 and critical updates stopping sometime before 2028. At least that's what I'm observing with EOL of 12 that's pending... as well as what's happened more organically for 10 and 11. Of course, the above is my opinion, and it's phrased such as to give some less vague timelines to John's proposal. Is this helpful? Warner > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetenc= e. > > --00000000000065fd2705fa54dc72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 27, 2023 at 11:32=E2=80= =AFAM Poul-Henning Kamp <phk@phk.f= reebsd.dk> wrote:
--------
John Baldwin writes:

> 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.

If we do, the first two questions we will get back are:

1. When does 15 happen ?

Late 2025, giv= e or take 6 months would be our recent cadence. while we might want to chan= ge
this cadance, any decision here should likely assume that cade= nce and we can make adjustments
to the plan based on a hypothetic= ally changed cadence would bring. So we'd plan on removing
th= e 32-bit platforms sometime in 2024 or early 2025 at the latest, but as soo= n as the end of this
year. So you'd no longer be able to run = 'main' on these platforms after a year or two.
=C2=A0=
2. How long time will some branch of 14 be supported ?

At least until 2027 if history is a guide (de-facto is abou= t 2 years after the next major branch) with
fading levels of supp= ort. I think the 'support model' would place it around June 2028 so= mewhere
assuming we release 14 in June. There's clearly some = fuzziness here, but for planning purposes
one should expect updat= es to trail off in late 2026 or early 2027 and critical updates stopping
sometime before 2028. At least that's what I'm observi= ng with EOL of 12 that's pending... as
well as what's hap= pened more organically for 10 and 11.

Of cours= e, the above is my opinion, and it's phrased such as to give some less = vague timelines to
John's proposal.

= Is this helpful?

Warner
=C2=A0
=
--
Poul-Henning Kamp=C2=A0 =C2=A0 =C2=A0 =C2=A0| UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| TCP/IP since RFC 956
FreeBSD committer=C2=A0 =C2=A0 =C2=A0 =C2=A0| BSD since 4.3-tahoe=C2=A0 =C2= =A0
Never attribute to malice what can adequately be explained by incompetence.=

--00000000000065fd2705fa54dc72-- From nobody Thu Apr 27 18:18:55 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 4Q6kX73tgBz47lvB for ; Thu, 27 Apr 2023 18:19:03 +0000 (UTC) (envelope-from fuz@fuz.su) Received: from fuz.su (fuz.su [IPv6:2001:41d0:8:e508::1]) (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 (2048 bits) client-digest SHA256) (Client CN "fuz.su", Issuer "fuz.su" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q6kX71GWvz41tW for ; Thu, 27 Apr 2023 18:19:03 +0000 (UTC) (envelope-from fuz@fuz.su) Authentication-Results: mx1.freebsd.org; none Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.16.1/8.16.1) with ESMTPS id 33RIIt0Z042217 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 27 Apr 2023 20:18:55 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.16.1/8.16.1/Submit) id 33RIItP1042216 for freebsd-arch@freebsd.org; Thu, 27 Apr 2023 20:18:55 +0200 (CEST) (envelope-from fuz) Date: Thu, 27 Apr 2023 20:18:55 +0200 From: Robert Clausecker To: "'freebsd-arch'" Subject: Re: Future of 32-bit platforms (including i386) Message-ID: References: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Q6kX71GWvz41tW X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N I would very much appreciate if lib32 support stays in (or is completed in the case of aarch64). Without it, FreeBSD becomes a lot less useful as a well rounded development system as you can no longer test code for 32 bit platforms. I also have a need for armv7 user space code in particular as I participate in and maintain the FreeBSD port of a Forth system written in armv7 assembly. Being able to run the same code you run on a microcontroller on a hosted platform makes it a lot easier to test and develop. As for running 32 bit kernels, I do not really have an opinion. Yours, Robert Clausecker Am Thu, Apr 27, 2023 at 10:19:59AM -0700 schrieb John Baldwin: > 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. > > -- > John Baldwin > -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From nobody Thu Apr 27 18:57:58 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 4Q6lPM2gHfz47nwY for ; Thu, 27 Apr 2023 18:58:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q6lPL1sjQz47mj for ; Thu, 27 Apr 2023 18:58:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=amGMY48K; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682621892; bh=nSHOoT6hw5liR8G5OHgNiIvxzaIVDKGqaE3z/IekJXw=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=amGMY48K0gkLGqU4xps+scmYcJduEdhatXpQGHqvkj1uJBM+bLhTVBE0BaVnyQnTP2HtV6Rwq6wyBG1PwDva9SUt4kPeBHgCRmPipgbULktXHwLckOTI0r8EgeMr4nvdEuQkFkF+LkUPkdi5uoKJ/fGtwRPyzsMooddAEKL1yC6nkF//eamr7TUO2qxPEfqkReEMS9fMIeRaPKK9dnVSQlk+ZNjdbGxzTXGf6ribD0spWeJPQThHwtOt4858JxeYAopY+B7vxlaOdSuzckru3o4/Sh97vsIqs9fo72LctmxFNKQ+eMOTdyHErLX+ns2GXqI1WWK6UExqIYuVPV4w9A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682621892; bh=Xa4tAcw976d0Ly7xjjjsdumsuOHQvch8u0alSn4JAEB=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=jOxN/3C7WNslvXun8ahquesDviJ+yAswIChiSA6fwamUE/SK5zyPAJYd+pKUmGPZMBKbFHkAKIR5ib83SmLHVdmA+oq989rmzzsVLJL2tubE83kst8fXrKjRtVsiL17Pza0Zi1J+zF4VtkBidpglwqDJw9iYIb4CkcKKJzAIIdzqS/bkS0tM6yuvO41VPJsUPnIghye2T/+PWb9XlvHHJjLZSqneAqMjvUwqpe+aZWHFbnWNsxtn9R88igGtaRLGX/csq+5i3sv8XWwEn0xOFGRu50hqp2xX8/QfIDmyUrg8spRxc5Pv8z3UXJGF9ddZfzRvBI1GcWd9vPK0MJLXXg== X-YMail-OSG: gtDdMgYVM1kAFMTa58wrpoGAqH8yccZPt1THIxaQdgoEA7ByRA0BuTlefRJaJdl blsQtuE1VwiRpD9O2UYiBQ8BEvRU7CGZvcPH3tNa3lPAsAdCISHRA_Fchdg9uqvW6yDqX6noOwiO X2uRzdqvJIhrHf6OmEr94kuzkdXw8oi9DvdI7hRe2NDqZ00gaFB8W.iqLUWPpelok6WRX33S2JFN 7ktzq.zJ_M_5eDqg73.jwwKSvkZQPEKhnV9i_p4pGsaJwnOtN0O361C9p5aNfUoI2EsufvZAfXBX h7G85bJRrfWArir5hnezBYSXrSntVRqKQIbliPpxC.aLCTpLlOf36VdkZbZU.t8YMDZHsypLatvR Un4tnyCzVS.B70VWcXr4HmOpu4WTXoVpn9iukRoyLRnDJZaVmwyRMWzkqSV2HaYH0UZ_xwXdw1xl GbW6BNjy7zaDV56uAuCA8CrR_tLNx.2otSA905YfHJIDqk5WnUX6VqkQg_boSXU8oAvT9KwRd98X GTv6Uc5UDMVDa3sfMfvUMGDXVc.03PcWztvPbd.p1kn5X1T6UYPADIcTrOqIQRWhgoRRY4cNpHEL GySqFBfbjtVxW_WaiPOtc0jTo9zzPxInleok4BntiDfgytYSRpS778n8RGJQ15i4jAQB5p3BVOOs VN._vzcM9AQoqelxvS4E4KEWTOLpxgCBlhuKLPQIgkybllnVhJzZ98l_v0T4nfC_.FwOGY9kOnI_ naokh9Xa4QrMxuAOGqLwxTAAglMfE8WkHSFTE.nkRErrw9uSKEEh4GDdOILUscamk4coYrLt9Lx6 vqPtBkDd_6.Y6.qnZWj.X8jK2UIQcSx_qzxDG2K_LIua0fe5jMEIEsxYLViRFgAwKDdpp3F0Plnp TT8mF10FXhiGgqXsiL3nJ2eepWPDzAYBFfgMriRiTs4SYs.3RKD.3usFM0dtbjSiGpcyXTJMyohk rGTjFNC8aA4rzgQSkRgnt.zcsilLQghnbpoAXNwH94WSowb.joVuH6JPZkQn0TTWeNWePvOgiddR wmN0kcaNgMWrT1hC3jrbpexL9RRw24yea71obtWxkceMLPd12Jw8XL033Srjt_76nx0Nc2QkV1jh fqyRJ89swQFL1ZpgCdlVS2Nve.lYXyhEy_M_zKQA230X3UHkf11r0DolF02VK_d4MEcUi3dePMyT wodp7sGezIJZn_JFIwvRwqeEVXEI2n4pW6nqs891meMP44gqBxda5zkCDahp.VEojpv8RUV1mkMR 23RhRsaSG1sJc3WcgX92gFhnReJnte7lWnbIZG4VMmJaMJa0vZXTMrLNPiNwsmYvBeGVRZMP4xRS VNB3t9FFCeEvBrTqotusPllfWiZDv8be_ybBQkr7uGv76MUbHW9EpHVM9IclJVt3fMQXZRyEJunw AfkAYRaWBSURQMOusrQD24D1LLacL.aEZ06iJPihqG5g_6.ACdR7Poyy5q5PNBtqdZLcKAmiTiw_ xhhkzmfan6Ui18PIX_S_T7cY89aLLeA9pH.0jlcQ29worsMbpd8aMRTQauRRbQDxbYV09wwKWxrp xUh4PEI0xgT3MxmIclTOw_Bn.90Yu2gPwZm6vemmyF4VaXk7e0SMtfPzq3Y97HZFpaA3hUY0to60 z49FXR9reFd.WdnZCa3TptHMhFhvq7HhcKRui8TKKlfkLjJeUpLVvGK_SbK2DnDvqzhY2x0rN4rH LEZNXV08K8UwCpJb.qbAMT46VGWBjmDXp7cieLKf7vIh1LYZsKCLDADlfSrehv26_V2whwLuRZ3F bNUmuHt9MLvtGOM6y5JBecBOCyLx9MTEMfKwD8BWxqcY9xf.yWao.CQgIUh0ZpmwyopHbXCca_Jg 3TH48xlyKjp_GDPd0dRfU7j7OdmOF9biX7KP0PS6swlcl9eHSZ0UfoV_mf4TFYVs4O7zVBPnwcFR t5gQXxd9CBlrB4Ze0.dTST.KJYjzyGa5eBCCPXY3T_JIm5sj2Cu9YKQfpcOGCT4R9ZIOmdU_FyV4 QVxxbq0B8ZBmOamqdLcFxdLEAT8It80sgZgvme4WSYXZYUvztoOsPv.QvOHlCrm6OCgbGUJtoSlh BR6d5JzPBmQf_kcky8LdFb7ca_VJdGPcqOsLI2Q7rpStdc4l.M7.05XI1xtYKOEr5P4uiLcCz2zr VLSKLt.Usa7Hq3DhDZCfLA5HGGDlnMmFiQ59KxlNQN.M.M8qxxh3ab_p9L7ShaQRPhVfmzEAWaea 8vaDN0HO3uaCTGA60JRcLsKQguW3KOiqFX7XWcwvdPNyGakalVRrLYUUpOy3UNLWqrq_lLYVgfva jGg-- X-Sonic-MF: X-Sonic-ID: 7f432bdc-e94d-4694-b0ef-2e7f61bdab02 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 27 Apr 2023 18:58:12 +0000 Received: by hermes--production-ne1-7dbd98dd99-t5dz4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7faee7bac76a35827af86f5e9ded7a50; Thu, 27 Apr 2023 18:58:09 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Future of 32-bit platforms (including i386) Message-Id: <1792FBB2-7555-430D-A42D-8B1EDB2F0EA7@yahoo.com> Date: Thu, 27 Apr 2023 11:57:58 -0700 To: Robert Clausecker , freebsd-arch X-Mailer: Apple Mail (2.3731.400.51.1.1) References: <1792FBB2-7555-430D-A42D-8B1EDB2F0EA7.ref@yahoo.com> X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org] X-Rspamd-Queue-Id: 4Q6lPL1sjQz47mj X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Robert Clausecker wrote on Date: Thu, 27 Apr 2023 18:18:55 UTC : > I would very much appreciate if lib32 support stays in (or is = completed > in the case of aarch64). Without it, FreeBSD becomes a lot less useful > as a well rounded development system as you can no longer test code = for > 32 bit platforms. I also have a need for armv7 user space code in > particular as I participate in and maintain the FreeBSD port of a = Forth > system written in armv7 assembly. Being able to run the same code you > run on a microcontroller on a hosted platform makes it a lot easier to > test and develop. What I do for armv7 on aarch64 is to install an armv7 world into a directory tree and chroot into that world. As I understand jails also work. One can install armv7 ports and such in the alternate world. But I do not use X11 or other such so my range of experience is limited and there could be issues that I just do not know about. > As for running 32 bit kernels, I do not really have an opinion. For reference, for some examples details , including some things not mentioned: # ls -Tld /usr/obj/DESTDIRs/main-CA7-*/ drwxr-xr-x 19 root wheel 22 Jul 14 13:17:19 2022 = /usr/obj/DESTDIRs/main-CA7-chroot/ drwxr-xr-x 18 root wheel 21 Apr 25 01:50:22 2023 = /usr/obj/DESTDIRs/main-CA7-poud-bulk_a/ drwxr-xr-x 18 root wheel 21 Apr 25 01:51:29 2023 = /usr/obj/DESTDIRs/main-CA7-poud/ # more ~/do-chroot-main-CA7.sh=20 #! /bin/sh mkdir -p /usr/obj/DESTDIRs/main-CA7-chroot/dev/ \ && mount -tdevfs devfs /usr/obj/DESTDIRs/main-CA7-chroot/dev/ \ && mkdir -p = /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/poudriere/data/packages/main-C= A7-default/ \ && mount_nullfs /usr/local/poudriere/data/packages/main-CA7-default \ = /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/poudriere/data/packages/main-C= A7-default/ \ && mkdir -p /usr/obj/DESTDIRs/main-CA7-chroot/usr/ports/ \ && mount_nullfs /usr/ports /usr/obj/DESTDIRs/main-CA7-chroot/usr/ports/ = \ && env IN_CHROOT=3D"main-CA7-chroot" chroot = /usr/obj/DESTDIRs/main-CA7-chroot/ umount /usr/obj/DESTDIRs/main-CA7-chroot/usr/ports/ umount = /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/poudriere/data/packages/main-C= A7-default/ umount /usr/obj/DESTDIRs/main-CA7-chroot/dev/ (IN_CHROOT is just a personal thing: not required.) # poudriere jail -l JAILNAME VERSION ARCH METHOD TIMESTAMP = PATH main-CA53 14.0-CURRENT arm64.aarch64 null 2021-06-27 17:57:33 = /usr/obj/DESTDIRs/main-CA53-poud main-CA7 14.0-CURRENT arm.armv7 null 2021-06-27 17:58:33 = /usr/obj/DESTDIRs/main-CA7-poud main-CA7-bulk_a 14.0-CURRENT arm.armv7 null 2021-12-04 14:54:10 = /usr/obj/DESTDIRs/main-CA7-poud-bulk_a main-CA72 14.0-CURRENT arm64.aarch64 null 2021-06-27 17:48:11 = /usr/obj/DESTDIRs/main-CA72-poud main-CA72-bulk_a 14.0-CURRENT arm64.aarch64 null 2021-12-04 14:54:44 = /usr/obj/DESTDIRs/main-CA72-poud-bulk_a main-CA78C 14.0-CURRENT arm64.aarch64 null 2023-04-26 18:55:46 = /usr/obj/DESTDIRs/main-CA78C-poud main-CA78C-bulk_a 14.0-CURRENT arm64.aarch64 null 2023-04-26 18:56:06 = /usr/obj/DESTDIRs/main-CA78C-poud-bulk_a I do the building of packages from ports without doing a chroot first. But /usr/obj/DESTDIRs/main-CA7-poud and /usr/obj/DESTDIRs/main-CA7-poud-bulk_a are again directorties with armv7 worlds installed, but with: installworld distrib-dirs distribution DB_FROM_SRC=3D1 as is appropriate for poudriere using the world. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Apr 27 23:44:28 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 4Q6sln6j8nz487CL for ; Thu, 27 Apr 2023 23:44:37 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q6sln4kqkz3MQH; Thu, 27 Apr 2023 23:44:37 +0000 (UTC) (envelope-from hps@selasky.org) Authentication-Results: mx1.freebsd.org; none Received: from [10.36.2.154] (unknown [46.212.121.255]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id DFE4326033D; Fri, 28 Apr 2023 01:44:28 +0200 (CEST) Message-ID: <671d3bf6-b207-e7c5-5282-4df317193db6@selasky.org> Date: Fri, 28 Apr 2023 01:44:28 +0200 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.10.0 Subject: Re: Future of 32-bit platforms (including i386) Content-Language: en-US To: 'freebsd-arch' , John Baldwin References: From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Q6sln4kqkz3MQH X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/27/23 19:19, 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. Hi, This makes me think about all the issues about the "long" type in the past, and printf() and more, being caught when compiling TARGET_ARCH=i386 . Maybe just put the following line of code somewhere central :-) _Static_assert(sizeof(long) == 8); Will there ever be some kind of hybrid CPU systems? 4 cores AMD64, 4 cores AARCH64 and some virtual QEMU CPUs all running on the same system? I mean, the arm vs intel battle is not going to end soonish. And emulating CPUs is slow and waste electricity. Why not have one computer having both kind of CPUs, and one OS, and one harddisk? And figure out a common ABI allowing seamless task switching between them? I know there are some hard differences, but can't those be ironed out? --HPS From nobody Thu Apr 27 23:50:22 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 4Q6stT4HvWz487fs for ; Thu, 27 Apr 2023 23:50:25 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 4Q6stT2Mqzz3NVX for ; Thu, 27 Apr 2023 23:50:25 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-3f178da219bso91092405e9.1 for ; Thu, 27 Apr 2023 16:50:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682639423; x=1685231423; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Fh65SKQ9zlBzcUD2qpJ8e1x7Cw61fbKdj+CzlmBgkC0=; b=Qit0E6lojTSayakOmOlZYkDW1zXg1bxvCZ+E8YLa99qqL/UZLA424DzDbKRjrPlp2i 9ZJdYHXXHEyqTAcLmud268tffSs+oLVtK5iA71nDRvj3ztsCAvha70jLjsyXlwRJcibA cblzojUtlXwSAkZIHHFsujomvYZAz0v3vPAW6q29aDM11jkB3GQig+7jYbJV2jcT59vn OLIDSLebVhI+M/LCUNHmdTREru0IDalK7PPUDK9mBOOCJlTHybyWnPvtsPnmB23lFi8X TIMCOMWV1Uj1xvDbqCsb3BpqS1pObzuAyBi9/EPErRdQJfhMaa75GGnIrzSQBFQ8fJFn inMw== X-Gm-Message-State: AC+VfDxSX+eFJjW33c+DG2UhTIqenKR5xVzoKJevGaInM3sFTT26tmuz /uKBPjRCoZ2Yd55rVytcnLg3TnbIQXtmpb5zTvc1wQ== X-Google-Smtp-Source: ACHHUZ4Vfrhiwu0x01cLeC7gtfVO0xP2GiItwrigP9pr87l/HtLRPCCokDi+LumvQ2J9gZsgO2D5FA== X-Received: by 2002:a05:600c:2104:b0:3f1:819d:d046 with SMTP id u4-20020a05600c210400b003f1819dd046mr2657009wml.5.1682639423248; Thu, 27 Apr 2023 16:50:23 -0700 (PDT) Received: from smtpclient.apple ([131.111.5.246]) by smtp.gmail.com with ESMTPSA id f12-20020adfdb4c000000b002f9ff443184sm19590376wrj.24.2023.04.27.16.50.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2023 16:50:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: Future of 32-bit platforms (including i386) From: Jessica Clarke In-Reply-To: <671d3bf6-b207-e7c5-5282-4df317193db6@selasky.org> Date: Fri, 28 Apr 2023 00:50:22 +0100 Cc: freebsd-arch , John Baldwin Content-Transfer-Encoding: quoted-printable Message-Id: References: <671d3bf6-b207-e7c5-5282-4df317193db6@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4Q6stT2Mqzz3NVX X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 28 Apr 2023, at 00:44, Hans Petter Selasky wrote: >=20 > On 4/27/23 19:19, 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. >=20 > Hi, >=20 > This makes me think about all the issues about the "long" type in the = past, and printf() and more, being caught when compiling = TARGET_ARCH=3Di386 . >=20 > Maybe just put the following line of code somewhere central :-) >=20 > _Static_assert(sizeof(long) =3D=3D 8); >=20 > Will there ever be some kind of hybrid CPU systems? >=20 > 4 cores AMD64, 4 cores AARCH64 and some virtual QEMU CPUs all running = on the same system? >=20 > I mean, the arm vs intel battle is not going to end soonish. And = emulating CPUs is slow and waste electricity. Why not have one computer = having both kind of CPUs, and one OS, and one harddisk? And figure out a = common ABI allowing seamless task switching between them? I know there = are some hard differences, but can't those be ironed out? I don=E2=80=99t know where to start with this other than to give an = emphatic no to almost all of what you said, or at least the bits for = which meaning can be extracted. Regardless, this is not the place for = such pie-in-the-sky discussions; if you want to theorise about weird and = wacky computer architectures then please take it elsewhere. Jess From nobody Fri Apr 28 05:29:47 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 4Q71Q75QmCz4808Y for ; Fri, 28 Apr 2023 05:29:51 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q71Q64Qjbz48lX; Fri, 28 Apr 2023 05:29:50 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id CA71B89293; Fri, 28 Apr 2023 05:29:48 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.17.1/8.16.1) with ESMTPS id 33S5TmsK073164 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 28 Apr 2023 05:29:48 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.17.1/8.16.1/Submit) id 33S5TlU1073163; Fri, 28 Apr 2023 05:29:47 GMT (envelope-from phk) Message-Id: <202304280529.33S5TlU1073163@critter.freebsd.dk> To: Warner Losh cc: freebsd-arch , John Baldwin Subject: Re: Future of 32-bit platforms (including i386) In-reply-to: From: "Poul-Henning Kamp" References: <202304271732.33RHWLrw069782@critter.freebsd.dk> 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 Content-Type: text/plain; charset="us-ascii" Content-ID: <73161.1682659787.1@critter.freebsd.dk> Date: Fri, 28 Apr 2023 05:29:47 +0000 X-Rspamd-Queue-Id: 4Q71Q64Qjbz48lX X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N -------- Warner Losh writes: > > If we do, the first two questions we will get back are: > > > > 1. When does 15 happen ? > > > > Late 2025, give or take [...] My point was not so much which specific answers we agree on, as on including those answers, up front, in the 32bit deprecation notice up. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Fri Apr 28 13:46:43 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 4Q7DRV42sVz48VSH for ; Fri, 28 Apr 2023 13:46:46 +0000 (UTC) (envelope-from jhb@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 4Q7DRV23jMz3sbQ; Fri, 28 Apr 2023 13:46:46 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682689606; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bo1f6UXPwC2+M0985QuwK6C0dnd/aYOA8UsLICGuZ2E=; b=ZGZ4Od8M22V7U7EyHbeXokQTApjD91Sm9oxSaUxAzmOVBIS2Dv9FxqzsZ4qmD1aLHMd9C9 ZD+aU+44ONYg4L0DbTSxaOdhQUuYW/Ic9CJjBC5BTiLd+mQbGiM6Z4g3defmPywggujvk9 8wFLOVwcUQVjCYcZqZjxeLHXWJtnXGRE4LR+OTOk9ywduNpc5u6h4GuRIHO2IDmuWhk7VY AwY1Vko3FLZxMlF1MlZmEhzm4pmvLFPrcvaTKIw90NVzhBx+fMiGwPkJAtpHXEra/uoYg+ aMiTvtSFOxMEEXghJmLTXAcdUMSTaYL/JhuWPIrw6isNkvExo/OxGJjjUg7dDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682689606; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bo1f6UXPwC2+M0985QuwK6C0dnd/aYOA8UsLICGuZ2E=; b=d4TKMC1Fm/j39Cuh5mVaKqI1g1O11xT8RYG6vEeeh5P56xXjl1AixaR++dmcZ3vAff/NTL 8ErUxru7Lb2xN1SV6ln+P6AnZLi5WSQ8POMYgbPf9Dj4lPwsH4bRTCi1bUlaX6cvVdLMA0 Id2DLzgocrOcLJIX86gppLFmVYFL3qcB1U//608WJ25SgVr1X8XZeOj6Y72GKnOUnC4nT7 /JiXb0Oy9N+PuhNRLvqCzNzCMwvi98+aq+LtoErs6nB++hcU+zlm3lG6OQjiIr7DnqnJuJ Jttn+NtWD6Pa9Lmi6ZWfw9PvUFbTgOofPNuo6D+UBrLln6gcZBZrZmI6qfDlqQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682689606; a=rsa-sha256; cv=none; b=Ld1YveIyIdpZWp90C8NdY7DJxASYQnUxftQZMuWsc8ICUvic+OZHn2Uho0seUe8vlI+uah iHtgpn23533jVXSeZLlSOBCHOXBK4L7HTNiuxXx4gHpXgG2AMZN4m5t2mE0pUfqzoRhtdl r9g/iSgffjlBzNtrVn+nobe7/yyICpqiX1jla4ENVLYlkQ/GkfEz4PDBjew8u/jJaBSP9V HMLmybpeO4E4U3vgnhwAWL4NrcrlfwPhM/sNqv+O/spl+YdJEVDptqrIB+HjceRULDMWb2 OH0v9HRIeQpbrRtd7tiNMc438ITjp5pEqeeDW3biTKwozjTKHZ2QKe2JfUsbfA== Received: from [IPV6:2601:648:8680:16b0:24f5:8737:ed3b:1175] (unknown [IPv6:2601:648:8680:16b0:24f5:8737:ed3b:1175]) (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: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q7DRT2qXNzKgv; Fri, 28 Apr 2023 13:46:45 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Fri, 28 Apr 2023 06:46:43 -0700 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 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: Future of 32-bit platforms (including i386) Content-Language: en-US To: Poul-Henning Kamp , Warner Losh Cc: freebsd-arch References: <202304271732.33RHWLrw069782@critter.freebsd.dk> <202304280529.33S5TlU1073163@critter.freebsd.dk> From: John Baldwin In-Reply-To: <202304280529.33S5TlU1073163@critter.freebsd.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 4/27/23 10:29 PM, Poul-Henning Kamp wrote: > -------- > Warner Losh writes: > >>> If we do, the first two questions we will get back are: >>> >>> 1. When does 15 happen ? >>> >> >> Late 2025, give or take [...] > > My point was not so much which specific answers we agree on, as on > including those answers, up front, in the 32bit deprecation notice > up. That's a good point, and assuming we do settle on a consensus here, we should include some ballparks on those dates in the final announcement. -- John Baldwin From nobody Fri Apr 28 14:16:12 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 4Q7F5X3d1Fz48Wlk for ; Fri, 28 Apr 2023 14:16:16 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q7F5X1mnVz3xhm for ; Fri, 28 Apr 2023 14:16:16 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id sOsipbZY36NwhsOtTpWNFC; Fri, 28 Apr 2023 14:16:15 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id sOtRp1IMJ3fOSsOtSpCQSs; Fri, 28 Apr 2023 14:16:15 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=644bd52f a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=dKHAf1wccvYA:10 a=7Qk2ozbKAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=p6a_BlIvSOyGAhOVOIYA:9 a=QEXdDO2ut3YA:10 a=1lyxoWkJIXJV6VJUPhuM:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 557EA2EE3; Fri, 28 Apr 2023 07:16:13 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by slippy.cwsent.com (Postfix) with ESMTP id 108AF8C2; Fri, 28 Apr 2023 07:16:13 -0700 (PDT) Date: Fri, 28 Apr 2023 07:16:12 -0700 From: Cy Schubert To: Warner Losh Cc: freebsd-arch Subject: Re: Future of 32-bit platforms (including i386) Message-ID: <20230428071612.16ca02bd@cschubert.com> In-Reply-To: References: Organization: KOMQUATS X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfBm++Fo0BLE5/UnrDaM3UrucNuPcXgoOhqhqIQ/3BB32a+VFcVsdomU5ZaVLnAuifdSvEazrYoSeabKGZyxyKE3NsAGmNc0sk/GNoCAcmJQQyPNAWWmC 3NS9b3jV+bpFXXvKyHCp3ve5v1vOlqF1fdh+YJ+hnN3N4Uq8RP4eWMf/odc6Af7tv8f9iWVcQGCAr9SsuwPZMaoOSG+bW1TqOyDoTBYpz1x3MIBUMr2Z7ZI8 X-Rspamd-Queue-Id: 4Q7F5X1mnVz3xhm X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Thu, 27 Apr 2023 11:33:15 -0600 Warner Losh wrote: > On Thu, Apr 27, 2023 at 11:20=E2=80=AFAM John Baldwin w= rote: >=20 > > 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. > > =20 >=20 > I like this. "In 14.0, i386 completes its journey to tier 2 status" maybe? >=20 >=20 > > 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. > > =20 >=20 > So no freebsd-update service for i386 for 14.x, but have it for arm64 and > amd64? > That seems reasonable (assuming that arm64 works). >=20 >=20 > > 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. > > =20 >=20 > I like this idea. It states intent strongly enough that people aren't > surprised, > but weakly enough that people with strong interests can show up. One less= on > we've learned repeatedly in the past, though, is that we get a lot people > showing up saying they'll do something, but then doing nothing. The > threshold > of doing something will be actually doing it and being an active member of > the community or providing other material support rather than "Geeze, I'd > hate to see sparc64 go, so I'll fix a port or two". I'm not sure how you'd > set > that expectation, but maybe something like "we'll evaluate the responses = and > the robustness, size and vitality of those communities as input into our > decision" > which would set the bar higher, and have something vaguely measureable to > point at. >=20 > Side note: We should stop providing packages and re-built images for armv6 > in 14, even if we don't completely decommission support for it right away. > That > might prove to be a good model here as well and give us some good experie= nce > for how to do that with the other 32-bit platforms for 15. >=20 > I generally favor this idea... It's also a natural evolution of what we've > been saying > about platforms, eg you need to provide 64-bit atomics and other operatio= ns, > even if they are relatively inefficient because the base system is starti= ng > to use them. >=20 > 32-bit going away is the long term trend, and the long term goal of the > project. > What remains in doubt is the timeline to accomplish this. Many 32-bit > platforms > still perform decently well, so we should expect to see some usage. But we > need > to weigh the size of that usage against the cost of providing it. We've > seen an increasing > cost to developers to provide this over the last few years. But as the > usage drops > the cost increases because unanticipated breakages become harder to fix as > they > are discovered further and further from the breaking point. Agreed. This brings us in line with virtually all major Linux distributions, Oracle Solaris (whatever is left of it), the other major commercial O/S out there (AIX), and the other major distributions of BSD (except NetBSD). I think we need to nudge the ports team in this direction, sooner than later, though in my experience, a good percentage of packages fail to build on i386 anymore here anyway, including all browsers in ports/www. >=20 > Warner --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=3D0 From nobody Fri Apr 28 17:45:08 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 4Q7Kkk36wRz47m1N for ; Fri, 28 Apr 2023 17:45:18 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q7Kkj5tfcz4LVD; Fri, 28 Apr 2023 17:45:17 +0000 (UTC) (envelope-from hps@selasky.org) Authentication-Results: mx1.freebsd.org; none Received: from [10.36.2.154] (unknown [46.212.121.255]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A1DFC2605A4; Fri, 28 Apr 2023 19:45:08 +0200 (CEST) Message-ID: <6079003b-7df2-f3c2-f624-6fe39a1cf9c0@selasky.org> Date: Fri, 28 Apr 2023 19:45:08 +0200 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.10.0 Subject: Re: Future of 32-bit platforms (including i386) Content-Language: en-US To: Jessica Clarke Cc: freebsd-arch , John Baldwin References: <671d3bf6-b207-e7c5-5282-4df317193db6@selasky.org> From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Q7Kkj5tfcz4LVD X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/28/23 01:50, Jessica Clarke wrote: > On 28 Apr 2023, at 00:44, Hans Petter Selasky wrote: >> >> On 4/27/23 19:19, 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. >> >> Hi, >> >> This makes me think about all the issues about the "long" type in the past, and printf() and more, being caught when compiling TARGET_ARCH=i386 . >> >> Maybe just put the following line of code somewhere central :-) >> >> _Static_assert(sizeof(long) == 8); >> >> Will there ever be some kind of hybrid CPU systems? >> >> 4 cores AMD64, 4 cores AARCH64 and some virtual QEMU CPUs all running on the same system? >> >> I mean, the arm vs intel battle is not going to end soonish. And emulating CPUs is slow and waste electricity. Why not have one computer having both kind of CPUs, and one OS, and one harddisk? And figure out a common ABI allowing seamless task switching between them? I know there are some hard differences, but can't those be ironed out? > > I don’t know where to start with this other than to give an emphatic no to almost all of what you said, or at least the bits for which meaning can be extracted. Regardless, this is not the place for such pie-in-the-sky discussions; if you want to theorise about weird and wacky computer architectures then please take it elsewhere. > Hi Jess, I'd like to know why you think this is a wacky idea, to have a super-set computer architecture, where each CPU can run the full instruction set of both ARM64 and AARCH64 at the same time. You have an open invitation for a video call on FaceBook or whatever you prefer to talk about this. Send me something off-list. --HPS From nobody Fri Apr 28 18:42:09 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 4Q7M143KrYz47ps7 for ; Fri, 28 Apr 2023 18:42:48 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) (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 4Q7M132KrMz3Bs0; Fri, 28 Apr 2023 18:42:47 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-187b07ad783so317611fac.0; Fri, 28 Apr 2023 11:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682707366; x=1685299366; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tjnPXPztAhVFU6/F11FRK13RD9m+NOV6PMW4sMGMC64=; b=X437PvsCibGTMdrjO/P11zIe7gpvxQNzXPumjTPfI+hL5yqBzrNHqfTl6ZVyIaD+Cx NTNs8zxfKx7k5lOpgMFbA/AQ0nXr4f5M+50DtQoFtMDmiMyP4jQ9jKpjGP/9YOKMKpzN P+1eFRv9hL7+c0CMDipdVT9ddQLxffG5ut69Cr/Ne9IECIdA+3uJAZJfAYv3hmoBA3Yt YhTWQpkTNpzB42VZ2++aZUdp53rUbDhXSOhrkGX7sr0P4JPvzpjNK1OWmgc8vruLDpI1 vGZu9y/hg2JcT9yqhkG1G1aVSHp9gpx8l+JmEVERB9LTCV2bHr2eN2iXjuMom4uE9hyO a25g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682707366; x=1685299366; 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=tjnPXPztAhVFU6/F11FRK13RD9m+NOV6PMW4sMGMC64=; b=fLWo14ps8ROQE3EbWLE1Otnf3ubrbggXji61p6rAgUFjpygF3BFZJXIyvY9fBcLuc7 UfWWK/zadzrsWa4FiiqOi8uxJMwpRZHPkM9bmn/qkK5Snrtn4U+owzLapBwvPvw8siOe 8zSvwDa/6OYlGeKAHP5PjDLP1VOBPn7HZ8ld1C/h9Bc0KB686q/YG8vQledVxSah1YPZ 4ZSMuYHBbLdJ9f8DugHqtDjccqOl69nm6HIncnrx2BuliZnMDPHFnP7krhce0rq4DZbR ucPEUfLl/ji4/AawMcZtBM0dDdYQeAi3eLCoAPORWV8QsiqAVhoPJUE/jZzVO4umimy+ xhCw== X-Gm-Message-State: AC+VfDznr3ZgFHC7QPT7pdgTTuZlmcXqC1czlEOAUB7BR5GR7BSYSdmk Wv9mNcfC+GlknvQHYbmnHxj+UxTz2Mtp32TJOTb8c8+/ X-Google-Smtp-Source: ACHHUZ6s03OmEJ4QD5G8vnEk9SJPn7njIUiWXyp/QwLjHM4dce/gMtr8bStEieCndmIdBKRlcy4SN/JP5jxwCVG/eP0= X-Received: by 2002:a05:6870:7402:b0:18b:1c64:2d3f with SMTP id x2-20020a056870740200b0018b1c642d3fmr2761033oam.54.1682707365694; Fri, 28 Apr 2023 11:42:45 -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: <671d3bf6-b207-e7c5-5282-4df317193db6@selasky.org> <6079003b-7df2-f3c2-f624-6fe39a1cf9c0@selasky.org> In-Reply-To: <6079003b-7df2-f3c2-f624-6fe39a1cf9c0@selasky.org> From: Mehmet Erol Sanliturk Date: Fri, 28 Apr 2023 21:42:09 +0300 Message-ID: Subject: Re: Future of 32-bit platforms (including i386) To: Hans Petter Selasky Cc: Jessica Clarke , freebsd-arch , John Baldwin Content-Type: multipart/alternative; boundary="000000000000cb135b05fa69d6d5" X-Rspamd-Queue-Id: 4Q7M132KrMz3Bs0 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000cb135b05fa69d6d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 28, 2023 at 8:45=E2=80=AFPM Hans Petter Selasky wrote: > On 4/28/23 01:50, Jessica Clarke wrote: > > On 28 Apr 2023, at 00:44, Hans Petter Selasky wrote: > >> > >> On 4/27/23 19:19, 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 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. > >> > >> Hi, > >> > >> This makes me think about all the issues about the "long" type in the > past, and printf() and more, being caught when compiling TARGET_ARCH=3Di3= 86 . > >> > >> Maybe just put the following line of code somewhere central :-) > >> > >> _Static_assert(sizeof(long) =3D=3D 8); > >> > >> Will there ever be some kind of hybrid CPU systems? > >> > >> 4 cores AMD64, 4 cores AARCH64 and some virtual QEMU CPUs all running > on the same system? > >> > >> I mean, the arm vs intel battle is not going to end soonish. And > emulating CPUs is slow and waste electricity. Why not have one computer > having both kind of CPUs, and one OS, and one harddisk? And figure out a > common ABI allowing seamless task switching between them? I know there ar= e > some hard differences, but can't those be ironed out? > > > > I don=E2=80=99t know where to start with this other than to give an emp= hatic no > to almost all of what you said, or at least the bits for which meaning ca= n > be extracted. Regardless, this is not the place for such pie-in-the-sky > discussions; if you want to theorise about weird and wacky computer > architectures then please take it elsewhere. > > > > Hi Jess, > > I'd like to know why you think this is a wacky idea, to have a super-set > computer architecture, where each CPU can run the full instruction set > of both ARM64 and AARCH64 at the same time. > > You have an open invitation for a video call on FaceBook or whatever you > prefer to talk about this. Send me something off-list. > > --HPS > > It is not necessary to go to a very far distant future . Assume you have a cluster of boards with different CPUs . Then schedule execution of your programs with respect to the required CPU on this cluster . Is this possible with FreeBSD ? Is it a good or bad idea to have such a facility ? Mehmet Erol Sanliturk --000000000000cb135b05fa69d6d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 28, 2023 at 8:45= =E2=80=AFPM Hans Petter Selasky <hps@= selasky.org> wrote:
On 4/28/23 01:50, Jessica Clarke wrote:
> On 28 Apr 2023, at 00:44, Hans Petter Selasky <hps@selasky.org> wrote:
>>
>> On 4/27/23 19:19, John Baldwin wrote:
>>> For 13.0, i386 was demoted from Tier 1 to Tier 2.=C2=A0 In the= announcement
>>> of this for 13.0, the project committed to an update on i386&#= 39;s future
>>> around the time of 14.0.=C2=A0 The announcement at the time su= ggested that
>>> i386 would be supported less in 14.x than in 13.x.
>>
>> Hi,
>>
>> This makes me think about all the issues about the "long"= ; type in the past, and printf() and more, being caught when compiling TARG= ET_ARCH=3Di386 .
>>
>> Maybe just put the following line of code somewhere central :-) >>
>> _Static_assert(sizeof(long) =3D=3D 8);
>>
>> Will there ever be some kind of hybrid CPU systems?
>>
>> 4 cores AMD64, 4 cores AARCH64 and some virtual QEMU CPUs all runn= ing on the same system?
>>
>> I mean, the arm vs intel battle is not going to end soonish. And e= mulating CPUs is slow and waste electricity. Why not have one computer havi= ng both kind of CPUs, and one OS, and one harddisk? And figure out a common= ABI allowing seamless task switching between them? I know there are some h= ard differences, but can't those be ironed out?
>
> I don=E2=80=99t know where to start with this other than to give an em= phatic no to almost all of what you said, or at least the bits for which me= aning can be extracted. Regardless, this is not the place for such pie-in-t= he-sky discussions; if you want to theorise about weird and wacky computer = architectures then please take it elsewhere.
>

Hi Jess,

I'd like to know why you think this is a wacky idea, to have a super-se= t
computer architecture, where each CPU can run the full instruction set
of both ARM64 and AARCH64 at the same time.

You have an open invitation for a video call on FaceBook or whatever you prefer to talk about this. Send me something off-list.

--HPS


It is not necessary to go to a very = far distant future .

Assume you have a cluster of bo= ards with different CPUs .
Then schedule execution of your programs = with respect to the required CPU on this cluster .

Is th= is possible with FreeBSD ?
Is it a good or bad idea to have such a f= acility ?




Mehmet E= rol Sanliturk


=C2=A0
--000000000000cb135b05fa69d6d5-- From nobody Sat Apr 29 00:17:32 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 4Q7VSF2GVmz48B4r for ; Sat, 29 Apr 2023 00:18:21 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q7VSC55Thz3vTg for ; Sat, 29 Apr 2023 00:18:19 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=juniper.net header.s=PPS1017 header.b=qC2x1zeq; dkim=pass header.d=juniper.net header.s=selector1 header.b=HYpPIW3u; spf=pass (mx1.freebsd.org: domain of sjg@juniper.net designates 67.231.152.164 as permitted sender) smtp.mailfrom=sjg@juniper.net; dmarc=pass (policy=reject) header.from=juniper.net; arc=pass ("microsoft.com:s=arcselector9901:i=1") Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33SF16xX032283 for ; Fri, 28 Apr 2023 17:18:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=A3Ew79X0MQVqbkufQkXtiYjvDznKWHo7aR3zqZaxtyE=; b=qC2x1zeqKAMevONgl71At54EYBJp41/zZdzQqErKdWJxhY0pxyIaWF7ZDg6wSHrqGk+V HAO9l5OlfYZfjMsQQ+/WdLGHur58afhS1JeuD49z+IHbw8Hp45kFQnhtRMsWnERUZiy1 6m3mAJjJ+NwDjmCjMeCKzUVF5phodYjoZ2qR8g0eRTofltB62J1c2HwogdnWqI8uwSXM nqFABMeQPfVe5YJk8FrqYtVwO8A0CGVpkXhvfidCRDhdzREt2FQ3dy+NRWhcxZ/UXN6O RpkEIVn49wKDeCaZKlw3f0lrgc79HzFJIwQbLzEkAePun4NuMsIr+7LQEeZjHTQNjwbX +Q== Received: from mw2pr02cu001.outbound.protection.outlook.com (mail-westus2azlp17012027.outbound.protection.outlook.com [40.93.10.27]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3q8gdh8xp4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 28 Apr 2023 17:18:18 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TK7Z2P/kEN2xUP+fBMvvPmFdqulTZDCQBv1xcgLBCfaLOn/vTByQ7LpZu0tA/NnlN/E5tseIdAE/prcUaBOZ8RFej6jWGOh/GgUoMQSJnw3IReHLd0joFf8l/iCDHad/ymFb1NvooDBY9WQtCMHHoU6CFsnRK/qy6ZHJ3tHUASLJnzMOaspPFpy+XokdwFs97OBNCrMTJ6HSUxxSpyYLo7h0Ez8MziqYSYdN7CvWCmfreqPgCTqTm331/gvoLUAp84hi7t4poGC7IV2/IH5sHTwwXh3bcAxoL3vKD25BvzR3W6ccayXr+1Ea41+E+pGwrV/P7fCbWcvFGOI9rljsSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A3Ew79X0MQVqbkufQkXtiYjvDznKWHo7aR3zqZaxtyE=; b=UgbsueJ96HwlnQBXwlpEakTrNjS5MYMFjI5W60OfbQKt7wk4jSMfseMrXDQ7NCYUvDovfttOR1c/msG8xqb2Oa7AOcYWVuHvjU80t9znA/xK7Ekkdg8IlTcIX/40bis9aNzMUI+jDlne9ZEO0MlniFEpi+iBZY4wgs4Qqw0nhuFVC28t8fNJxsKoA5Rb965uq4vL/4y5jviC8aEzv9m8GYF6asfA2zgsEDn9yvHRcFTfWdqNysVs83AzDbbvwzdMngOMKmWxJHklhpfuV7f4jBKmM5oF2WEyeYKs/ilh5IntGqExsfFtTi33W55VkKK5Drmq6aTz4tbszazobimxkw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.14) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A3Ew79X0MQVqbkufQkXtiYjvDznKWHo7aR3zqZaxtyE=; b=HYpPIW3uXBEYt2AnuU5V7WjheTny2mXilGa7Nnfp76GuO2B6wu++1j4ujbtOusbcwA8HVQ93hXYkI7rAW26rP12xkjotpzrvYh96TvOAAHBAHneqH+cxjqFCq8yy5VAOLWJNq0tQXiqFABdith3VbORUuLICD/MJF35O0UQnAlI= Received: from MW4PR04CA0252.namprd04.prod.outlook.com (2603:10b6:303:88::17) by PH0PR05MB8255.namprd05.prod.outlook.com (2603:10b6:510:b0::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6340.22; Sat, 29 Apr 2023 00:18:12 +0000 Received: from MW2NAM12FT107.eop-nam12.prod.protection.outlook.com (2603:10b6:303:88:cafe::99) by MW4PR04CA0252.outlook.office365.com (2603:10b6:303:88::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6340.24 via Frontend Transport; Sat, 29 Apr 2023 00:18:12 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.14) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.239.14) by MW2NAM12FT107.mail.protection.outlook.com (10.13.181.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6363.12 via Frontend Transport; Sat, 29 Apr 2023 00:18:12 +0000 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7; Fri, 28 Apr 2023 19:18:10 -0500 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7; Fri, 28 Apr 2023 19:18:10 -0500 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7 via Frontend Transport; Fri, 28 Apr 2023 19:18:10 -0500 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 33T0I9vB022020 for ; Fri, 28 Apr 2023 17:18:09 -0700 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id E243A88191; Fri, 28 Apr 2023 17:17:32 -0700 (PDT) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id E1C6287DF1; Fri, 28 Apr 2023 17:17:32 -0700 (PDT) To: 'freebsd-arch' CC: Subject: Re: Future of 32-bit platforms (including i386) In-Reply-To: References: Comments: In-reply-to: John Baldwin message dated "Thu, 27 Apr 2023 10:19:59 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.2 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 Content-Type: text/plain; charset="us-ascii" Content-ID: <78152.1682727452.1@kaos.jnpr.net> Date: Fri, 28 Apr 2023 17:17:32 -0700 Message-ID: <82207.1682727452@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MW2NAM12FT107:EE_|PH0PR05MB8255:EE_ X-MS-Office365-Filtering-Correlation-Id: 6445dd96-541c-4bd0-0cef-08db48473814 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xAPluAzDaPChXiTXYRqyxZND8V8InJbbLAr7gRcIsxSsxnoRO30M2FUaMI/sqwAQGDou7IVZLWDaVx0T5U5AjLSmmDC9ha7PrYA8eXOKQ0LDjWBPSOkj3b7bCG8GGveHKBEk5yBUdorgB12j+7oC1N2L6uQVGPJfnhxqA/Fj2VMUnyeI+6fQiLLeQAzdqG8QEMP2nKcCuzvpuRQOQndAXSKmiLQSEf2mRXYxL7LZj4Rwxo+Nm5WDydMSjWDgU62LArM2bLAjAA/xqXF26DWB/3ACqzKor0CAOEXEJvl9r8C3GQ22RGe0H0y8XPO0+5lJHp5Om+lpsbJoa05N3M0GUhyuGQdlCIdjj2V5HhDIUWyXM+rHLfwRnhu97ItOuI6lGospPRl4wMBvkdYhqJC30iUM6hHP3zHKNycsh6M7j2WiskdGnE66k53OgFlOV6pX1PpDnNCrviukIe81SHvMHsiSKHAzOQKTwZrGN0qkUoGQrI2jC8xZFYBoVVrQ7y5v+1S71cJ9fn7r65Ag3JtdEuoPSteN0X15P1yRa52e+mK1HAcDof18RQ5oUmCv92FJb2AWIdRd8QnqLOr8PbZ+yYD+3kpgy1MCwpSWxO9if3jA3htRCtqp/IG5KLWKH0be9INBSN+xyM+rftzmYiXfJdKsKE1ix3gAxXYYSNeFogxDRIfu0gvDydgnFA5+8Ff9RJ13fzNBxGOKzry0bQvfov3kHJLH8rdzuV7x0a3dt5J22lRoIJok4JsK6gCHDwqvvGAm9u8nvx8pRkYsiJqpA6CU0Mxr8JGENZmz3rwidXM= X-Forefront-Antispam-Report: CIP:66.129.239.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230028)(4636009)(136003)(346002)(376002)(396003)(39860400002)(451199021)(46966006)(36840700001)(40470700004)(55016003)(40480700001)(40460700003)(478600001)(4326008)(6916009)(70206006)(7696005)(70586007)(8676002)(8936002)(82740400003)(41300700001)(316002)(5660300002)(356005)(81166007)(186003)(336012)(6266002)(47076005)(36860700001)(107886003)(7126003)(9686003)(26005)(82310400005)(86362001)(2906002)(4744005)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2023 00:18:12.3304 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6445dd96-541c-4bd0-0cef-08db48473814 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT107.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR05MB8255 X-Proofpoint-GUID: 17MeA-sjzbKQrwQi2FuL-XLo0kInKTBZ X-Proofpoint-ORIG-GUID: 17MeA-sjzbKQrwQi2FuL-XLo0kInKTBZ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-28_08,2023-04-27_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 priorityscore=1501 malwarescore=0 bulkscore=0 adultscore=0 lowpriorityscore=0 phishscore=0 impostorscore=0 suspectscore=0 spamscore=0 mlxscore=0 mlxlogscore=555 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304290001 X-Spamd-Result: default: False [-5.08 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.979]; DMARC_POLICY_ALLOW(-0.50)[juniper.net,reject]; R_DKIM_ALLOW(-0.20)[juniper.net:s=PPS1017,juniper.net:s=selector1]; R_SPF_ALLOW(-0.20)[+ip4:67.231.152.164]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[67.231.152.164:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWELVE(0.00)[12]; FREEFALL_USER(0.00)[sjg]; RCVD_IN_DNSWL_NONE(0.00)[40.93.10.27:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[juniper.net:+] X-Rspamd-Queue-Id: 4Q7VSC55Thz3vTg X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N John Baldwin wrote: > A larger question is what to do about 32-bit platforms moving forward. FWIW while we do not use i386 kernels anymore compat32 support is very important. Some of our daemons are very pointer heavy and up to a certain scale point, a 32bit app is more memory efficient, of course the 64bit version can scale much bigger but many customers do not need that. --sjg