From nobody Tue May 30 14:36: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 4QVw2r6FN5z4Xbk1 for ; Tue, 30 May 2023 14:37:08 +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 4QVw2q3SKLz4T1r; Tue, 30 May 2023 14:37:07 +0000 (UTC) (envelope-from hps@selasky.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org; dmarc=none Received: from [10.36.2.145] (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 BD6712600D3; Tue, 30 May 2023 16:36:59 +0200 (CEST) Message-ID: <6dd8a279-1ccf-ea66-9009-3865a7865e1a@selasky.org> Date: Tue, 30 May 2023 16:36:58 +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.11.1 Subject: Re: Future of 32-bit platforms (including i386) To: Tomek CEDRO , Peter Jeremy Cc: Warner Losh , freebsd-arch References: Content-Language: en-US From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-2.92 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.89)[-0.894]; NEURAL_HAM_MEDIUM(-0.72)[-0.724]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; TO_DN_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[selasky.org]; RCPT_COUNT_THREE(0.00)[4]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4QVw2q3SKLz4T1r X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On 5/26/23 17:31, Tomek CEDRO wrote: > Thanks Peter.. I know 64-bit is now easier to maintain both in > software and hardware domain.. I just don't like "Enforced Changes > Ideologies" so things that worked well needs to be "just deleted and > replaced".. in most cases this is what destroys our current world.. > its like history rewrite.. maybe marking code as "obsolete" / > "unsupported" / "abandoned" just for anyone ever wanting to play with > the code ever again rather than removing the code and leaving nothing > for the future.. I don't know what are the plans but I think code for > porting to other platforms should be preserved for various reasons > even when obsoleted it will be solid source of knowledge 😄 Hi, I want to add, there are consumers of FreeBSD kernel code, like RTEMS and QNX. If someone wants to maintain for example the Network stack for a 32-bit platform outside of FreeBSD, how is FreeBSD thinking about that? What is the plan there? Instead of 128/64/32 -bit support it will be 128/64 -bit support (thinking about CheriBSD)? If 32-bit CPU and platform technology patents are about to expire, then keeping 32-bit support around could be a scoop for FreeBSD, even though 32-bit PC platforms are a patchwork of technologies, going from ISA, PnP to PCI and USB. Citing Warner Losh: > contains Intel's plans for the future. They have removed support for booting 16/32-bit and non-UEFI from their firmware as of 2020... And it is also well known how secure boot works, and allows Intel to control who can use their hardware components or not. I would not be surprised at all, if in the future, you would have to pay serious money to boot FreeBSD on desktop computers. Apple has already been doing this for many years. Given secure booting is not defined for 32-bit platforms, is this a strong argument to keep 32-bit support around? Personally I would see it as a big step backwards to boot up Windows or Apple first, then run VirtualBox or VMware, and then login to FreeBSD. Not only would it require you to constantly pull system updates for two systems, but it will totally screw performance. --HPS