From nobody Tue May 30 18:57:17 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 4QW1q84h8qz4Y08Y for ; Tue, 30 May 2023 18:57:24 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QW1q82bZhz42Nd; Tue, 30 May 2023 18:57:24 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 34UIvI0T005079; Tue, 30 May 2023 13:57:18 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1685473038; bh=ZelSfpB12mSe9wgwORvHkQB6NAazAHCkrwQ8fQh6yH4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=nUQGFKyiz0Rmjr5z0HS12pPJYHnYZr3ED/pZNC+718V9NXRrtwUhQU4Fi7OYhUrEQ 5xtXOgqdUh91md9VztwxSC2Xv3VYEs8zgTVXoGW9FlrexBWsGhbW7T5mRTz0/dAuG5 1w4Z3YGlkKO8nra2XBw3ZQMwjX+6x6/4BkwPD9JQzKxspBUE3K/vmLs5A90Jy7eqZr CRabNyAjfofEGB76Bg/77X8Imy15W3blQlXTfTtu/7mRAwg43ZCtcSIjvk6NRe4ZL3 XGDRFo+fZy/Z0wH0hmkopGZR2wujW5Ed/bHJ9xpODeKZyb+GxcXONVBBbloF16JFO4 vsoBNJVwXTZPA== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id GM4JEg5HdmTVEwAAs/W3XQ (envelope-from ); Tue, 30 May 2023 13:57:18 -0500 From: Mike Karels To: John Baldwin Cc: freebsd-arch Subject: Re: Future of 32-bit platforms (including i386) Date: Tue, 30 May 2023 13:57:17 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: <2FA8A693-13A0-4540-A49B-79B694FFBF1D@karels.net> In-Reply-To: <018790e3-3ede-2397-651a-69cc7567e903@FreeBSD.org> References: <6dd8a279-1ccf-ea66-9009-3865a7865e1a@selasky.org> <018790e3-3ede-2397-651a-69cc7567e903@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; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4QW1q82bZhz42Nd X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 30 May 2023, at 12:55, John Baldwin wrote: > On 5/30/23 7:36 AM, Hans Petter Selasky wrote: >> ... >> 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? > > Folks are more than welcome to use bits of FreeBSD in their own codebases, > but FreeBSD is not obligated to maintain those bits in other codebases. > The healthy relationship there is for those consumers to engage with their > upstream (FreeBSD). > >> Instead of 128/64/32 -bit support it will be 128/64 -bit support >> (thinking about CheriBSD)? > > CHERI is not full 128-bit integers (e.g. long and addresses are still > 64-bits), so it's not quite as large a gap as 32 vs 64 (though is close). One advantage of having at least one 32-bit system as part of the build is that it finds mismatched/non-portable use of integer types and format strings. If there is no real 32-bit platform worth updating, maybe we could include a “null” 32-bit port, e.g. one without machine-dependent code other than headers? It could be based on i386 or armv7, but obviously would not include a full kernel. It could potentially include stubs to allow the kernel to link, but just generating object files for the MI parts would be valuable. Does anyone have any idea how much work this might be? If we have the ability to build 32-bit user-level binaries with -m32, the kernel or kernel objects would be the main addition. Mike