From nobody Mon Oct 5 10:17:25 2026 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 4hywLR6cnNz6k4Lt for ; Mon, 05 Oct 2026 10:17:35 +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 4hywLR0HHyz4RtW for ; Mon, 05 Oct 2026 10:17:34 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk; dmarc=none Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 94BAA9CCB3 for ; Mon, 05 Oct 2026 10:17:25 +0000 (UTC) Received: from phk (uid 488) (envelope-from phk@critter.freebsd.dk) id 2812d by critter.freebsd.dk (DragonFly Mail Agent v0.13+ on critter.freebsd.dk); Mon, 05 Oct 2026 10:17:25 +0000 To: Yuri Tkachenko cc: freebsd-arch@freebsd.org Subject: Re: [RFC] Kernel-Enforced Jail Scoping, Lifecycle States, and Automated QoS/Cleanup 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <32447.1791195445.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 05 Oct 2026 10:17:25 +0000 Message-Id: <6ac37935.2812d.70f392a1@critter.freebsd.dk> X-Spamd-Bar: / X-Spamd-Result: default: False [0.50 / 15.00]; HFILTER_FROMHOST_NORESOLVE_MX(0.50)[s2gw.ddhf.dk]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FREEMAIL_TO(0.00)[gmail.com]; FREEFALL_USER(0.00)[phk]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[freebsd.dk]; RCVD_TLS_LAST(0.00)[]; ALIAS_RESOLVED(0.00)[]; MISSING_XM_UA(0.00)[] X-Rspamd-Queue-Id: 4hywLR0HHyz4RtW -------- Yuri Tkachenko writes: > When containers crash or orchestrators abort unexpectedly, this userland= -centric > approach frequently leads to orphaned VNET interfaces, zombie ZFS datase= ts, > and stale rctl rules. > [=E2=80=A6] > To solve this, I've put together an architectural RFC for a kernel-manag= ed > lifecycle framework. [=E2=80=A6] My considered opinion is that this proposal suffers from the "everything i= s better/easier/smarter in the kernel" misconception which is almost directl= y the opposite of UNIX philosophy. Yes, when things go wrong in userland, you can end up with debris, which you, crucially, have to the tools to properly dispose. If you tangle all this up in the kernel, you'd better hope nothing of the sort ever happens, because you will have no other cure than a reboot. Not a fan. -- = 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 Tue Oct 6 03:06:08 2026 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 4hzLk94ZJ0z4nCKH for ; Tue, 06 Oct 2026 03:06:09 +0000 (UTC) (envelope-from jhb@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzLk944Zpz4dPj for ; Tue, 06 Oct 2026 03:06:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791255969; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=jRn9CBbp7tvzKL52rOPOv1AqBMdgfEUi+B4pnYP6dXE=; b=ws1PE0TDj0pumIK0sKTUoIeOa6g7b+meAywJuFCtJYUqNHjz6KJnOs7/m147AZKmn+JC5B gLs1QLG6bxjJa+xDdIN3nclYtIo6K/Fv/SSCXXYWhNi1gyskr8PAY+6U10swOQbch0paTm fROZuDfgGud4mUrF0BqNX//0QtJ6sh5KWFlgJSe1+cnTmVA5uXYzREB9LC1MeYWo/HNXuL y4suBjLdJny+Zhu411afWdQfRdXSNp9sTKcle+kJVrQWx3EUAsgWL1QNhDmWZoTd1BPE9T VDR+ToZ7rx37N9vg525SpVMuRkib5ZbsO0VQFEceB65qDyuQ7EyuSfU2tg/1UA== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791255969; b=bE229oXabvH4YxMxMageeVPamEIioP0FznRoAQ+/EdYp8KwXd7l4d0SwHGriK5XksWiSr3 haGp6LwCSK3JiPEu0LCrvUo909ZlbfFBQkRvKoBDjoyXrHmI9F5C1b3voqxJKwBC8eOm57 uYfPV1OVq6u1tz3qDO1HlIqW2v7HGQd3x4j41XIEk4hWluNIZbMMyNRwuDBOf6KnR87XHR npHoFP8xQ8XoqLpGfc9U9xu5LuYoJzYz1DzUnPQd7DGk3N5QvGzsQtWeIrQswdDdusWMHt JT5Xxu94KJTmqvRKDsS9mGf9pcze+9AUhOX2JMIWpOBLhR9lLOaTsw47xsz1pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791255969; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=jRn9CBbp7tvzKL52rOPOv1AqBMdgfEUi+B4pnYP6dXE=; b=D3wJ70IUPu1ACkVewFUD8xsemJws9nbCwOblhOgGr8E+rdPaB6KOVuTL1rzvko2kyegHc5 sMFTNmoQZotm0ZjkmbIHynvVuqR+Km3y6TLtJfMsOpxRuZbZhG1KI+q/wgSDkeEza17qA0 kaeXeD5g/xDVMd4YzBVpIp9YrRVPuYEzfGcXxQWwhkcaLDoAtmvS5Fnxgrmokk/aBtF2WJ o8CXgj4KLF1O/m6/SiXVwL6JA+8artbh7ZTwGU8/zqoSjNeaIVaDMkk3pphbdP6jv3JvoU GYydZEdogyBWhxFIF7ZpAEUixao7LVoj0q4+8nROlYrROiSSA6Ay4vWpnlkkYw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2601:5cc:4402:82e0:61d0:4b4e:3a7c:9ca8] (unknown [IPv6:2601:5cc:4402:82e0:61d0:4b4e:3a7c:9ca8]) (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 4hzLk92Gm4zrY7 for ; Tue, 06 Oct 2026 03:06:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> Date: Mon, 5 Oct 2026 23:06:08 -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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: freebsd-arch@freebsd.org Content-Language: en-US From: John Baldwin Subject: i386 kernel removal Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit After some threads on the committers mailing lists a couple of months ago, srcmgr@ agreed to modify our original schedule for deprecating some platforms back in 15.0 and to go ahead and remove i386 kernel support from main. Towards that end, I have been working on a branch for the past month or so trying to find all the bits and bobs associated with i386 kernels into a somewhat-organized list of commits. The recent fixes to acpi_timer(4) and the removal of older APM BIOS bits were part of this branch, and there are some more cleanups/fixes before the actual commit to remove most of sys/i386. At this point, what would be useful is for other folks who are familiar with i386-specific to look at the set of commits I have so far and maybe point out other things I have missed that should also be removed. I also have some open questions and things I'm specifically not doing: - The last few commits in this branch around stand/ I'm less certain of as it may still be useful (for example) to continue support booting FreeBSD/i386 guests in bhyve via bhyveload. So, in general I'm not sure how far down the path we want to go in removing stand/ support. Perhaps /boot/loader makes sense as if you want to boot an older version that has a kernel you probably want to use /boot/loader from that version. bhyveload is the tricky bit here I think. - I have made no attempt to "move" anything out of sys/x86. For most things that are there I don't think the churn is worth it to move them into sys/amd64. There are a few headers which are now only used on amd64 for which it may make sense to move to sys/amd64/include in the future. - Once the kernel is gone, i386 worlds can now only run under an amd64 kernel. This means we could adjust the ABI of i386 perhaps to assume the amd64 baseline (SSE2, etc.). We already assume 64-bit atomics via cmpxchg8b. This would be equivalent to using the lib32 library builds (e.g. specialness around FSBASE/GSBASE in lib32 is something we might want to enable for plain i386). I have not done any of this and do not intend to make any such changes in this branch. - I have not stubbed out i386-specific things in userspace that won't work without an i386 kernel (e.g. i386_vm86(2)). The amd64 kernel will already fail these things, but there might be i386-only programs or daemons similar to apmd(8) (recently removed) that my branch doesn't yet remove that should be on the chopping block. If you know of something I'm missing, please let me know. - When device drivers were not specifically tied to i386 just only made sense / were enabled on i386, I have split removing those out to separate commits to make it easier to fetch them out of history in the future if they are ever needed for some other architecture. - I'm currently stuck keeping sys/i386/linux as libsysdecode uses it for SYSDECODE_ABO_LINUX on i386. Probably I should just change the i386 build to use the amd64 linux32 tables instead. You can see the current branch here (note that I frequently rebase it): https://github.com/freebsd/freebsd-src/compare/main...bsdjhb:freebsd:rm_i386_kernel -- John Baldwin From nobody Tue Oct 6 03:23:51 2026 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 4hzM6x1wtNz4nDtm for ; Tue, 06 Oct 2026 03:24:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzM6w2KwSz4g9x for ; Tue, 06 Oct 2026 03:24:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20251104.gappssmtp.com header.s=20251104 header.b=sEkAQ9WG; arc=pass ("google.com:s=arc-20260327:i=1"); spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::102d) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-3a02551822eso338122a91.1 for ; Mon, 05 Oct 2026 20:24:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1791257042; cv=none; d=google.com; s=arc-20260327; b=YurDUnLSSusAToOwDjLdjFc/0qUSzv8gIRKPgRBU0GHFfFEOynYa+6vXpH9rFFCtBS YSseTsxQMwcyoMmtWPLeTVEwnMvBgMJerXZZpLhMPZR2jL7AZUMjbml1BiGmRjsrH7iH vy6rT2WSC+la2QNkLBC2Rj2+WoFiltjzBHrdNsPfPVSwn1P75S20jJCGEuvL2lLXhMTs PJsiY8xZeevxK58Am2otyCQy/4OuusYiEVNjDKsXsI8sYKtsrAXIZO7gimnskUpw3QLr oNXJJA6D29S8HwASZNwn84QU7fEV7Q9j3eugVsUJ/UXcztvmzlVjiGS7+bFy/wxYv9an RU/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=IQjfzsAvMHrnvDO0O0ZMZ2GnGCrDsIrS2zZYVRiPMkM=; fh=RGNtlpVAmThvElEyWB7xUQNmlxr67eL769wK06jQXF0=; b=k2EEWa4QvS9n43doMGO2AB9cctIzAzOgQ+0vY+5yucV7QApPBRR+3LBWGRux7QsF8/ bctut2g5rHaqHPBKykS0PVlFtOoGyrlgGZtCRVe74BF39Cyx/sKtyyvTts+Gxxvl2gwC 7vt1TbCgnR4RJvGY93iHvpLcUzBWZzz/iyY6woqsvSPry5vBHC7Z5V+4T76o7tmo/xu/ Nf0vLDmqmBcXN3Gg97zZB3bXeGZe/Lf0Xsl5TIaGcALZOmEovbLaQ4FtMW+IfF773IUI 7XztQBBLhDE8L9rWBobNGHyWMHe9S0m+woT7708abrxh29HLVauzJby33TcC2LKyJFar wVpA==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20251104.gappssmtp.com; s=20251104; t=1791257042; x=1791861842; darn=freebsd.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=IQjfzsAvMHrnvDO0O0ZMZ2GnGCrDsIrS2zZYVRiPMkM=; b=sEkAQ9WGR7tVSgsqMqXrLLdcTAKyL+hEPiNX/pdx/FGssyTFutkK/hRtRa7X89iYVd 2vfM2cbsvZjO7vXDQ0X1rBDJgzrE8+6u2go3/kl8CRIV5CW/BcrG3Dt1IhuUxSWTWz+O 9FQccVMS3nx7WTg0qXe6QuGkWs93U45rFRWJ9JB+EFvLmzCe7t5UTUHJVMQAF3bmPQqm qvX9QZL8fhvqCkU3d9+zLjK12RLqb0ql1EgLYvM55kocSVnmt/+I6CagRPGqKt4o/8nY kTMTYZYlh8GNm/e3f2uflx52TaPTCprdMtjy+4t3Vfdg2w0aMJ/ppb6wMAlc01HG2f+S DBUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791257042; x=1791861842; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=IQjfzsAvMHrnvDO0O0ZMZ2GnGCrDsIrS2zZYVRiPMkM=; b=s6Gz+ajo4hPex7rrpx47z2jolSuN4tix12rXOHxKU1LZ+x3j/nY28WQwUawaU9KCaj BnVLqCmeN51XcL6c9ZmUJ0x/+/OqqJ4/VuAHXns1ffCRuqZOxwlYW2hude92C/Tld1pj /EBZjoP2IsGBqtjSxhg9nFF+kXfA8v+lLHAYALOPsizf7k0X5LU9nqCLM5sv4i7Ue8C0 TftHcfJIQxgQInTSjazmZrVz7O5U+MNE1/bb6iLqvOsbSMVYJ9VOL7jtHIyrmmhVjsok jNyhsmLWOSA2oizG8P7KnanOUew2tlJE/gj+qZd/7/AmRimXLieOZYen2MPWGKR4OTdo 0Qyg== X-Gm-Message-State: AFq9FYLZ+MtsCuTzKmhzNJ786DOBUHi+9542rhhGPNh1DwnkTu45FOna IWqrLlPg6HMtfp88MlyPvnmHLxnw6VQVfVYMdrlbX55CXsd7+AUM1jRBM/MRigxUuoRCPITwEe5 9RmvCsXg524DGE1TddHKtr0qKSkiM2IHHVMcAOGIzFRTMHzemrdL+BaM= X-Gm-Gg: AYBFou0jkh+0Fk4DyalpqVg0tBu7T0H47mlfGFs8tdWxmTeuHu0+mWSTqzI0Mdxiev1 8X2Xqyr6rjeF04kb0rf2je7on6QB54xhWdnzEweDyj3j4sW1M2LFP/Xa5qh2dFdR1DIqchz8eo2 P2UmBJy2fl4lw31jXmp/bnMhH+TF0VvKUerQBbnrEYvmAApFZ0VfMQYHTbUjm3G+WXVoqnUk6Zl Rv/9MBZismnEpYdJcA1lfoyw8d9YMEdzgD64cD6jb2zJDIm9VXsIqb98qCKkDkxSPNu5bxV1kok H4t1p6PGVkObL0rfN4dYkwT/cUI+NctljFOAf6LqeugYQwLkUWpnpCpcWlnX3ZO4olChdiUKIyw KojjJDkxvwQ== X-Received: by 2002:a17:90b:4ec5:b0:3a0:eaf4:a435 with SMTP id 98e67ed59e1d1-3a85464b6ecmr1204363a91.46.1791257042111; Mon, 05 Oct 2026 20:24:02 -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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> In-Reply-To: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> From: Warner Losh Date: Mon, 5 Oct 2026 21:23:51 -0600 X-Gm-Features: AclHuK8F8O8FwW_JXdIXeRg8flYOzxcrcfv5nld-aXuITAECJB4gOMy39aIMVDw Message-ID: Subject: Re: i386 kernel removal To: John Baldwin Cc: freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b2621e065d238736" X-Spamd-Bar: - X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_ALLOW(-1.00)[google.com:s=arc-20260327:i=1]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20251104.gappssmtp.com:s=20251104]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102d:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20251104.gappssmtp.com:+] X-Rspamd-Queue-Id: 4hzM6w2KwSz4g9x --000000000000b2621e065d238736 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 5, 2026 at 9:06=E2=80=AFPM John Baldwin wrote= : > After some threads on the committers mailing lists a couple of months ago= , > srcmgr@ agreed to modify our original schedule for deprecating some > platforms back in 15.0 and to go ahead and remove i386 kernel support fro= m > main. > > Towards that end, I have been working on a branch for the past month or s= o > trying to find all the bits and bobs associated with i386 kernels into a > somewhat-organized list of commits. The recent fixes to acpi_timer(4) > and the removal of older APM BIOS bits were part of this branch, and ther= e > are some more cleanups/fixes before the actual commit to remove most of > sys/i386. At this point, what would be useful is for other folks who are > familiar with i386-specific to look at the set of commits I have so far > and maybe point out other things I have missed that should also be > removed. > > I also have some open questions and things I'm specifically not doing: > > - The last few commits in this branch around stand/ I'm less certain of > as it may still be useful (for example) to continue support booting > FreeBSD/i386 guests in bhyve via bhyveload. So, in general I'm not > sure how far down the path we want to go in removing stand/ support. > Perhaps /boot/loader makes sense as if you want to boot an older > version that has a kernel you probably want to use /boot/loader from > that version. bhyveload is the tricky bit here I think. > I'd hold off on this. The benefit is small, and there's a couple of use cases still around. We've had a long-term stable interface here. Booting 14 and even 15 should work for the foreseeable future. We have to use 32-bit mode in the loader to boot amd64.... The rest looks fine. Warner > - I have made no attempt to "move" anything out of sys/x86. For > most things that are there I don't think the churn is worth it to > move them into sys/amd64. There are a few headers which are now > only used on amd64 for which it may make sense to move to > sys/amd64/include in the future. > > - Once the kernel is gone, i386 worlds can now only run under an amd64 > kernel. This means we could adjust the ABI of i386 perhaps to > assume the amd64 baseline (SSE2, etc.). We already assume 64-bit > atomics via cmpxchg8b. This would be equivalent to using the lib32 > library builds (e.g. specialness around FSBASE/GSBASE in lib32 is > something we might want to enable for plain i386). I have not done > any of this and do not intend to make any such changes in this branch. > > - I have not stubbed out i386-specific things in userspace that won't > work without an i386 kernel (e.g. i386_vm86(2)). The amd64 kernel > will already fail these things, but there might be i386-only > programs or daemons similar to apmd(8) (recently removed) that my > branch doesn't yet remove that should be on the chopping block. If > you know of something I'm missing, please let me know. > > - When device drivers were not specifically tied to i386 just only > made sense / were enabled on i386, I have split removing those > out to separate commits to make it easier to fetch them out of > history in the future if they are ever needed for some other > architecture. > > - I'm currently stuck keeping sys/i386/linux as libsysdecode uses > it for SYSDECODE_ABO_LINUX on i386. Probably I should just > change the i386 build to use the amd64 linux32 tables instead. > > You can see the current branch here (note that I frequently rebase > it): > > > https://github.com/freebsd/freebsd-src/compare/main...bsdjhb:freebsd:rm_i= 386_kernel > > -- > John Baldwin > > --000000000000b2621e065d238736 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 5, = 2026 at 9:06=E2=80=AFPM John Baldwin <jhb@freebsd.org> wrote:
After some threads on the committers mailing lists a couple= of months ago,
srcmgr@ agreed to modify our original schedule for deprecating some
platforms back in 15.0 and to go ahead and remove i386 kernel support from<= br> main.

Towards that end, I have been working on a branch for the past month or so<= br> trying to find all the bits and bobs associated with i386 kernels into a somewhat-organized list of commits.=C2=A0 The recent fixes to acpi_timer(4)=
and the removal of older APM BIOS bits were part of this branch, and there<= br> are some more cleanups/fixes before the actual commit to remove most of
sys/i386.=C2=A0 At this point, what would be useful is for other folks who = are
familiar with i386-specific to look at the set of commits I have so far
and maybe point out other things I have missed that should also be
removed.

I also have some open questions and things I'm specifically not doing:<= br>
- The last few commits in this branch around stand/ I'm less certain of=
=C2=A0 =C2=A0as it may still be useful (for example) to continue support bo= oting
=C2=A0 =C2=A0FreeBSD/i386 guests in bhyve via bhyveload.=C2=A0 So, in gener= al I'm not
=C2=A0 =C2=A0sure how far down the path we want to go in removing stand/ su= pport.
=C2=A0 =C2=A0Perhaps /boot/loader makes sense as if you want to boot an old= er
=C2=A0 =C2=A0version that has a kernel you probably want to use /boot/loade= r from
=C2=A0 =C2=A0that version.=C2=A0 bhyveload is the tricky bit here I think.<= br>

I'd hold off on this. The benefit i= s small, and there's a couple of use cases
still around. We&#= 39;ve had a long-term stable interface here. Booting 14 and
even = 15 should work for the foreseeable future. We have to use 32-bit
= mode in the loader to boot amd64....

The rest look= s fine.

Warner
=C2=A0
- I have made no attempt to "move" anything out of sys/x86.=C2=A0= For
=C2=A0 =C2=A0most things that are there I don't think the churn is wort= h it to
=C2=A0 =C2=A0move them into sys/amd64.=C2=A0 There are a few headers which = are now
=C2=A0 =C2=A0only used on amd64 for which it may make sense to move to
=C2=A0 =C2=A0sys/amd64/include in the future.

- Once the kernel is gone, i386 worlds can now only run under an amd64
=C2=A0 =C2=A0kernel.=C2=A0 This means we could adjust the ABI of i386 perha= ps to
=C2=A0 =C2=A0assume the amd64 baseline (SSE2, etc.).=C2=A0 We already assum= e 64-bit
=C2=A0 =C2=A0atomics via cmpxchg8b.=C2=A0 This would be equivalent to using= the lib32
=C2=A0 =C2=A0library builds (e.g. specialness around FSBASE/GSBASE in lib32= is
=C2=A0 =C2=A0something we might want to enable for plain i386).=C2=A0 I hav= e not done
=C2=A0 =C2=A0any of this and do not intend to make any such changes in this= branch.

- I have not stubbed out i386-specific things in userspace that won't =C2=A0 =C2=A0work without an i386 kernel (e.g. i386_vm86(2)).=C2=A0 The amd= 64 kernel
=C2=A0 =C2=A0will already fail these things, but there might be i386-only =C2=A0 =C2=A0programs or daemons similar to apmd(8) (recently removed) that= my
=C2=A0 =C2=A0branch doesn't yet remove that should be on the chopping b= lock.=C2=A0 If
=C2=A0 =C2=A0you know of something I'm missing, please let me know.

- When device drivers were not specifically tied to i386 just only
=C2=A0 =C2=A0made sense / were enabled on i386, I have split removing those=
=C2=A0 =C2=A0out to separate commits to make it easier to fetch them out of=
=C2=A0 =C2=A0history in the future if they are ever needed for some other =C2=A0 =C2=A0architecture.

- I'm currently stuck keeping sys/i386/linux as libsysdecode uses
=C2=A0 =C2=A0it for SYSDECODE_ABO_LINUX on i386.=C2=A0 Probably I should ju= st
=C2=A0 =C2=A0change the i386 build to use the amd64 linux32 tables instead.=

You can see the current branch here (note that I frequently rebase
it):

https://github.co= m/freebsd/freebsd-src/compare/main...bsdjhb:freebsd:rm_i386_kernel

--
John Baldwin

--000000000000b2621e065d238736-- From nobody Tue Oct 6 06:19:13 2026 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 4hzR1C74XZz6Z91P for ; Tue, 06 Oct 2026 06:19:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzR1B6lbKz3JFv; Tue, 06 Oct 2026 06:19:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none) Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTPS id 6966JDBG009255 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 6 Oct 2026 09:19:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 6966JDBG009255 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 6966JD1p009254; Tue, 6 Oct 2026 09:19:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 6 Oct 2026 09:19:13 +0300 From: Konstantin Belousov To: John Baldwin Cc: freebsd-arch@freebsd.org Subject: Re: i386 kernel removal Message-ID: References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on tom.home X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; HAS_XAW(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4hzR1B6lbKz3JFv On Mon, Oct 05, 2026 at 11:06:08PM -0400, John Baldwin wrote: > After some threads on the committers mailing lists a couple of months ago, > srcmgr@ agreed to modify our original schedule for deprecating some > platforms back in 15.0 and to go ahead and remove i386 kernel support from > main. > > Towards that end, I have been working on a branch for the past month or so > trying to find all the bits and bobs associated with i386 kernels into a > somewhat-organized list of commits. The recent fixes to acpi_timer(4) > and the removal of older APM BIOS bits were part of this branch, and there > are some more cleanups/fixes before the actual commit to remove most of > sys/i386. At this point, what would be useful is for other folks who are > familiar with i386-specific to look at the set of commits I have so far > and maybe point out other things I have missed that should also be > removed. > > I also have some open questions and things I'm specifically not doing: > > - The last few commits in this branch around stand/ I'm less certain of > as it may still be useful (for example) to continue support booting > FreeBSD/i386 guests in bhyve via bhyveload. So, in general I'm not > sure how far down the path we want to go in removing stand/ support. > Perhaps /boot/loader makes sense as if you want to boot an older > version that has a kernel you probably want to use /boot/loader from > that version. bhyveload is the tricky bit here I think. > > - I have made no attempt to "move" anything out of sys/x86. For > most things that are there I don't think the churn is worth it to > move them into sys/amd64. There are a few headers which are now > only used on amd64 for which it may make sense to move to > sys/amd64/include in the future. sys/x86 is still needed to compile 32bit world, because enough of the headers in i386 machine/ forward to x86. So it is not about churn. > > - Once the kernel is gone, i386 worlds can now only run under an amd64 > kernel. This means we could adjust the ABI of i386 perhaps to > assume the amd64 baseline (SSE2, etc.). We already assume 64-bit > atomics via cmpxchg8b. This would be equivalent to using the lib32 > library builds (e.g. specialness around FSBASE/GSBASE in lib32 is > something we might want to enable for plain i386). I have not done What specifically do you mean there about segbases? > any of this and do not intend to make any such changes in this branch. > > - I have not stubbed out i386-specific things in userspace that won't > work without an i386 kernel (e.g. i386_vm86(2)). The amd64 kernel > will already fail these things, but there might be i386-only > programs or daemons similar to apmd(8) (recently removed) that my > branch doesn't yet remove that should be on the chopping block. If > you know of something I'm missing, please let me know. > > - When device drivers were not specifically tied to i386 just only > made sense / were enabled on i386, I have split removing those > out to separate commits to make it easier to fetch them out of > history in the future if they are ever needed for some other > architecture. > > - I'm currently stuck keeping sys/i386/linux as libsysdecode uses > it for SYSDECODE_ABO_LINUX on i386. Probably I should just > change the i386 build to use the amd64 linux32 tables instead. > > You can see the current branch here (note that I frequently rebase > it): > > https://github.com/freebsd/freebsd-src/compare/main...bsdjhb:freebsd:rm_i386_kernel > > -- > John Baldwin From nobody Tue Oct 6 08:07:55 2026 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 4hzTQd03brz6cYBS for ; Tue, 06 Oct 2026 08:08:09 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzTQc0tdBz4bWj for ; Tue, 06 Oct 2026 08:08:08 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20251104 header.b=ZxrK3PAe; spf=pass (mx1.freebsd.org: domain of vadimnuclight@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) smtp.mailfrom=vadimnuclight@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-48afbd2c386so323888f8f.3 for ; Tue, 06 Oct 2026 01:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791274082; x=1791878882; darn=freebsd.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=yu8ZKNhWsmG6sT0YwGuuHMFQEyoYvTZLrNUI9qO0D/4=; b=ZxrK3PAewb6duzEMJySqWwSBVWXS1ip4Fh+e21OEuKPTw3K71VqTbzku8QMWZAbVXP EQSk2eJdv2rJcTOgcfNx1If5wEFxuPsNH9FY0xSFnP5AC9aqryvUoY6CZV/W/UBg2Vq3 fuuUKo+yXCCjIPFaj+RnTIUFwe8O8UibTMNPfDrnm8vPiQ5KfYr+6YG6VmtYERfcLvhY SjrofcQHR23ycRV5xpSc5gNcR0UJMu3upyKjI/oKh1haZpWDnmheAOv+gME6gwb+tbdM pF7K8DdyX3yzbpExDU2F599r1pQteMq/9Rf6Nu3zw68W8N03HLCVBCUbdNtxX3QJe+9v 5i8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791274082; x=1791878882; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=yu8ZKNhWsmG6sT0YwGuuHMFQEyoYvTZLrNUI9qO0D/4=; b=bKKmUmYbAIROMLO6sqk4uc/rKohOhH2AzaH4zMvRseOFmto+Zb3hNfFg411++z80ef AWfnlAqVDY/Wyh3yFFdPvn5NQcoT5lryl9IMMx/hwsSzTK6v9xz3126t9qr56Uo7WY6O red/8PjbxhWDOGjlYic/l8k7dVRJj/KP+NGI3KQleTkIQsnzN2sFgxEDe+kmAz3lcTlb YA/JvKadl8J2KqR44Yn+tDN5xapNoeSx3iKpPjg23uUH1s7DT9wQRFMQCJvwVuvWX0kp ZHC419ABf67vPKwTV8zmWRArJunbddltBUMp8phClmoqgpZuEYCDxfGS3Atzer23mjJE w18Q== X-Gm-Message-State: AFq9FYIFB4e+U+JkzGgaNoCQvtPU4kG/zfO+PSMfWC+3DKHCcexzfuLY v4883wFzH9Q0Y9DlMFtW8T6xMAkLvnyd7dkcRIicvzqukhbqqoGiNdAa X-Gm-Gg: AYBFou0PbJqzPiT6p8KmAXeuBx1HlQnkrkcTov90D0V3xsy+9BAHTKneM1lrdMsamyq 8PZsqCrcbZcZEpAl8zThpsbUgyZ6YJjupfs+uLF6YzCa3Q001gD2161LewvaL91laZRdq46Dgx3 PubcW7Hb3OLY/v7zLFXTuL+JkN0TmSibL4cU2usK24jLfzM0vNwjE8nMMQMVNDFegSOQao0T3Ok cLOgu1/r+KMg00HAgEVg2MBeqCLIc5vY/JcBIYzHRgVYtzJpYKkwQCP+W/AEnFJzEmltAidomRW L7anQPxw7RVLjSTzMCc/slsJQPbaAtwVWxjEklisMz9XGR1bDdUpWGxGJDgbczmnKwr1FA49ajA bT4TiV5me3ytyvAi62EfnDBgdHxzqaCn9O9ffs9HzcSSL+LyIdo/5g8HpWD9xiCD0beVdZByZ7r uE55Mtc42VPH3kFDUMwqp5qXKp13eOxd8tGUDwMG1RLBmozJakHoXGtyON8oalTrqnqRG0hU0b8 iIuRCnTbWx3XKa+JjTlsdlaYPupu2zTh7m3yozH9rSNtho= X-Received: by 2002:a05:6000:4382:b0:48c:490a:336b with SMTP id ffacd0b85a97d-48c6d0f3e9bmr1371849f8f.5.1791274081253; Tue, 06 Oct 2026 01:08:01 -0700 (PDT) Received: from nuclight.lan (broadband-77-37-180-76.ip.moscow.rt.ru. [77.37.180.76]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48c622907fesm9413287f8f.26.2026.10.06.01.08.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2026 01:08:01 -0700 (PDT) Date: Tue, 6 Oct 2026 11:07:55 +0300 From: Vadim Goncharov To: John Baldwin Cc: freebsd-arch@freebsd.org Subject: Re: i386 kernel removal Message-ID: <20261006110755.0ff20e9e@nuclight.lan> In-Reply-To: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; amd64-portbld-freebsd13.5) 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: - X-Spamd-Result: default: False [-1.00 / 15.00]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20251104]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4864::/56]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42b:from]; RCVD_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+] X-Rspamd-Queue-Id: 4hzTQc0tdBz4bWj On Mon, 5 Oct 2026 23:06:08 -0400 John Baldwin wrote: > After some threads on the committers mailing lists a couple of months ago, > srcmgr@ agreed to modify our original schedule for deprecating some > platforms back in 15.0 and to go ahead and remove i386 kernel support from > main. Why anyone need to remove it all (previous goal "just out of Tier-1" looked much more sane) ? Why unnecessary effort to axe it out? Especially given expected industry degradation to 90 nm level during during 2030-s, then likely add it back in a rush a few years later? (Did the burning data centers in Kyiv and the Persian Gulf teach no one that ASML would be among the first WW3 targets?) > Towards that end, I have been working on a branch for the past month or so > trying to find all the bits and bobs associated with i386 kernels into a > somewhat-organized list of commits. The recent fixes to acpi_timer(4) > and the removal of older APM BIOS bits were part of this branch, and there > are some more cleanups/fixes before the actual commit to remove most of > sys/i386. At this point, what would be useful is for other folks who are > familiar with i386-specific to look at the set of commits I have so far > and maybe point out other things I have missed that should also be > removed. > > I also have some open questions and things I'm specifically not doing: > > - The last few commits in this branch around stand/ I'm less certain of > as it may still be useful (for example) to continue support booting > FreeBSD/i386 guests in bhyve via bhyveload. So, in general I'm not > sure how far down the path we want to go in removing stand/ support. > Perhaps /boot/loader makes sense as if you want to boot an older > version that has a kernel you probably want to use /boot/loader from > that version. bhyveload is the tricky bit here I think. > > - I have made no attempt to "move" anything out of sys/x86. For > most things that are there I don't think the churn is worth it to > move them into sys/amd64. There are a few headers which are now > only used on amd64 for which it may make sense to move to > sys/amd64/include in the future. > > - Once the kernel is gone, i386 worlds can now only run under an amd64 > kernel. This means we could adjust the ABI of i386 perhaps to > assume the amd64 baseline (SSE2, etc.). We already assume 64-bit > atomics via cmpxchg8b. This would be equivalent to using the lib32 > library builds (e.g. specialness around FSBASE/GSBASE in lib32 is > something we might want to enable for plain i386). I have not done > any of this and do not intend to make any such changes in this branch. > > - I have not stubbed out i386-specific things in userspace that won't > work without an i386 kernel (e.g. i386_vm86(2)). The amd64 kernel > will already fail these things, but there might be i386-only > programs or daemons similar to apmd(8) (recently removed) that my > branch doesn't yet remove that should be on the chopping block. If > you know of something I'm missing, please let me know. > > - When device drivers were not specifically tied to i386 just only > made sense / were enabled on i386, I have split removing those > out to separate commits to make it easier to fetch them out of > history in the future if they are ever needed for some other > architecture. > > - I'm currently stuck keeping sys/i386/linux as libsysdecode uses > it for SYSDECODE_ABO_LINUX on i386. Probably I should just > change the i386 build to use the amd64 linux32 tables instead. > > You can see the current branch here (note that I frequently rebase > it): > > https://github.com/freebsd/freebsd-src/compare/main...bsdjhb:freebsd:rm_i386_kernel > -- WBR, @nuclight From nobody Tue Oct 6 08:21:28 2026 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 4hzTkH3d64z6cZ6v for ; Tue, 06 Oct 2026 08:21:43 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzTkG3XWGz4d9Q for ; Tue, 06 Oct 2026 08:21:42 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of jrtc27@jrtc27.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=jrtc27@jrtc27.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none) Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-c2e3846d1caso37591466b.0 for ; Tue, 06 Oct 2026 01:21:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791274901; x=1791879701; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:content-type:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=i56SdHBSfJ/7npervoHXSXapDucsfG3IfPUePOWlLXo=; b=rkrznvRoQ8EkGyOSrbZnAWYbRkwKdRYqMlWBNxiAI3ZcO6yMOjwXDuVUNlpvUZjRvO zoY+4VgBw/wlIU9pagKwrz+rjI1mTutYUM5TR2X6NWSM5RIe5KyPsR58uq4zYprYZFgb n9LjZdVjMMR+dfk23AugMan86t2R2LOmBxYXuGcdM2+yIwQgDewm8L9kyV6K0AN2b0su YAKt2zIZurnRqC4sOVaaps+Lr3q1QXyTRHMLTMDMjNOvXnfnQsfs0TSVVQr/erKHr5e3 ExhEWV6n2ABS5DNIhPkzOsF6h4weLqhsqOMcKscim70RItfhMq1lI6uX4SXnv7Pvw3xE Q+Zw== X-Gm-Message-State: AFuF++ltjrUD2+Ef5M6Zr/8Cw5j9cWD9Mw0Caw4tKeSYHxfJF+LgAgjV f+XwkhSMNu4LeY8PEOVpUB1d0tOrJqyIpRu2LQcJkIsgixT08UBpKF7xqCa7eTRgT/A= X-Gm-Gg: AYBFou32WdFf/ZyiwmzYe+8gWyxcsELGyLh/bqlBkqna7XJcMVRYiri91UylieADoOt viZfw9X4iLlv/KMIBpgWa+5DVZx3avSihEVNcm7vjx2+X58Bkeo5NQfIcdJQ6b6Pe/tKduZ31ve RHKSNOxEX9UuckxpSFvgYD3NVaKaZ5l6zzDqkF8LJGRe4AiGc9LIeKCLDtTJSM4LKKFOk0AqOtz CulNvp5S0P7uOK+5H48hPb90QeY1ozASu8L8viSpcjebfLInqnVjTAjJFe7+ottlwpIBcrqe4ET 3iVBOhx+Geuh28LzVf/WgONnc+htGI/fSK9rhEHBAUjaq64XfI4v8vB2CfoQNdSW8GxhfLX0Py+ 6VkkhQ8C6161eAbZkIbS6KxfCEYb0gLeBF8r2z1IR1CzwV9A1el6lxF0htCWW+rb8+WDSTXeKSd JXBTREaVQcDtoiZwXQ/YeBANmeMadXuKUSRBxYUlPWBCPJx61WS5sBa5rlpwVEVfAETPm2fdUtu EkPTcQ2xE2PAAzfU+2i5NlkOwOhrA== X-Received: by 2002:a17:906:f591:b0:c2d:e548:3ac with SMTP id a640c23a62f3a-c3169fa464amr70714766b.19.1791274900626; Tue, 06 Oct 2026 01:21:40 -0700 (PDT) Received: from smtpclient.apple ([2a00:23c8:f53f:8a01:f10f:1164:10e2:8d9c]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c31562dcd2asm178747066b.39.2026.10.06.01.21.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2026 01:21:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3901.100.1.1.12\)) Subject: Re: i386 kernel removal From: Jessica Clarke In-Reply-To: <20261006110755.0ff20e9e@nuclight.lan> Date: Tue, 6 Oct 2026 09:21:28 +0100 Cc: freebsd-arch@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> To: Vadim Goncharov X-Mailer: Apple Mail (2.3901.100.1.1.12) X-Spamd-Bar: / X-Spamd-Result: default: False [0.50 / 15.00]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[jrtc27@freebsd.org,jrtc27@jrtc27.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.218.52:from]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[jrtc27]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[jrtc27@freebsd.org,jrtc27@jrtc27.com]; FREEMAIL_TO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.52:from] X-Rspamd-Queue-Id: 4hzTkG3XWGz4d9Q On 6 Oct 2026, at 09:07, Vadim Goncharov = wrote: >=20 > On Mon, 5 Oct 2026 23:06:08 -0400 > John Baldwin wrote: >=20 >> After some threads on the committers mailing lists a couple of months = ago, >> srcmgr@ agreed to modify our original schedule for deprecating some >> platforms back in 15.0 and to go ahead and remove i386 kernel support = from >> main. >=20 > Why anyone need to remove it all (previous goal "just out of Tier-1" = looked > much more sane) ? Why unnecessary effort to axe it out? >=20 > Especially given expected industry degradation to 90 nm level during = during > 2030-s, then likely add it back in a rush a few years later? >=20 > (Did the burning data centers in Kyiv and the Persian Gulf teach no = one that > ASML would be among the first WW3 targets?) If survivors of the apocalypse have access to the FreeBSD Git repository, they can always go back through the history and reinstate it. But given the content of your message I struggle to believe any of this is a serious question. Jessica From nobody Tue Oct 6 08:45:56 2026 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 4hzVGS1P4Rz6cbXR for ; Tue, 06 Oct 2026 08:46:08 +0000 (UTC) (envelope-from freebsd-arch-freebsd-org789@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4hzVGQ4KB8z4gBN for ; Tue, 06 Oct 2026 08:46:06 +0000 (UTC) (envelope-from freebsd-arch-freebsd-org789@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=anIZW2hM; spf=pass (mx1.freebsd.org: domain of freebsd-arch-freebsd-org789@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-arch-freebsd-org789@ketas.si.pri.ee; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee X-Clacks-Overhead: GNU Terry Pratchett DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1791276356; bh=ns7p1yDhA2CG5CfJqJ3+unH2fdhlm/FUOpJtLrdXO5o=; h=Date:From:To:Subject:In-Reply-To:References; b=anIZW2hMMXSmPEcXcUmSAvIOjUxULHhOeVMKUQGT/8d4pyPGorPpvjcGuOAS91vdI pguUvKM9PM8PaZCzmHj9XL72l2LLrcc/lZ0/FJ0I516wpmEVAWbNOwLp5oFfZQllIS baabFG1pY3FCBh7UesPA+NIzbMVvheemm3C555gMGu9UW+JPI46ZsQgotHEZiujpO8 T2gqrQa4Cqf67xyzpQJUz6iosyEaQcUBxSm03LkfdM3Lteq+lRC1XaVCIcEA9ImJ7u Gzp7J2J1f6iXUVTmYMWVqROV6q4MTA7PFbirBTckX6rQCF+2PygiO4atJxTlnLDW1d PZZ7lkql0DOUdnZuzCIpsrQOb47ExL0j/4+ghfl7iGupXdsPoDBeJTCRAjQ/Kki+7T cGwMdu9rmGc9/Xg9F8ij2Cc4uaEvzo9PgFhbZ22041XhXqimMDtob+T1A8YUQYxwPp q4U2OXwuSD9sPHoeU0apsu4mcCqYwYp9W4muB0n40MkZILcfVdBo047QkptBCR0c9j oRc7apUmtFN6sD65AsC2PsnwPL4uMQRGwMnJHJet+5lEV7a4b2fcc8BmWbXaYd2N0S c8BUzZmZ0HbRIs2Ct5n12ZnV/q+CEgSGH5JcXMcJQuotZ9DYgD/bPy6nkpsB1hcM60 ik8PeVPZi0BMbYOokt0ZvEF0= X-Passed-Through: http://ketas.si.pri.ee/ Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (MTA) with ESMTPSA id 581C65F6793 for ; Tue, 06 Oct 2026 11:45:56 +0300 (EEST) Date: Tue, 06 Oct 2026 11:45:56 +0300 From: Sulev-Madis Silber To: freebsd-arch@freebsd.org Subject: Re: i386 kernel removal User-Agent: K-9 Mail for Android In-Reply-To: <20261006110755.0ff20e9e@nuclight.lan> References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> Message-ID: <209747BE-8286-4AC5-B6DF-182D129ADB8C@ketas.si.pri.ee> 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.20 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4hzVGQ4KB8z4gBN On October 6, 2026 11:07:55 AM GMT+03:00, Vadim Goncharov wrote: >Why anyone need to remove it all (previous goal "just out of Tier-1" look= ed >much more sane) ? Why unnecessary effort to axe it out? > >Especially given expected industry degradation to 90 nm level during duri= ng >2030-s, then likely add it back in a rush a few years later? > >(Did the burning data centers in Kyiv and the Persian Gulf teach no one t= hat >ASML would be among the first WW3 targets?) honestly, if (nuclear) war comes=2E all bets are off tbh one can still use i386 fbsd build then i seriously have considering needing to run standalone networks in postapo= calyptic world but honestly one would even be happy to run fucking win95 by= then=2E tho there's likely other oses too that being said, how do you expect the world fall so low tho? it's not lik= e asml factory makes it all i recently watched https://m=2Eyoutube=2Ecom/watch?v=3DMiUHjLxm3V0 The Closest Thing We Have to Alien Technology @veritasium 817K likes 60M views 9 months ago asml was fully open how those things are made so it's not like knowledge is somehow "lost" nor do i believe we even destroy hw=2E we have made so much of this=2E pla= net is filled with smart people, hardware, libraries and so forth lets bring chance of techological singularity here too if we talk about do= omsday scenarios that would change the course of fbsd tbh nobody on this planet has brain capacity to "get" that anyway unfortunately we can make ai=2E because "i" exists=2E it won't break laws = of physics and only needs 20w it won't likely be hollywood movie but we also don't have jason statham axing one special cable From nobody Tue Oct 6 10:23:49 2026 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 4hzXRP1q2yz6jwvw for ; Tue, 06 Oct 2026 10:24:01 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzXRN5tx9z4tqf for ; Tue, 06 Oct 2026 10:24:00 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20251104 header.b=T2B0kcLF; spf=pass (mx1.freebsd.org: domain of vadimnuclight@gmail.com designates 2a00:1450:4864:20::32b as permitted sender) smtp.mailfrom=vadimnuclight@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4a01933b584so4777355e9.0 for ; Tue, 06 Oct 2026 03:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791282234; x=1791887034; darn=freebsd.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=aXxY2oiNftK1cgTkQKweyRGzNq9wmn3LZWHS4rHj1No=; b=T2B0kcLFoIplbRYK2/hofF4vRVgzyuavJLZiEUWLlPV5dYm+QF4n/QuIQM4V1XaQEe eS5iKsvI0YQTMXjoH66AauRtW3rHkKgX9jCHm2O8OoN6XyF4sjLvZ/6a8zsU79do8ZAk kVSB4x0NtNr/EU02Z7OKPzCOw7pUP8B1Xt+3/jAaFqrowesnHKHH2JRUXWhLS8s+C/Bd xM9c6ZcL58lGCP/9WjaghD167Q3TKegE3nHxak9j+ITfXszmDR6qPOQkWQ91zrpc5Yj3 ASVpHXxoEUNRQ5fIoC6b58MnbeonuaTOvk4BnUcsCwIE2YXfTHWlSeG6ofSy8lEIjO5q iaRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791282234; x=1791887034; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=aXxY2oiNftK1cgTkQKweyRGzNq9wmn3LZWHS4rHj1No=; b=AAyi65ZuFwlSzCOQ+VlhyV5ApkG4FL2faqo3Qvu9PHE9B2EX7stkDWp6qmfHrn3vuv z8oIBi8sLfgNuXSYn26cThRpJi8kLF+KLLGX/una1e8ue4RawZ2xZa0UbKjpk7tziCRe EaDP/g4TSDwNR2mn4c/gILP1FhS+RT/qrgpnGm+UqWEjs6i0CgzMTBwLGh+zn+aXfgE9 lQh+Rk/xvnR0IhXiuigThXzsFZMvEEkFKniXlvz1mLPoIRBma2gcxJLyr9bThNerwcme cI6tOIfFGJwX/GmI97UMkoeExwExny5OyouHM3mJJkuJyaF8NeoSQD59C5M4lhlbYIQ3 uaxg== X-Gm-Message-State: AFuF++lvmobYj8SjVkSXxwzkDv336h3j/NEC/OK3l1Az48gBF2RCwRUY fuOpU9NsyRUXUBZGpDV7MtDqWIEO8gSt8xogU+dYepTcOjPqw15zNlQyy0EX6NeV X-Gm-Gg: AYBFou2DAFc6nb4GtlZ9qSylWpdQkBXtFVFBDgqMaT8tDnPUNhf7jfRZKIKriigw5jt xxSBVK/DSWvcODnRJIXMQPA6Lx6ZLRE8/sjBu8jFFpPaeVFXer98MA8vGrLXC3KZcox4HaP73qU 48ZFbUicMHqi0mzIhV8wvJ4XekFkt/fFAf+xL8NiF2uBTjzkrZIwNn9RiSDgD6BbsxaSJewFZLQ 8l4dzaMuYj+QokGwD7bvi8gqLU7sTYuOK2aZtH3wnh0rAyb9FPhSDQB+Gc4jOKpy5GgRD96a0VB F661q7zUODxFptb0aQIk7FrlFvqVtNOkGzgJuICggKpU1vgokgbo760pK6AW2bjhXlg8EywXnnZ vx9pXyyXok0SiNfCneNhRofNefvYKec8WkmFxCgfe/nKxLYauLYeze9bxvbfoUP8uv1hzLs91yD fZGM7s5L6yNnyuv1hkWOFSLoTVdB1IDo6lw2VSWyEz/94/x6qcX5EJOatMXi3zkofCg1zqIdLWX whCtqc1PDzhqXmCrAWGhnovWEpSt2SdEizfjGJgfTZqMZU= X-Received: by 2002:a05:600c:848d:b0:4a1:71e5:9420 with SMTP id 5b1f17b1804b1-4a17b53c11emr16188455e9.13.1791282234404; Tue, 06 Oct 2026 03:23:54 -0700 (PDT) Received: from nuclight.lan (broadband-77-37-180-76.ip.moscow.rt.ru. [77.37.180.76]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4a178c53299sm107212385e9.11.2026.10.06.03.23.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2026 03:23:54 -0700 (PDT) Date: Tue, 6 Oct 2026 13:23:49 +0300 From: Vadim Goncharov To: Jessica Clarke Cc: freebsd-arch@freebsd.org Subject: Re: i386 kernel removal Message-ID: <20261006132349.69e40508@nuclight.lan> In-Reply-To: <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; amd64-portbld-freebsd13.5) 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: - X-Spamd-Result: default: False [-1.00 / 15.00]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20251104]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4864::/56:c]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32b:from]; RCVD_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+] X-Rspamd-Queue-Id: 4hzXRN5tx9z4tqf On Tue, 6 Oct 2026 09:21:28 +0100 Jessica Clarke wrote: > On 6 Oct 2026, at 09:07, Vadim Goncharov wrote: > >=20 > > On Mon, 5 Oct 2026 23:06:08 -0400 > > John Baldwin wrote: > > =20 > >> After some threads on the committers mailing lists a couple of months = ago, > >> srcmgr@ agreed to modify our original schedule for deprecating some > >> platforms back in 15.0 and to go ahead and remove i386 kernel support = from > >> main. =20 > >=20 > > Why anyone need to remove it all (previous goal "just out of Tier-1" lo= oked > > much more sane) ? Why unnecessary effort to axe it out? > >=20 > > Especially given expected industry degradation to 90 nm level during du= ring > > 2030-s, then likely add it back in a rush a few years later? > >=20 > > (Did the burning data centers in Kyiv and the Persian Gulf teach no one > > that ASML would be among the first WW3 targets?) =20 >=20 > If survivors of the apocalypse have access to the FreeBSD Git > repository, they can always go back through the history and reinstate > it. But given the content of your message I struggle to believe any of > this is a serious question. - There won't be a WW3: the franchise owners have abandoned full-fledged numbered releases in favor of a service-based model featuring monthly subscriptions and seasonal events. (c) threads.com/@v.predictor/ Nobody is interested in apocalypse/nuclear war. The Lindy Effect dictates previous technologies are more robust, therefore depriving the enemy of more vulnerable more modern technologies is more than sufficient (to win then wi= th classics). So this will be done. And nobody will seriously complain, like it was with Nord Streams explosion, because of "hey, most of the world has basically stayed the same - surely that=E2=80=99s no reason to start a nucl= ear war?". And thus instead of an apocalypse, it will be a gradual decline in living standards for many decades (a process already underway in Europe for several years), when e.g. you will be happy to watch 480p videos instead of 1080p, because it's not 360p (yet) and you can still watch them at all, so there's no point to rise a riot (especially when it was because of some terrorist on the other side of the globe, as you'll be told), right?.. *That's* the most realistic scenario for 10-15 years, open your eyes (even = without full-fledged WW3 you'll get the global Greatest Depression - oil prices). S= o there is no point to waste effort for removing something which was not in previou= s plan ("just unmaintain"), better put effort in something more valuable. For exam= ple, abandon pkgbase as both harmful by itself and as eating much more bandwidth= than freebsd-update, unacceptable in 90 nm network links capacities. --=20 WBR, @nuclight From nobody Tue Oct 6 11:51:59 2026 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 4hzZP30TjVz6k4Mm for ; Tue, 06 Oct 2026 11:52:07 +0000 (UTC) (envelope-from evg.andrienko@gmail.com) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzZP22MGzz3KDP for ; Tue, 06 Oct 2026 11:52:06 +0000 (UTC) (envelope-from evg.andrienko@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20251104 header.b=mHhvEv8q; spf=pass (mx1.freebsd.org: domain of evg.andrienko@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) smtp.mailfrom=evg.andrienko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-3a5a26c8412so2841541fa.3 for ; Tue, 06 Oct 2026 04:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791287522; x=1791892322; darn=freebsd.org; h=content-type:mime-version:message-id:date:user-agent:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=iie7IX8kVzO8UfqVQ3Il2uo7JOV8rrV54yGSCHV6Jis=; b=mHhvEv8qRyUZil1+4RIiIdbfH/RxPl8INfwh7X87754NOqAoE9GFUxrtm66pbLapAf 7ERUjRRtCnmpRLjkWVCPUznNs6Zd2Q2hvMbR9Z91zydfcp4fvkGlGUEUv1+3Oq6bOEXu ic0/N3B+CanNEIU8KPfElRCGuUt0EuiiZ3+2HKIsKaa7y8R6T1ybY0n9GaoD+O0zfYJo gsZONYOot6uK2meHeIybgUuLdDqVHAfrJppu4WxVIPYD++Kb2KXpNRvK413zxhODdTaE MKv8M1ZPF3DlRalh0FqEt1kqKKCbU7sQs8f84KvJEgh/9wWyRqzeiKvVpasAdH3cfw56 kEIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791287522; x=1791892322; h=content-type:mime-version:message-id:date:user-agent:references :in-reply-to:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=iie7IX8kVzO8UfqVQ3Il2uo7JOV8rrV54yGSCHV6Jis=; b=CmJrDXnrKfMDfe8Qh2TlYFwQAmGbjLsdehgsm1CmGBqx56+Gqoe3HfxUJtp7lU+IVx FxDBy8lwTLwdq8ovacPQFw9YtWQs48sfXaTalSjclUNrjv1+THzG557C9rrRlpEOCuYC zaSfD2KUZQ2up6UU1e+UCjCV0xaRGEmnws9uh1l+F65dRaiW5BCw4HvASX9Z0kjdL7uv oxHns5XttNJU4f7IONjPlo18JN71en3SaZmJy+o1wj18ck0H857f6WdNPjsFiJBcO57u GrOGwnDpafRXeHNJFrZWnt8eYxy+MCFDYx2wme47AxnDi8VFPX8o4nmDv6n819b892bu EOOQ== X-Forwarded-Encrypted: i=1; AKwUvBwm65qUCi8V4D83dweoxZJ5nIJK9VhD8VlgLwL9EqfX43NcFab37fzhNE+UR9Q22fC2RonwU6SNz/BXjL8=@freebsd.org X-Gm-Message-State: AFq9FYLLuaj7d1/z/r71b9rx06EvgoIeWUraRbGnP89PCcCmKHUJdrL+ tomjx0o0DmrSPLQBf1I5RHoKeYSfY5skRa7QMQcXu5et4KEbnJFlbhYe X-Gm-Gg: AYBFou3ebpCnrsmSSL0pPWlp0jaLy0lPT4y9O3X4P0kdVDS4aJ8skxSKvdNXv9l9jeO gXhBH3443ZghtOcE9EklFqEnF3SeRWsxSXOWW3wlMOuTPtbjas6dIr0DGANQzV0l6+jrpNVzRme 6HzxGqYBxTExQHgfR0qjObtlh5waFCCHxd4jry2Q72cFSOvM8GeYgVcbkOn19uAJu6N0OdPLRTc sFuhSxlXjueGoa6vVg75j6Xlf+aW8xGQyPSrdltsd8xvawV+/KU2UFywqwTW5ZXUzMBnaIWToNS qR3OKfT108VgdUapMwd26e0uQm9IWiuRE4GAIfVtSd1iD5FqSapv4zFxVh7Iryc4/NonWiu4mDs 0JuRRgXDe6YFY+OKHTYgbhfrJeqaeCR/aQbI+RtVBoSEbTuvaA/bHZ5cOkaszoLEwi7uqTm0xwe UDnHFwtcIO3eQD5UzbyHto5TqFGpJfTLyj4p/tP5rJq2TgshgKzpGNrdzLTY+LnJFM66o= X-Received: by 2002:a05:651c:211b:b0:3a7:72ec:81a9 with SMTP id 38308e7fff4ca-3a99acf26fbmr3027901fa.9.1791287522212; Tue, 06 Oct 2026 04:52:02 -0700 (PDT) Received: from localhost ([93.100.9.239]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-3a87e321cc5sm49756621fa.33.2026.10.06.04.52.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2026 04:52:00 -0700 (PDT) From: Eugene Andrienko To: Jessica Clarke Cc: Vadim Goncharov , freebsd-arch@freebsd.org Subject: Re: i386 kernel removal In-Reply-To: <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 06 Oct 2026 14:51:59 +0300 Message-ID: <864iez82sg.fsf@drag0n-laptop.lair.internal> 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Bar: / X-Spamd-Result: default: False [-0.50 / 15.00]; R_MISSING_CHARSET(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20251104]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4864::/56:c]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RECEIVED_HELO_LOCALHOST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::230:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ALIAS_RESOLVED(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4hzZP22MGzz3KDP Jessica Clarke writes: > If survivors of the apocalypse have access to the FreeBSD Git > repository, they can always go back through the history and reinstate > it. But given the content of your message I struggle to believe any of > this is a serious question. I think, the "If" is the most questionable thing here. E.g. I'm already stored some FreeBSD installation images just in case (Internet blackout like in Iran, etc), but I didn't store the FreeBSD Git repository - because the disk space is not infinite and I'm, as an end-user, didn't need source code - I need the resulting artifact (the mentioned installation images). And I pretty sure that a lot of people, who performing the same task, also didn't store the mentioned Git repo. I agree with Vadim Goncharov here, but I want to bring not so apocalyptic scenarios, but events that are happening right now. The new and modern computer hardware nowadays may be inaccessible because of inflation (too big prices - better to buy food, than HiEnd, not so well repairable computer), it may be inaccessible because of sanctions (waving from Russia, most of new hardware for usual people now comes from AliExpress and other Chinese marketplaces), or it may be too expensive because of new taxes, imposed by government (waving from the same country). And also worth to mention RAM, SSD and HDD shortages because of LLMs. So, the old hardware from closets are in use again. And not only from closets, e.g. I could by a second-hand industrual PC (highly likely with i386 based CPU inside) from some broken industrual machine and use it as a PC for usual tasks, like e-mail reading, text editing, etc. E.g. my main server is a cash register for 30$ and with Intel Atom N2800 (x86_64 from 2011 year!) inside. Ofc it is with NetBSD inside, because I heard news about removing "obsolete" CPU architectures from FreeBSD at near a year ago and I was concerned about support of old hardware in use by FreeBSD. Definitely, I don't want to make pkg upgrade one day and find that my server no longer booting. So, I'm also joining to the same question: Why remove i386 support if it works and there are no new hardware in the near future? As I understand this is something like "complete software" [1], which will not rot while lying in the source tree? [1] https://my-notes.dragas.net/2026/01/06/the-virtue-of-finished-things/ -- Eugene Andrienko From nobody Tue Oct 6 13:03:57 2026 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 4hzc0G36GHz6vJnS for ; Tue, 06 Oct 2026 13:04:14 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzc0D2nqLz4F7r for ; Tue, 06 Oct 2026 13:04:12 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of jrtc27@jrtc27.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=jrtc27@jrtc27.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none) Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-6ae305e3bd9so1051226a12.0 for ; Tue, 06 Oct 2026 06:04:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791291850; x=1791896650; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:content-type:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=wHVeeoW9vBioRRg9sv+iRl+H+5TGoguGMEvpc1poI6E=; b=UH5dyFNRQ932zLKE6C3soJ667pdSTof9jlb+4FjJSSfwXK1k4bfS8qV06uUbMmlFXd cEiezve9XhXFw6uAA3noMvGg2QG9/2V/vEkUp5M5jWDBR5mk3L7aZP3OQB4esLHmAAve 4rmlYpSx9/9Drwcg3qFpdp9cmOZptKLMj+kuKznjhcgvfRskFvYPUrWtySfyV2BfpG0k 9soKjMyanNDcNQ2D6zKoHS4fVSh/AJvUoymfpikol1641U4D3/wRej6EJ28WUflFQyOD oEEh+ubBZea4Qwl7F3f4+H6EygK8mfU8JS8QxejlHmsa/M0s/qxqY1WR1fteekxyOmdQ Nhbw== X-Forwarded-Encrypted: i=1; AKwUvBwirI6KFS5dNOVrsMIpANZLh+AECuEUq1Lkn7ctixc9wy1cfOI3Hc0bTkd3t9cMhB0juIXguQdksotVqnI=@freebsd.org X-Gm-Message-State: AFq9FYI6dNiUYVIzQ3usYrc1hEDhESFqEeu5w1mY2LMzpGlJJXWPck1R HmxPZ1iFB2/pkV4gSt2hE5TRuPM1i04p3p20e7jISVNGK2QMx7O+1cNR2tVw6O9lfmyG1FH1vui /ZWYr1vc= X-Gm-Gg: AYBFou0wIiOujp4zezbho6mCt84RYnlcfi4j8lLKtviwC7bw+w5JFEUtCVWsv5Z39X/ 4hpP0WmroEfpTDoobfI2o2ZkCvINqf7zHyo/84SMrCCdAEtdJqsp7OMCwHchB7AzbolMsudF8bt DEnYQNdywhQq5la0XJGjbStJdqmV5QoQrdI9TpKDlAi6qiaZH+eSJ39pXIPiUELkb00Q0BCYpVN CC0q4dmIODNZa8OYaf/lbFiaFYDnLqbkWso104ZHT+nZNHSgMsPyY+niRL1nELUPjqAj2n2aUI5 /stNV8AQo0Yi2naM53oSYjyOgTB5j2ctIK9dog5N+XREr/L0sKysKg79MInn454/9Ot2yFzTZDN HfBNPdSrSC6I9ssZzktIRl3FNsh5T0pWPpZswnqTK8IMOUqCuRSwYlnDh4pMWqHendqwq5Fc1m2 WKSrLZPNzMpHTTXM5a/zxDst4VtwlNd7mxRPZRMYQ3gKkariDD9fPIBY0/iNGoOE6pP+7yq1bW4 tTYpcXFYhFYhpjcZxUHuC6v07aYwl2GTVPjxrhDWJk= X-Received: by 2002:a05:6402:20cd:b0:6aa:e589:87dd with SMTP id 4fb4d7f45d1cf-6afe29be83emr1232435a12.14.1791291850243; Tue, 06 Oct 2026 06:04:10 -0700 (PDT) Received: from smtpclient.apple (nat-184-65.net.cam.ac.uk. [131.111.184.65]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6afb014784bsm4667963a12.3.2026.10.06.06.04.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2026 06:04:09 -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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3901.100.1.1.12\)) Subject: Re: i386 kernel removal From: Jessica Clarke In-Reply-To: <864iez82sg.fsf@drag0n-laptop.lair.internal> Date: Tue, 6 Oct 2026 14:03:57 +0100 Cc: Vadim Goncharov , freebsd-arch@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <195845CA-895A-44D8-8E24-350509E781F4@freebsd.org> References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> To: Eugene Andrienko X-Mailer: Apple Mail (2.3901.100.1.1.12) X-Spamd-Bar: / X-Spamd-Result: default: False [0.60 / 15.00]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[jrtc27@freebsd.org,jrtc27@jrtc27.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEFALL_USER(0.00)[jrtc27]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.41:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[jrtc27@freebsd.org,jrtc27@jrtc27.com]; TO_DN_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; R_DKIM_NA(0.00)[]; ALIAS_RESOLVED(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.41:from] X-Rspamd-Queue-Id: 4hzc0D2nqLz4F7r On 6 Oct 2026, at 12:51, Eugene Andrienko = wrote: > So, I'm also joining to the same question: Why remove i386 support if = it > works and there are no new hardware in the near future? As I = understand > this is something like "complete software" [1], which will not rot = while > lying in the source tree? Because the project already decided that was the path it was going to take[1]. That isn=E2=80=99t up for debate, only the exact timeline for = doing so and how it is achieved. This thread is not to re-litigate that decision. Jessica [1] = https://lists.freebsd.org/archives/freebsd-arch/2025-June/000949.html From nobody Tue Oct 6 13:16:41 2026 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 4hzcHc47X9z6vKXh for ; Tue, 06 Oct 2026 13:17:32 +0000 (UTC) (envelope-from seuros@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzcHc3gKpz4GSc; Tue, 06 Oct 2026 13:17:32 +0000 (UTC) (envelope-from seuros@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791292652; 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=/WaUTwitmktEz4/ZLdnRktb0cK1LTe9yHPksyoggEvk=; b=awVkw7j0xYK+qd01eSfzB3IC1H278S2OxQHFwDzVUqn7LT54hZc1hNYlnxozVhwTyaJQiq Mfp3OFfCO0SAelbTM9YzqobLNK4A8/CTQeA8SW9frWzLftKnpWhUVFP199AfcOXPuepOQ9 NipXv8TjpXAWX33hxQnT18MUJEGoHQPdRGT8H3vFMB86zI91+x1Ex1P9ej1ZygdvHkcm3t z23W0pxZPT/RFiTdzyQiJM6N+EITfJUA6+QyUHT+g+DsWPW7TIgs8cGyLCAzFOEeT79QXi gtipB8l0KIr0BP16gQybloBLP6tiQeodJmbZffYiFzln2R9QedxqyyUgzXhonw== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791292652; b=r2ktjanX+okQa9z27RaFBFVbtMEbEf/xUxzOIeSMH7RV/VBsVj9thr83Qf+G7vU7eoFzJr bvCmuSAHnhPYtaQLeHPNxWPUaGaIdOZgWXcLR8QfCVJKhd69zxw1rSOASnjQpVJgMhURzN +Hnf+j6u3+YzPqmXY4pARtFdmO6HmlLnXEiHAhV3qhhogvYycZ+aTU1dKuiGAOaO/iwdgl ndImrXrgiXQNUPX37XEG51f6AeJZiaWhG4scSvDIIumz5I1g5KkEXlddx2y9pKGJfoYcpK Amp/BFVwGsESQmuBE1TyUoOVWGFklWZ5+r+Izfw2Lyay9kpfEaPvbDcwxhbMNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791292652; 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=/WaUTwitmktEz4/ZLdnRktb0cK1LTe9yHPksyoggEvk=; b=hAEbttSGQNrPDQ0iF4+oKQCuLG/wVm97Zh7xnDju+EQbzcmi/FNikZNbnuv3yP4ShvJoEh e7ZfwYWjD1OiZArFA8bP3h8FEkvBr8ZA7n6I+JxagrtrIaJ+4eGv5IL5jwxWpd6IGKAGrZ CUh3hXo1ZnFDbG9d8mcTNAe3kdsnfolpd6EIg2bYpr8TbtHaBx7x3JL5gz8Yq9k83fv14J bb7utfQg/WwAZ45MPgqfGnGAoof/QHzMTOxyTa2PHX+Zga9urBFS+Yzcwj7iMHfkLTX+oo 5fKZ0UZU4GqEcr7C86rdQ3aEDYfn8PQTCqGB3gM7J8CgTRTBsLBnoNO2+rHqRg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com [103.168.172.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 did not present a certificate) (Authenticated sender: seuros) by smtp.freebsd.org (Postfix) with ESMTPSA id 4hzcHc26k9z166s; Tue, 06 Oct 2026 13:17:32 +0000 (UTC) (envelope-from seuros@freebsd.org) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfauth.phl.internal (Postfix) with ESMTP id 5909DF40068; Tue, 6 Oct 2026 09:17:31 -0400 (EDT) Received: from phl-imap-04 ([10.202.2.82]) by phl-compute-06.internal (MEProxy); Tue, 06 Oct 2026 09:17:31 -0400 X-ME-Sender: X-ME-Proxy-Cause: dmFkZTG2oc4gylDHvH1FHN0isZdFIWBRsfKdmH56x9HrRAcXTrOjCCCObvbk0pgFvhhPK9 R5C7S8c4+RGG8k5nYXHlmUFOz2qCH6rq7+9p3rhlq3hjx+oIvuuUIMjrTNHBAyzmVR11n1 ZWv7O0LaQYhAS+AOMYh9MIQf5SUUKEl8hrK4vOBaMKbAxRR+HBTdMpBwpEC7MrKyWuO174 Kl3M4LnASw9c1gQYGfESe+HNxd26gNUylfI/zzVcJpDOA0f8HFdsiSZzwF/GsupRm1FXRI q+wjLj+j3AKhJYGLwNxBybtCijpVoja0LQ1Z3lkb6P9Sx3t/MYLuT53f/rmMKBedCKiPjw K62K9iaSyWt1oK0DDOt+xEbRBZxM9mbB8HKwcWJmgMBOVTiVjVK0WGY5Kgibr9PPTunZxU B0Hajq1xGgqjhR3tuFg1SlPY16jvSd20O2J2hqdh/iH+LNzViQvoCiYQ50fPS1wZbNBnqq uV5Y/Gk3JCwc43NMhDMLAdDKrIvzB7V9SkmE3+yd1HtlvtzluWMdLLZfoDPPX1G1RrRTRB 4nTBhobePgODezwja05jbdXi/YtafLZAlMgsXMkwUGkaHoSThMq3l1lMtFB6HFUmPYz/R5 9+OejM9/0l4D6MxYiBx5sWf0BJu5Sg7FU1gFJ6TV5ndL//FgzcWE2l+asxTg X-ME-Proxy: Feedback-ID: i323e4aa8:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 0AD93B6006E; Tue, 6 Oct 2026 09:17:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-ThreadId: AjEgz-Vs0qfs Date: Tue, 06 Oct 2026 13:16:41 +0000 From: "Abdelkader Boudih" To: "Vadim Goncharov" , "Jessica Clarke" Cc: freebsd-arch@freebsd.org Message-Id: In-Reply-To: <20261006132349.69e40508@nuclight.lan> References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <20261006132349.69e40508@nuclight.lan> Subject: Re: i386 kernel removal Content-Type: multipart/alternative; boundary=6323344c04791d415b2515bb7ee2922aa81de3a1 --6323344c04791d415b2515bb7ee2922aa81de3a1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I love this thread. We started by trying to remove 32-bit kernel, and so= mehow derailed into designing a FreeBSD contingency plan for when SkyNet= is fully activated. Just to entertain the scenario: if WW3 happens, FreeBSD is probably one = of the worst operating systems to pick for your post-apocalyptic compute= r.=20 We are already missing drivers for plenty of hardware that exists today,= and we only recently started getting serious about modern power managem= ent in FreeBSD 16 thanks to olce@ and others. We dont have a portable nuclear power unit like Fallout universe... I probably have lot antique hardware here, and even I have exactly one 3= 2-bit FreeBSD machine still running: an Xbox console. Not even a PC, and= I had to necromancer the code from Git history.=20 The 32-bit code is already broken in many places and has accumulated bug= s. I opened a few diffs while just trying to compile the 32-bit version.= There are more, but nobody is going to review them.=20 DragonFlyBSD removed 32-bit kernel support years ago, and they still hav= e an OS that boots on modern hardware. And if the semiconductor industry somehow collapses back to 90 nm, I sus= pect 'where is the FreeBSD i386 kernel ?' will rank slightly below food,= electricity, functioning fabs, packaging, RAM, storage, networking equi= pment, and figuring out why the only surviving monitor has VGA but your = cable is HDMI.=20 If humanity survives WW3, rebuilds semiconductor factories, gets electri= city and networking working again, clones the FreeBSD repository, and di= scovers that i386 is suddenly strategically important, I=E2=80=99m prett= y sure we can figure it out. But since we are already this deep into the scenario: what if the Pyrami= ds were the ASML of the ancient world? Then their WW3 happened, the docu= mentation was lost, and 5,000 years later we are still trying to reverse= -engineer the README. My theory makes even more sense because when I vis= ited Egypt, I saw emojis all over the pyramids just like a tik-tok feed. Maybe the real lesson here is not to remove i386. Maybe the wisdom is to= put the FreeBSD Git repository inside a pyramid to protect it from an E= MP. Also, Remember Stuxnet was 32-bit. Removing i386 is part of the FreeBSD = anti-SkyNet security strategy. Abdelkader --6323344c04791d415b2515bb7ee2922aa81de3a1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I love this thread. We started by = trying to remove 32-bit kernel, and somehow derailed into designing a Fr= eeBSD contingency plan for when SkyNet is fully activated.

Just to entertain the scenario: = if WW3 happens, FreeBSD is probably one of the worst operating systems t= o pick for your post-apocalyptic computer.
We are already missing drivers for plent= y of hardware that exists today, and we only recently started getting se= rious about modern power management in FreeBSD 16 thanks to olce@ and ot= hers.
We don= t have a portable nuclear power unit like Fallout universe...

I probably have lot antique ha= rdware here, and even I have exactly one 32-bit FreeBSD machine still ru= nning: an Xbox console. Not even a PC, and I had to necromancer the code= from Git history.
The 32-bit code is already broken in many places and has accumul= ated bugs. I opened a few diffs while just trying to compile the 32-bit = version. There are more, but nobody is going to review them.
DragonFlyBSD removed 3= 2-bit kernel support years ago, and they still have an OS that boots on = modern hardware.

An= d if the semiconductor industry somehow collapses back to 90 nm, I suspe= ct 'where is the FreeBSD i386 kernel ?' will rank slightly below food, e= lectricity, functioning fabs, packaging, RAM, storage, networking equipm= ent, and figuring out why the only surviving monitor has VGA but your ca= ble is HDMI.
If humanity survives WW3, rebuilds semiconductor factories, gets elect= ricity and networking working again, clones the FreeBSD repository, and = discovers that i386 is suddenly strategically important, I=E2=80=99m pre= tty sure we can figure it out.

But since we are already this deep into the scenario: what i= f the Pyramids were the ASML of the ancient world? Then their WW3 happen= ed, the documentation was lost, and 5,000 years later we are still tryin= g to reverse-engineer the README. My theory makes even more sense becaus= e when I visited Egypt, I saw emojis all over the pyramids just like a t= ik-tok feed.

Maybe = the real lesson here is not to remove i386. Maybe the wisdom is to put t= he FreeBSD Git repository inside a pyramid to protect it from an EMP.

Also, Remember Stuxne= t was 32-bit. Removing i386 is part of the FreeBSD anti-SkyNet security = strategy.
Abdelkade= r

--6323344c04791d415b2515bb7ee2922aa81de3a1-- From nobody Tue Oct 6 14:08:42 2026 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 4hzdQg0PTsz6vPGQ for ; Tue, 06 Oct 2026 14:08:43 +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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzdQf73HTz4PDb; Tue, 06 Oct 2026 14:08:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791295723; 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=ekjNaaXJz7FlDhZWO1sVBBTTVn+vFc+6BrZ0TKeXeuI=; b=WQt11iugeWeJiWuKTltT98F5QpHbAlrYP6z1221QD6e4cRi3jlYr6QxnLMv8LsAF50zReZ nxXWeTLSn3Im4DYAqrkrt6j8izZnK8PGUgNDBM+zY/MXlCk/iiG+M2MXpQ9CtNA7xHbj/E 8HwCS5cPHEvAKlECstErqPmMlZzp6bQq8TrhYDn/uLZfs9EYJrKoQxwnz1yR4oHA6RkRfG A1BZxXerWPxMm1SqexP06PGAjfFc1F5A3ROZ6jAzLicndi/jW4pSVENWetcqxAhgMaz33r 0tD3hIUiaANOp3G4qYV+hyoMopOk5/ZxCsPmtoA8AQtFdRbvznCW8gFxQwMDMg== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791295723; b=HV0nL/gpnprePr+5Ghj92sE8DpCiy2Fp2bNfRvp2Ct+GWHEc4FAkwpwF5IlyXrg33rnv1a vsw4h5VWVq2WBEGj5QtBypfA3ZLDJLIuoLgQjbi3hSxhw5iYFCrE45UiXNDuA/aJvApFPe 8yTskQdDYSTObUfU856d5IBL0yCvUNCPafiVYUYxbhIOokBKcyt6BkzjkP6vcvs2fCqMmp E51N9FZwr3SLAXUc9NWtblknt14W0dUeBUo9/UEh3x8ZrEaLqN7UgFXcd+2sZ2dI2vg8+a x6cobaqEMvPygyeNSDHR0MCrK6iQg3cfhdBhgVOEHtAtHuoipmhA1cu70uawow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791295723; 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=ekjNaaXJz7FlDhZWO1sVBBTTVn+vFc+6BrZ0TKeXeuI=; b=DlwQY/bXaCkN5120mS3rPMCyx1hZqYyMoaib3LqbFnATDH/B8mJM0d2axX0oHlTpXTbFfX 1OOefEWXVwI7EIg/xcIq1vAV/dIyqv5azQJoYYhuhe3bVx53DRZ5Z65epPXb8KQ68nzGq+ k6ncMDshEI2PQPqpoaNM/7MF9FPjNglbEl7MESGVpLnE/KVZaFlKdKWnsewguBmypyic0D K/AAZQ4Sb9nvwiRo4bAg+mpFXV23KtQKSZNCy0XCqHnn9LqqLJRYMEF/4EMJdds8LPd0cE 5vyUAGZdSSUcH7WRsSkSz7qKENEFHIyiN0O093NNDIpuj7Y76Ja0MgMN6Z7NQw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2601:5cc:4480:1036:3129:49c9:2e6c:45d7] (unknown [IPv6:2601:5cc:4480:1036:3129:49c9:2e6c:45d7]) (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 4hzdQf5CClz165r; Tue, 06 Oct 2026 14:08:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Tue, 6 Oct 2026 10:08:42 -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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: i386 kernel removal Content-Language: en-US To: Warner Losh Cc: freebsd-arch@freebsd.org References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/5/26 23:23, Warner Losh wrote: > On Mon, Oct 5, 2026 at 9:06 PM John Baldwin wrote: > >> After some threads on the committers mailing lists a couple of months ago, >> srcmgr@ agreed to modify our original schedule for deprecating some >> platforms back in 15.0 and to go ahead and remove i386 kernel support from >> main. >> >> Towards that end, I have been working on a branch for the past month or so >> trying to find all the bits and bobs associated with i386 kernels into a >> somewhat-organized list of commits. The recent fixes to acpi_timer(4) >> and the removal of older APM BIOS bits were part of this branch, and there >> are some more cleanups/fixes before the actual commit to remove most of >> sys/i386. At this point, what would be useful is for other folks who are >> familiar with i386-specific to look at the set of commits I have so far >> and maybe point out other things I have missed that should also be >> removed. >> >> I also have some open questions and things I'm specifically not doing: >> >> - The last few commits in this branch around stand/ I'm less certain of >> as it may still be useful (for example) to continue support booting >> FreeBSD/i386 guests in bhyve via bhyveload. So, in general I'm not >> sure how far down the path we want to go in removing stand/ support. >> Perhaps /boot/loader makes sense as if you want to boot an older >> version that has a kernel you probably want to use /boot/loader from >> that version. bhyveload is the tricky bit here I think. >> > > I'd hold off on this. The benefit is small, and there's a couple of use > cases > still around. We've had a long-term stable interface here. Booting 14 and > even 15 should work for the foreseeable future. We have to use 32-bit > mode in the loader to boot amd64.... > > The rest looks fine. > > Warner > > >> - I have made no attempt to "move" anything out of sys/x86. For >> most things that are there I don't think the churn is worth it to >> move them into sys/amd64. There are a few headers which are now >> only used on amd64 for which it may make sense to move to >> sys/amd64/include in the future. >> >> - Once the kernel is gone, i386 worlds can now only run under an amd64 >> kernel. This means we could adjust the ABI of i386 perhaps to >> assume the amd64 baseline (SSE2, etc.). We already assume 64-bit >> atomics via cmpxchg8b. This would be equivalent to using the lib32 >> library builds (e.g. specialness around FSBASE/GSBASE in lib32 is >> something we might want to enable for plain i386). I have not done >> any of this and do not intend to make any such changes in this branch. >> >> - I have not stubbed out i386-specific things in userspace that won't >> work without an i386 kernel (e.g. i386_vm86(2)). The amd64 kernel >> will already fail these things, but there might be i386-only >> programs or daemons similar to apmd(8) (recently removed) that my >> branch doesn't yet remove that should be on the chopping block. If >> you know of something I'm missing, please let me know. >> >> - When device drivers were not specifically tied to i386 just only >> made sense / were enabled on i386, I have split removing those >> out to separate commits to make it easier to fetch them out of >> history in the future if they are ever needed for some other >> architecture. >> >> - I'm currently stuck keeping sys/i386/linux as libsysdecode uses >> it for SYSDECODE_ABO_LINUX on i386. Probably I should just >> change the i386 build to use the amd64 linux32 tables instead. >> >> You can see the current branch here (note that I frequently rebase >> it): >> >> >> https://github.com/freebsd/freebsd-src/compare/main...bsdjhb:freebsd:rm_i386_kernel >> >> -- >> John Baldwin >> >> >> >> >> >> On Mon, Oct 5, 2026 at 9:06 PM John Baldwin > wrote: >> >> After some threads on the committers mailing lists a couple of months ago, >> srcmgr@ agreed to modify our original schedule for deprecating some >> platforms back in 15.0 and to go ahead and remove i386 kernel support from >> main. >> >> Towards that end, I have been working on a branch for the past month or so >> trying to find all the bits and bobs associated with i386 kernels into a >> somewhat-organized list of commits.  The recent fixes to acpi_timer(4) >> and the removal of older APM BIOS bits were part of this branch, and there >> are some more cleanups/fixes before the actual commit to remove most of >> sys/i386.  At this point, what would be useful is for other folks who are >> familiar with i386-specific to look at the set of commits I have so far >> and maybe point out other things I have missed that should also be >> removed. >> >> I also have some open questions and things I'm specifically not doing: >> >> - The last few commits in this branch around stand/ I'm less certain of >>    as it may still be useful (for example) to continue support booting >>    FreeBSD/i386 guests in bhyve via bhyveload.  So, in general I'm not >>    sure how far down the path we want to go in removing stand/ support. >>    Perhaps /boot/loader makes sense as if you want to boot an older >>    version that has a kernel you probably want to use /boot/loader from >>    that version.  bhyveload is the tricky bit here I think. >> >> >> I'd hold off on this. The benefit is small, and there's a couple of use cases >> still around. We've had a long-term stable interface here. Booting 14 and >> even 15 should work for the foreseeable future. We have to use 32-bit >> mode in the loader to boot amd64.... To be clear, the only change here for /boot/loader is to remove the actual bits to load an i386 kernel, not executing the loader as a 32-bit binary. -- John Baldwin From nobody Tue Oct 6 14:11:09 2026 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 4hzdTV4kbVz6vP5P for ; Tue, 06 Oct 2026 14:11:10 +0000 (UTC) (envelope-from mchoo@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzdTV497Cz4PXW; Tue, 06 Oct 2026 14:11:10 +0000 (UTC) (envelope-from mchoo@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791295870; 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=lLYqgla67f4rDkcicHE2CK1LJ+Wl89reyD/DHFcaRuM=; b=oMPH8U8W/3eqvAoRVbSW6/9d/mBe+UNuEzXhyA2gpqiyJTXAUXKsgp9EcavKXUv6TbLWjt HzOdPpZX1u7hOc6OhTS3plIF4yexRT0piT8zqAdPODu2uR8ZLW/MsAQgewOZZliJ6ctWP1 gdZmSYbdE/B7LKsgcDN7XC1MMbZR7wqFXX0hqZO6r70AmUDR8MpBGptGCTvPsu9IopKgNT 8vsx18tpV4EWchrEvPL70fwEfLR8kIN8KeCFpMTBmvEHFCWETsBUCCtFaWuG4n0xPZ6Xjt Z2voKbYIhlFVedh3pftz14hgYG7gsk46z1K2u3fwGORoqKFwt+IjL0TDAGVEyA== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791295870; b=esi0pmh7LxL59LiCT5ovgDTOR9fAZXedWo/u7TR5sYWUhVoQdn2DgqRiWWXkB17L0dNNXk O2JVAXY44cHAL/jk0/MQoZz0hdZ5X9FTIEp8GaL0Y65wMFFDp8Yv0waX4f/ZXFdgUeX9Sb nZVETNU0YpYeXRBZg5oXpJ+RrcmIoZQWNefrGEG2cgOfOtknXtWbWaVImG4+4cxSX9B6xp YmICeRH/x3Jmhpc/MPKsBsBPaEz2gxuIPCj3HDbysvGoBHcGFvZuWdWIP8YxJJkKOUbgxR FhaqrPXzuZhfd5ysDyJhdSrUNTATNw+SlOoZ71jduJvsb3fxM51MNaa/QPzFKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791295870; 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=lLYqgla67f4rDkcicHE2CK1LJ+Wl89reyD/DHFcaRuM=; b=SHOCeXDE0pL2HcrJpMrb39AV9nzA4HKeHq7rAUYmCN94BXorv9IA+clPXQBxjtBktglM/d zVwbg5m1Pn5UW3wCbXnDrncPUCoBvD4SVMrQLKaYxf2CiQMxJykH8vUdfChtG2+s3w1Wju TDYj1QdqpHaq7VjBGbugju84Fgt3QSTlZwoImj4C+lsO+iY0CIss9noXDnKnncrZQj3x9n whDlqEozeQ3rbFC8nXf+qN5EUpRZipOpJaRs2izRCIgunxONr8MQTUxLLgHsFq/XiZ70r7 j0m79flNwuiLgzDFAzkf8OZKOLvZbdRUfgPlaJqyxDey7Q8qeXzO9HxlpHI3jA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.31.133.153] (unknown [72.142.18.42]) (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: mchoo/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4hzdTV1Bfpz16xv; Tue, 06 Oct 2026 14:11:10 +0000 (UTC) (envelope-from mchoo@FreeBSD.org) Content-Type: multipart/alternative; boundary="------------xTPGimeJpNnTq70H0SFxKWoH" Message-ID: Date: Tue, 6 Oct 2026 10:11:09 -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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: i386 kernel removal To: Eugene Andrienko , Jessica Clarke Cc: Vadim Goncharov , freebsd-arch@freebsd.org References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> Content-Language: en-US From: Minsoo Choo In-Reply-To: <864iez82sg.fsf@drag0n-laptop.lair.internal> This is a multi-part message in MIME format. --------------xTPGimeJpNnTq70H0SFxKWoH Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026-10-06 07:51, Eugene Andrienko wrote: > So, I'm also joining to the same question: Why remove i386 support if it > works and there are no new hardware in the near future? As I understand > this is something like "complete software" [1], which will not rot while > lying in the source tree? > > [1]https://my-notes.dragas.net/2026/01/06/the-virtue-of-finished-things/ > > -- > Eugene Andrienko i386 is already broken. To quote seuros@: On 2026-10-06 09:16, Abdelkader Boudih wrote: > I probably have lot antique hardware here, and even I have exactly one > 32-bit FreeBSD machine still running: an Xbox console. Not even a PC, > and I had to necromancer the code from Git history. > The 32-bit code is already broken in many places and has accumulated > bugs. I opened a few diffs while just trying to compile the 32-bit > version. There are more, but nobody is going to review them. > DragonFlyBSD removed 32-bit kernel support years ago, and they still > have an OS that boots on modern hardware. And I believe me and you are already dealing with broken i386 code, although you might not have noticed. The sigtramp.S test case failure affects i386 as well and it needs update on llvm/libunwind side. I'm not doing that work because llvm already suffers from lack of reviewers and there is no reviewers left especially for i386. Removing i386 is not our own problem, but it is connected to third-party dependencies (especially llvm) that we rely on. armv7 still seems to be supported thanks to developers hired by Arm, but once Arm gives up maintaining armv7-A, we might need to drop it. One might ask keeping our own i386 patch in the base system but based on how frequently llvm change their private APIs, I don't know if the churn is worth it. It might further delay MFVing next llvm release which I don't want to see. -- Minsoo Choo --------------xTPGimeJpNnTq70H0SFxKWoH Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

On 2026-10-06 07:51, Eugene Andrienko wrote:

So, I'm also joining to the same question: Why remove i386 support if it
works and there are no new hardware in the near future? As I understand
this is something like "complete software" [1], which will not rot while
lying in the source tree?

[1] https://my-notes.dragas.net/2026/01/06/the-virtue-of-finished-things/

--
Eugene Andrienko

i386 is already broken. To quote seuros@:

On 2026-10-06 09:16, Abdelkader Boudih wrote:
I probably have lot antique hardware here, and even I have exactly one 32-bit FreeBSD machine still running: an Xbox console. Not even a PC, and I had to necromancer the code from Git history.
The 32-bit code is already broken in many places and has accumulated bugs. I opened a few diffs while just trying to compile the 32-bit version. There are more, but nobody is going to review them.
DragonFlyBSD removed 32-bit kernel support years ago, and they still have an OS that boots on modern hardware.

And I believe me and you are already dealing with broken i386 code, although you might not have noticed. The sigtramp.S test case failure affects i386 as well and it needs update on llvm/libunwind side. I'm not doing that work because llvm already suffers from lack of reviewers and there is no reviewers left especially for i386. Removing i386 is not our own problem, but it is connected to third-party dependencies (especially llvm) that we rely on. armv7 still seems to be supported thanks to developers hired by Arm, but once Arm gives up maintaining armv7-A, we might need to drop it.

One might ask keeping our own i386 patch in the base system but based on how frequently llvm change their private APIs, I don't know if the churn is worth it. It might further delay MFVing next llvm release which I don't want to see.

--

Minsoo Choo

--------------xTPGimeJpNnTq70H0SFxKWoH-- From nobody Tue Oct 6 14:15:08 2026 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 4hzdZL0Fm0z6vPTd for ; Tue, 06 Oct 2026 14:15:22 +0000 (UTC) (envelope-from mm@dorfdsl.de) Received: from srv1.dorfdsl.de (srv1.dorfdsl.de [IPv6:2a01:170:118f:3::22]) (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 (prime256v1) client-digest SHA256) (Client CN "srv1.dorfdsl.de", Issuer "YE1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzdZK0Lqtz4QSL for ; Tue, 06 Oct 2026 14:15:20 +0000 (UTC) (envelope-from mm@dorfdsl.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dorfdsl.de header.s=default header.b=xAuMApF9; spf=pass (mx1.freebsd.org: domain of mm@dorfdsl.de designates 2a01:170:118f:3::22 as permitted sender) smtp.mailfrom=mm@dorfdsl.de; dmarc=pass (policy=none) header.from=dorfdsl.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorfdsl.de; s=default; t=1791296109; bh=glImrtBj1W/4rJEco4Cvm3T/GrApEFS7sGuvva9oUbM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=xAuMApF9naBQYQbPKT8NsTgjs2ZVGIS2+WJu4p5xWvXUpQgihJiyAMceEFD5bBkyZ 2QL5dOVPCSc3Kmbl1S5sJeS5Rhu1gqewzkbD07M/UkHimaXINM3K+r0p9gRFkrNNfm 1pVAcVOkyI54JNRh08iTrrIr9BNMtPYD3n/U5uFMU/oMG0GK0vN4rXhv1qcxp5yQQb NdGmnrXfKeoAjgA0DIDCrBiBUx9wEBI850v/KZtDsYRYNqi22wCbLH8tkF6uKTEerD qLF37TiIUOaRaOnD28W28iRfs5Eu9iD8quCLnyTNah5L7nzWq6pO5hgqaIsdskzzIN /XjbBAQczey5g== Received: from [IPV6:2a01:170:118f:2:4243:9422:d1b9:bd77] ([IPv6:2a01:170:118f:2:4243:9422:d1b9:bd77]) (authenticated bits=0) by srv1.dorfdsl.de (8.18.1/8.18.1/Debian-6) with ESMTPSA id 696EF8YL025664 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 6 Oct 2026 16:15:09 +0200 Message-ID: Date: Tue, 6 Oct 2026 16:15: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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: i386 kernel removal To: freebsd-arch@freebsd.org References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> Content-Language: en-US, de-DE From: Marco Moock Autocrypt: addr=mm@dorfdsl.de; keydata= xsDNBGnlI3gBDADDY5KSROZxxR7vS37LLqDMm0DyhP+6ou/D79MU+w+44OuNicr384mEMVAg PRSoig//mla8oso9fhwcu8G2IqWGzIzE8YKVq40veyJPGeOATMIbsI69oIKBjYZt7Vnw8g0Z 6iQq/9JqYRmHprtm9DPS4PME528f29jCTXOhmd7+RIHnNPiAa8Q7DDILZADRY03ksxDPYmRY 543dnDqIEuECamRfaahfJrMSJkmTt4UJEe1ZxCp1rUdgBbxrOyQyF5gVIdWr06+fyFnxpg6u YfuHl7OzPHYzHoOrNY0U9AEldW4QrNDIOqAJZVjxeWa9u2oxnIUCGMxQ/dHg5tTk+CDl2mXE aCAqOaQ5lcKFsxx7KR/BQfuRQW+Sm6meJmQQLHcWablpafAWSnqrZjz+5qflYj3CiN3vYXjE rpjLzPov3gOlfOGDXqkHTXmaenmB1HUybdpKRX0PH0r+LGJlA5U1cfy1IlvB9ZY8C2gGGRE7 LQTl228a1nvCis7+MRQm/pkAEQEAAc0bTWFyY28gTW9vY2sgPG1tQGRvcmZkc2wuZGU+wsEO BBMBCgA4FiEEGHxuJD2s+A3zICvbVZ4aMxpGtGMFAmnlI3gCGwMFCwkIBwIGFQoJCAsCBBYC AwECHgECF4AACgkQVZ4aMxpGtGOiwQv8D202XflE5ipU1uhx6VyqcZ/IQ5/eiMs+gGbm3GFK SIBpQBy2c+QDRFf7zhB/r3omVB6PHrVJGBU/T1m3BKNmCdnp1JaczjOybt+MNQGtm5RgWhpk 3he7gyp0vnT3Vy8fs2fF+pnnrt4IOnHu6hKWGXINSUxcZknRI2SFcJuYYbg+EXD/ShyDIPA0 qihw74kSY+yoa09D+W6qxrSf0+dgUUWobPwhIrPG6ypFqu5rcy/ByvifRH4vz2+C7iWF4Rtt 1U+74CqiEspF/b9B6zzg3PsdEaiuRBI4S6bJXZiMLH1cUFY4sGjSW8Qbt5/hZB9NiToW3VoY lBHohdCPRI4haEJTyZ5n7irXozO6Z/3Ikq+7jDS5I4c5v1PqFgorqiRbbh2yMKi7F2WfJcjK b2JNz7wvLAKmfqH1JO0TmmzdzCidXUOJd3zti5PyTrRrZHNWK1aAG72mhug67zTgr81zW0ph F9diJYbQVBCe27TVssm9gN3eNGrZIBQkHfI/wNaBzsDNBGnlI3gBDADjXrGqJttd4WsQ/iiZ cUA+2Qh5HMJuLSuIjBTkv/sZX5kUwWhDbXFW28TlNwEk5ogtByLOq4kmgsygZU0nk1DfpDKw yumc1n6+ReBpYNTkWUfxF3unpMuO4BE+sfEFlCJe6fjC2yTzwrC/Ls+EjkbvRzHiCfJrddQx /iKEBWCJVlWuwB4iEvO0EZh9eYPulx+p0iJRRGdRH3RBIJyQXK8sEFsfMTzOCXHwVfjkVmBc CZHviGaG5Urn7f7aHfpfxV9mN8Idxa1Eksgi/9aCuTHFQwfeyrTsNVfp1MUKG/H85/uRieXc 5MnF8i7f7luBSJCnZcqTjN0q/jLD6GJyMbnoKA71pzAlEC0EaK9MIZgSz7m4nh/JCBXPL6+t bc26lD6HDNLqMCfD2uvbpdkY/gjOo661W9fIZ+V33N+veH0ckCI8SByiJRSOotYK2rBFlfnh JzucC0yQvNxtcxlnrPvb5mt5cUMlxI1xWO4aQ+pHmZALLItna0ODS6jujxZZNkkAEQEAAcLA 9gQYAQoAIBYhBBh8biQ9rPgN8yAr21WeGjMaRrRjBQJp5SN4AhsMAAoJEFWeGjMaRrRjNUQM AKivzYaSLxYCB/IVLZpexHssAN0IBOwuEFkfMfmzSRNPLakMA0PhzJvy0HkNVT9l+7X4Uu3X +5KkPdLKPs0Z8h8h18vxKUCkknEUY3dT5EVeNAgSshxjxmCAVvQvHdW6ZBxYNJoHQrU1xpkr EHwNP6I/VqH+C6aSncXq8TU3LeBT9l58douj6JknXaiEblQj9SUWtYWVVK4/+PqOpWrbE1kB fwkMGlFHpRQzIsAkIGqnUes/RoM1EszeYNjvKAuNaw5ghUDwgQbd8MIIoi0S82kpvflJSLzQ KziNuzyunAUeJeFW9PQ2BzOf4gK9G3+pqkpLQ2OdwDL/TAqlzElWX7O2hW0X+L2+6dPOYGey HTsU2eYMeB2q6VQpJEas3ebWHRANt31wA2mvSQKbYJJYofxThfCMUcKD0CUHduEXwdahB7Vy PDCIU7kwmN2JG5n4foywEym/i942UyTQu30MtPpuhwBhpka5jG6wiFfpQAdwsb0QF0Gpzcet MCwzZXR/AA== Organization: keine vorhanden, alles chaotisch In-Reply-To: <864iez82sg.fsf@drag0n-laptop.lair.internal> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------q0h92zUF8i4PpweNoLtnDfmD" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.80 / 15.00]; SIGNED_PGP(-2.00)[]; DMARC_POLICY_ALLOW(-0.50)[dorfdsl.de,none]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[dorfdsl.de:s=default]; R_SPF_ALLOW(-0.20)[+ip6:2a01:170:118f:3::22]; MIME_BASE64_TEXT(0.10)[]; ASN(0.00)[asn:8820, ipnet:2a01:170::/32, country:DE]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; FREEFALL_USER(0.00)[mm]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_TRACE(0.00)[dorfdsl.de:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4hzdZK0Lqtz4QSL This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------q0h92zUF8i4PpweNoLtnDfmD Content-Type: multipart/mixed; boundary="------------VBy4iZehqOpe4Rm1wUC000Er"; protected-headers="v1"; hp="clear" Message-ID: Date: Tue, 6 Oct 2026 16:15:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: i386 kernel removal To: freebsd-arch@freebsd.org References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> Content-Language: en-US, de-DE From: Marco Moock Autocrypt: addr=mm@dorfdsl.de; keydata= xsDNBGnlI3gBDADDY5KSROZxxR7vS37LLqDMm0DyhP+6ou/D79MU+w+44OuNicr384mEMVAg PRSoig//mla8oso9fhwcu8G2IqWGzIzE8YKVq40veyJPGeOATMIbsI69oIKBjYZt7Vnw8g0Z 6iQq/9JqYRmHprtm9DPS4PME528f29jCTXOhmd7+RIHnNPiAa8Q7DDILZADRY03ksxDPYmRY 543dnDqIEuECamRfaahfJrMSJkmTt4UJEe1ZxCp1rUdgBbxrOyQyF5gVIdWr06+fyFnxpg6u YfuHl7OzPHYzHoOrNY0U9AEldW4QrNDIOqAJZVjxeWa9u2oxnIUCGMxQ/dHg5tTk+CDl2mXE aCAqOaQ5lcKFsxx7KR/BQfuRQW+Sm6meJmQQLHcWablpafAWSnqrZjz+5qflYj3CiN3vYXjE rpjLzPov3gOlfOGDXqkHTXmaenmB1HUybdpKRX0PH0r+LGJlA5U1cfy1IlvB9ZY8C2gGGRE7 LQTl228a1nvCis7+MRQm/pkAEQEAAc0bTWFyY28gTW9vY2sgPG1tQGRvcmZkc2wuZGU+wsEO BBMBCgA4FiEEGHxuJD2s+A3zICvbVZ4aMxpGtGMFAmnlI3gCGwMFCwkIBwIGFQoJCAsCBBYC AwECHgECF4AACgkQVZ4aMxpGtGOiwQv8D202XflE5ipU1uhx6VyqcZ/IQ5/eiMs+gGbm3GFK SIBpQBy2c+QDRFf7zhB/r3omVB6PHrVJGBU/T1m3BKNmCdnp1JaczjOybt+MNQGtm5RgWhpk 3he7gyp0vnT3Vy8fs2fF+pnnrt4IOnHu6hKWGXINSUxcZknRI2SFcJuYYbg+EXD/ShyDIPA0 qihw74kSY+yoa09D+W6qxrSf0+dgUUWobPwhIrPG6ypFqu5rcy/ByvifRH4vz2+C7iWF4Rtt 1U+74CqiEspF/b9B6zzg3PsdEaiuRBI4S6bJXZiMLH1cUFY4sGjSW8Qbt5/hZB9NiToW3VoY lBHohdCPRI4haEJTyZ5n7irXozO6Z/3Ikq+7jDS5I4c5v1PqFgorqiRbbh2yMKi7F2WfJcjK b2JNz7wvLAKmfqH1JO0TmmzdzCidXUOJd3zti5PyTrRrZHNWK1aAG72mhug67zTgr81zW0ph F9diJYbQVBCe27TVssm9gN3eNGrZIBQkHfI/wNaBzsDNBGnlI3gBDADjXrGqJttd4WsQ/iiZ cUA+2Qh5HMJuLSuIjBTkv/sZX5kUwWhDbXFW28TlNwEk5ogtByLOq4kmgsygZU0nk1DfpDKw yumc1n6+ReBpYNTkWUfxF3unpMuO4BE+sfEFlCJe6fjC2yTzwrC/Ls+EjkbvRzHiCfJrddQx /iKEBWCJVlWuwB4iEvO0EZh9eYPulx+p0iJRRGdRH3RBIJyQXK8sEFsfMTzOCXHwVfjkVmBc CZHviGaG5Urn7f7aHfpfxV9mN8Idxa1Eksgi/9aCuTHFQwfeyrTsNVfp1MUKG/H85/uRieXc 5MnF8i7f7luBSJCnZcqTjN0q/jLD6GJyMbnoKA71pzAlEC0EaK9MIZgSz7m4nh/JCBXPL6+t bc26lD6HDNLqMCfD2uvbpdkY/gjOo661W9fIZ+V33N+veH0ckCI8SByiJRSOotYK2rBFlfnh JzucC0yQvNxtcxlnrPvb5mt5cUMlxI1xWO4aQ+pHmZALLItna0ODS6jujxZZNkkAEQEAAcLA 9gQYAQoAIBYhBBh8biQ9rPgN8yAr21WeGjMaRrRjBQJp5SN4AhsMAAoJEFWeGjMaRrRjNUQM AKivzYaSLxYCB/IVLZpexHssAN0IBOwuEFkfMfmzSRNPLakMA0PhzJvy0HkNVT9l+7X4Uu3X +5KkPdLKPs0Z8h8h18vxKUCkknEUY3dT5EVeNAgSshxjxmCAVvQvHdW6ZBxYNJoHQrU1xpkr EHwNP6I/VqH+C6aSncXq8TU3LeBT9l58douj6JknXaiEblQj9SUWtYWVVK4/+PqOpWrbE1kB fwkMGlFHpRQzIsAkIGqnUes/RoM1EszeYNjvKAuNaw5ghUDwgQbd8MIIoi0S82kpvflJSLzQ KziNuzyunAUeJeFW9PQ2BzOf4gK9G3+pqkpLQ2OdwDL/TAqlzElWX7O2hW0X+L2+6dPOYGey HTsU2eYMeB2q6VQpJEas3ebWHRANt31wA2mvSQKbYJJYofxThfCMUcKD0CUHduEXwdahB7Vy PDCIU7kwmN2JG5n4foywEym/i942UyTQu30MtPpuhwBhpka5jG6wiFfpQAdwsb0QF0Gpzcet MCwzZXR/AA== Organization: keine vorhanden, alles chaotisch In-Reply-To: <864iez82sg.fsf@drag0n-laptop.lair.internal> --------------VBy4iZehqOpe4Rm1wUC000Er Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 QW0gMDYuMTAuMjYgdW0gMTM6NTEgc2NocmllYiBFdWdlbmUgQW5kcmllbmtvOg0KPiBJIGFn cmVlIHdpdGggVmFkaW0gR29uY2hhcm92IGhlcmUsIGJ1dCBJIHdhbnQgdG8gYnJpbmcgbm90 IHNvDQo+IGFwb2NhbHlwdGljIHNjZW5hcmlvcywgYnV0IGV2ZW50cyB0aGF0IGFyZSBoYXBw ZW5pbmcgcmlnaHQgbm93LiBUaGUgbmV3DQo+IGFuZCBtb2Rlcm4gY29tcHV0ZXIgaGFyZHdh cmUgbm93YWRheXMgbWF5IGJlIGluYWNjZXNzaWJsZSBiZWNhdXNlIG9mDQo+IGluZmxhdGlv biAodG9vIGJpZyBwcmljZXMgLSBiZXR0ZXIgdG8gYnV5IGZvb2QsIHRoYW4gSGlFbmQsIG5v dCBzbyB3ZWxsDQo+IHJlcGFpcmFibGUgY29tcHV0ZXIpLCBpdCBtYXkgYmUgaW5hY2Nlc3Np YmxlIGJlY2F1c2Ugb2Ygc2FuY3Rpb25zDQo+ICh3YXZpbmcgZnJvbSBSdXNzaWEsIG1vc3Qg b2YgbmV3IGhhcmR3YXJlIGZvciB1c3VhbCBwZW9wbGUgbm93IGNvbWVzDQo+IGZyb20gQWxp RXhwcmVzcyBhbmQgb3RoZXIgQ2hpbmVzZSBtYXJrZXRwbGFjZXMpLCBvciBpdCBtYXkgYmUg dG9vDQo+IGV4cGVuc2l2ZSBiZWNhdXNlIG9mIG5ldyB0YXhlcywgaW1wb3NlZCBieSBnb3Zl cm5tZW50ICh3YXZpbmcgZnJvbSB0aGUNCj4gc2FtZSBjb3VudHJ5KS4gQW5kIGFsc28gd29y dGggdG8gbWVudGlvbiBSQU0sIFNTRCBhbmQgSEREIHNob3J0YWdlcw0KPiBiZWNhdXNlIG9m IExMTXMuDQo+IA0KPiBTbywgdGhlIG9sZCBoYXJkd2FyZSBmcm9tIGNsb3NldHMgYXJlIGlu IHVzZSBhZ2Fpbi4gQW5kIG5vdCBvbmx5IGZyb20NCj4gY2xvc2V0cywgZS5nLiBJIGNvdWxk IGJ5IGEgc2Vjb25kLWhhbmQgaW5kdXN0cnVhbCBQQyAoaGlnaGx5IGxpa2VseSB3aXRoDQo+ IGkzODYgYmFzZWQgQ1BVIGluc2lkZSkgZnJvbSBzb21lIGJyb2tlbiBpbmR1c3RydWFsIG1h Y2hpbmUgYW5kIHVzZSBpdCBhcw0KPiBhIFBDIGZvciB1c3VhbCB0YXNrcywgbGlrZSBlLW1h aWwgcmVhZGluZywgdGV4dCBlZGl0aW5nLCBldGMuIEUuZy4gbXkNCj4gbWFpbiBzZXJ2ZXIg aXMgYSBjYXNoIHJlZ2lzdGVyIGZvciAzMCQgYW5kIHdpdGggSW50ZWwgQXRvbSBOMjgwMCAo eDg2XzY0DQo+IGZyb20gMjAxMSB5ZWFyISkgaW5zaWRlLg0KDQpUaGUgbW9zdCBoYXJkd2Fy ZSB5b3UgZmluZCBvbiB0aGUgc2NyYXB5YXJkIG5vdyBhbHJlYWR5IGhhcyB4ODZfNjQuDQpJ dCBpcyB0aGUgc3RhbmRhcmQgYXJjaGl0ZWN0dXJlIGZvciAyMCB5ZWFycyBub3cgKEkga25v dyB0aGF0IGEgZmV3IA0KZXhjZXB0aW9ucywgbGlrZSBzb21lIGVhcmx5IEludGVsIEF0b20s IGV4aXN0KS4NCg0KDQotLSANCkdydcOfDQpNYXJjbw0KTXVlbGwgdW5kIFNwYW0gYml0dGUg YW4gYWJmYWxsZWltZXIyMDAyQHN0aW5rZWRvcmVzLmRvcmZkc2wuZGUNCg== --------------VBy4iZehqOpe4Rm1wUC000Er-- --------------q0h92zUF8i4PpweNoLtnDfmD Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGHxuJD2s+A3zICvbVZ4aMxpGtGMFAmrFAmwFAwAAAAAACgkQVZ4aMxpGtGN+ vgv+MMQVjCuRMOOyA4uLujpXRTcypw+JlVgaFCXzT9IOHUobYRd4YgGMtS4hv9MDRADvqFZpeEYR jtVD37ikpo/AVmW9BWAPIU9eHTPh+Fxaam1Qr4ZEYqBW3hEvwWne1x4warlldwj7niOhmKkNOtmW 1ivG9FgXhtb9zVottrAiNd1BEbzntmuv+GsaFoHE0QOOh7vj6eb2b3GandqbC49BrQZ1lNgSGm70 hQKRv3NiPf7fRfEEwExz6dNQDStCPjLSIGYQ7bKjfai1Jz4hKt6OyoV0FyJZAo3HIp8BSTUXZh+D B7mTUudQ/xRcXklxqSUFc/pRdiMCHfF2dwYJPAplPIatrBUMB8q2E5MyG4Jo81BndnBQ30S/wESx deVOTgkKUPg8lTyrHBERqsMOAaa1WBB4pXkRrR7xaablTeJzCLHPLRJEthz3nC4hpNWNMfT60fUl /S8XRsXBfzg0kxIEyQx6b/qxuxhhANIH27+ScTNP7WqyjGCYHfhf9Ll0coc+ =jXHO -----END PGP SIGNATURE----- --------------q0h92zUF8i4PpweNoLtnDfmD-- From nobody Tue Oct 6 14:23:03 2026 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 4hzdlV0mVdz6vPtl for ; Tue, 06 Oct 2026 14:23:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yx1-f49.google.com (mail-yx1-f49.google.com [74.125.224.49]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzdlT1S2Vz4RqP for ; Tue, 06 Oct 2026 14:23:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; arc=pass ("google.com:s=arc-20260327:i=1"); spf=pass (mx1.freebsd.org: domain of adrian.chadd@gmail.com designates 74.125.224.49 as permitted sender) smtp.mailfrom=adrian.chadd@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none) Received: by mail-yx1-f49.google.com with SMTP id 956f58d0204a3-67699afea08so729010d50.3 for ; Tue, 06 Oct 2026 07:23:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1791296596; cv=none; d=google.com; s=arc-20260327; b=nAkF02CV8p8CzGr1lWq3/wY6vpItBgnzubkG1eBWXP3QGj/R1GHFqsQNtu/zQkwhbN 9eWsJ+lQJePCkbKcLQGjFcdti5nJRtXEDzVeaipuGS57ttPvpakEsAmD1WvzFQ0UCykv Qld4AO4o/y8NuOSUxWT4XUVDvgoBgZfXZ1G3l5mcbonx76IC9obfHxyMDTW4eoDRNDTS nHy80Ubane/MoyhvTRH2hSUOI8Nh/61I4vrLJBMHnmMfzaIw2SfulMvZpLiMRAbeTR3k 5dRB/GOBPX2GQRg9Vxwp4hMWL8xHgpKBIKW9IgtP8MSpj8VNMVFsHbkqWrF0ih2pchTk dXkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version; bh=ihweohKaYihSBKv4KSdTjQsdHBOBsocLkfC1kuABMsk=; fh=6xuScgZQxV1MlfPakgeu8KMcV7r3xtdOsDG34gcyLQA=; b=Pw4Hl8eO9yxtRUKVQ4xAPJskhTmDsspkMqGKdLJJRa0sxHCaxunX+4zVVQGGys2Ths cE+Es4ohzzWuhnDyZxIGM/XbqlRr5yKsMDiyVl9ddhaFAgScmXBUCVmrZYCo5YNHEDlu BH4buYxEjdmyPA0PjVQGjRBquuSOC2fU2ngq8e2ewdFHEvVg3fYV+Pg1a89At0G2U53p f90DI/J/5U3RjUZuONJQHxLDT4qhr5Od3t1qBaza3lB1q15ykO7XfTZV701cammmXOur wONXPOezVuVytS0yNjs1ky1G+jJpgmAj4bTyf2LSOjY1kDcYD6jGHdPqrCzRFocv4Y0Y 1LNg==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791296596; x=1791901396; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=ihweohKaYihSBKv4KSdTjQsdHBOBsocLkfC1kuABMsk=; b=qPuTheFi9Q/gh5jESknzC9OtAU0XMx9Qe7C/IciE90F3EYctVqKTgGU8g9oI8Y817R I7kB7Bp7f/DYanvo7S4UouFes3caP8r+4BC1dOptc9BuVdTzCNFslg2Y5TTHqBZtiKV9 js6OC6PVyMIhGcQxjpPapPyONYCCBf68xyaN+gP/eWFDiyf95I2KmTb+FXlPkcEphpUh 79Fd3nW5m/58ykP6UpdZsZEEfnCy6U7qvxIdXIPiUpMcPWv/bHFhZ7L6fxO/CzlhRXGk +rYbkqeHaq/OGSdWHfswc14uGI4ahrp2ynWcOTXx/Nlf8jlRFTbLUi0f6Sn3JgIuMkqo nV8A== X-Forwarded-Encrypted: i=1; AKwUvByRijBTe1iiCmnQWFW3uVUc6xf9zTBLe4LdczzuHuqT4rEdl9+pha+VYjbFhKkwN6SDG7r2zYwZoIRVqgE=@freebsd.org X-Gm-Message-State: AFq9FYKC6QPWu2TCIztpbeQmhPaE4WRID8tzA4NAD0/G7RIsG+pxnpG0 S9wfvt0Dy527f2/cbbvCL6RPuvtPUMjN9Q1No/o0RdbCp8LG/HySs6a0wwmLOaE5+JldON9TOTk 8i9Ol+EJCZ8cK1b/3wr4QvEbLrV6TuCI= X-Gm-Gg: AYBFou0uHe9gZpIq9Oi3m+0rip6sczkzzJoXqTf15rrqIGNSSWe4k9K8YQWMJAQMPm5 6/f8ktYoVLlu8Z3Zi+vT8ABEk7cQB3dD+zQDnAFE496ZAPbQPzv4TD33h383YhilkhHjnBduyFM 2iWf3f25j9OhI0BNThgGpVOp3GVeH9TRWBusS+aR5vTuNxC+rOv2DQwTMKi5EA+SdsEQFf3s80M boksdXNJxQPomDPtjJ5zXEsf5mQKK+rZyh+LSt2dceraKy3NgK2ORbIltPavO1E/pFWsadjCTjP DG9mVK7sLfpWt010sNq3xFX7oXM+Uq16ZvvCYzq3pANMkC3FV+CE8U6fLmZPSGCVkzTmNZisZrF b/Wp0MuTcCVclk6H2N9utlwr4TU5UzkUFTK2W1zQwPhwTgzco9MG/Q0/TWOwm34OO19KhALEurt WOKRuXDKTfWg5H3oM5PSQgXyMT7jysWexAZJeCzGsFvHi+1qlLC+wYy9a94x5gdXi7GROm6a2fd veukc0Mj1jcmPY= X-Received: by 2002:a05:690e:4802:b0:675:6bb2:cc9c with SMTP id 956f58d0204a3-678fce42d35mr490687d50.121.1791296595874; Tue, 06 Oct 2026 07:23:15 -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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> In-Reply-To: From: Adrian Chadd Date: Tue, 6 Oct 2026 07:23:03 -0700 X-Gm-Features: AclHuK9gZVBlS5-4nXYigm0B_5oIoqJrGMD0a72u0w-ZQLCoDpMj_8VRBa9HEc8 Message-ID: Subject: Re: i386 kernel removal To: Minsoo Choo Cc: Eugene Andrienko , Jessica Clarke , Vadim Goncharov , freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="00000000000048d905065d2cbd58" X-Spamd-Bar: / X-Spamd-Result: default: False [-0.90 / 15.00]; ARC_ALLOW(-1.00)[google.com:s=arc-20260327:i=1]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:74.125.0.0/16:c]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RWL_MAILSPIKE_POSSIBLE(0.00)[74.125.224.49:from]; ASN(0.00)[asn:15169, ipnet:74.125.0.0/16, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; ALIAS_RESOLVED(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[74.125.224.49:from]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; MISSING_XM_UA(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_FIVE(0.00)[5] X-Rspamd-Queue-Id: 4hzdlT1S2Vz4RqP --00000000000048d905065d2cbd58 Content-Type: text/plain; charset="UTF-8" maybe we can add an i386 tag to reviews to make it easier to find that stuff and get it reviewed. (do you tag them as 'x86' at the moment?) -adrian On Tue, 6 Oct 2026 at 07:11, Minsoo Choo wrote: > On 2026-10-06 07:51, Eugene Andrienko wrote: > > So, I'm also joining to the same question: Why remove i386 support if it > works and there are no new hardware in the near future? As I understand > this is something like "complete software" [1], which will not rot while > lying in the source tree? > > [1] https://my-notes.dragas.net/2026/01/06/the-virtue-of-finished-things/ > > -- > Eugene Andrienko > > i386 is already broken. To quote seuros@: > On 2026-10-06 09:16, Abdelkader Boudih wrote: > > I probably have lot antique hardware here, and even I have exactly one > 32-bit FreeBSD machine still running: an Xbox console. Not even a PC, and I > had to necromancer the code from Git history. > The 32-bit code is already broken in many places and has accumulated bugs. > I opened a few diffs while just trying to compile the 32-bit version. There > are more, but nobody is going to review them. > DragonFlyBSD removed 32-bit kernel support years ago, and they still have > an OS that boots on modern hardware. > > And I believe me and you are already dealing with broken i386 code, > although you might not have noticed. The sigtramp.S test case failure > affects i386 as well and it needs update on llvm/libunwind side. I'm not > doing that work because llvm already suffers from lack of reviewers and > there is no reviewers left especially for i386. Removing i386 is not our > own problem, but it is connected to third-party dependencies (especially > llvm) that we rely on. armv7 still seems to be supported thanks to > developers hired by Arm, but once Arm gives up maintaining armv7-A, we > might need to drop it. > > One might ask keeping our own i386 patch in the base system but based on > how frequently llvm change their private APIs, I don't know if the churn is > worth it. It might further delay MFVing next llvm release which I don't > want to see. > > -- > > Minsoo Choo > --00000000000048d905065d2cbd58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
maybe we can add an i386 tag to reviews to make it ea= sier to find that stuff and get it reviewed.

(do y= ou tag them as 'x86' at the moment?)


<= /div>

-adrian


On Tue, 6 Oct 2026 at 07:11, Minsoo Choo <mchoo@freebsd.org> wrote:
=20 =20 =20

On 2026-10-06 07:51, Eugene Andrienko wrote:

So, I'm also joining to the same question: Why remove i386 s=
upport if it
works and there are no new hardware in the near future? As I understand
this is something like "complete software" [1], which will not ro=
t while
lying in the source tree?

[1] https://my-notes.dragas.net/2026/01/06/the-vir=
tue-of-finished-things/

--
Eugene Andrienko

i386 is already broken. To quote seuros@:

On 2026-10-06 09:16, Abdelkader Boudih wrote:
I probably have lot antique hardware here, and even I have exactly one 32-bit FreeBSD machine still running: an Xbox console. Not even a PC, and I had to necromancer the code from Git history.
The 32-bit code is already broken in many places and has accumulated bugs. I opened a few diffs while just trying to compile the 32-bit version. There are more, but nobody is going to review them.
DragonFlyBSD removed 32-bit kernel support years ago, and they still have an OS that boots on modern hardware.

And I believe me and you are already dealing with broken i386 code, although you might not have noticed. The sigtramp.S test case failure affects i386 as well and it needs update on llvm/libunwind side. I'm not doing that work because llvm already suffers from lack of reviewers and there is no reviewers left especially for i386. Removing i386 is not our own problem, but it is connected to third-party dependencies (especially llvm) that we rely on. armv7 still seems to be supported thanks to developers hired by Arm, but once Arm gives up maintaining armv7-A, we might need to drop it.

One might ask keeping our own i386 patch in the base system but based on how frequently llvm change their private APIs, I don't know if the churn is worth it. It might further delay MFVing next llvm release which I don't want to see.

--

Minsoo Choo

--00000000000048d905065d2cbd58-- From nobody Tue Oct 6 14:35:35 2026 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 4hzf1h25rbz6vQjW for ; Tue, 06 Oct 2026 14:35:36 +0000 (UTC) (envelope-from jhb@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzf1h1M0sz4TQs; Tue, 06 Oct 2026 14:35:36 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791297336; 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=hhPQ9pUxjmKYXZS2sKZ2REe+5C7/1Oubu29fV6py50s=; b=kU52Ceko0VMIZKPyyjxAv7SrVv1J9MvDCGoaoqLnPN/I70NihHu981/05WaPWmzu9Fr1sd bBvkAXL0H/OOskobBTTvtYUN2fsHsIdyQq3Dy+bfgR7Sci++8skhWRwfLrnE1+y5AeXOrY ENaYpsG8mtEqTmzREp7WB1Q1IjjFqbQxgyvt4KmTAegb473uF/CjVIJdkkmPk3nNEI5/oD iWWkMM7gpB0tsczGPTd4HhjeYRofVeogs0PZko9Y5RDmlMk+va4Me8lGxK8gBXnagQSf7I /dQZ1XvBrEttSNBuXPMBPIdlsbBAfEa/uatmW47YeJtf4jetUSKAqqkb2jYX0Q== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791297336; b=Vhx5CEUhePJZFYR2mcMo3CfVMXZWFKYg2j6O0S3pzNiFJKPMsNPKpHFNHauduZ7ty1dGe8 PmxnYZCBDiwHYJF3Tl6qjZuPv4IxGFjywugKnlpfieOeJGZ6MHPkCHiMIgR5GBy5QAxpkW EkEv/FJAJlkoj9OP+yb/tz1xk1w/vBIZh/GxxaDJujNbZBExzHbZWemcuaJwS03/xbhmnc /vUgY9eNgTiqPordYq1SaDi3RJ3z5bNCDR5/OHzgPXeBtdUXF1uQpusJv5nBsHtBnzz6IG wCyTFXy40OsXtmPbr/hkqiIhzrowjFWJJBrQFWKGe73KjSlPXjO1Jlg+DPPEqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791297336; 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=hhPQ9pUxjmKYXZS2sKZ2REe+5C7/1Oubu29fV6py50s=; b=kP/AsqfxfBkfcX//2LzQ8wpcb4XbEcXZTyBUlWNrSnUb/h30df2hXK96XYAvNz7/QKzvZ2 GxPm+blX5xY1HmjtmAdFUvz0WMzmSs+uY4BXR+ihR8ZH8S7b3Ehg/PlU4Hs6r1BhVKbUfv YHR3OmUCqaoaqpfMPxwDJvOItbsAm3HHlfUOPTiFurwxrVzYXqk/4tlPs89fSW7aq76OPl NYlKbfGG/63iD0PRxE9Fc0jYYMhnTFAGdyHlNwT4aATzAoHQnn5EVI0ttMrYhXazFkSHEU HhRZXh/mnrexCdiU4fESEAHw22UBTjuXYWuwO5m0Y0dSJ7iIRD42xp7HDn+4pA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2601:5cc:4480:1036:3129:49c9:2e6c:45d7] (unknown [IPv6:2601:5cc:4480:1036:3129:49c9:2e6c:45d7]) (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 4hzf1g6djdz17c1; Tue, 06 Oct 2026 14:35:35 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <3e5214a2-ee62-4948-916e-ec1a07b798c1@FreeBSD.org> Date: Tue, 6 Oct 2026 10:35:35 -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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: i386 kernel removal Content-Language: en-US To: Konstantin Belousov Cc: freebsd-arch@freebsd.org References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/6/26 02:19, Konstantin Belousov wrote: > On Mon, Oct 05, 2026 at 11:06:08PM -0400, John Baldwin wrote: >> After some threads on the committers mailing lists a couple of months ago, >> srcmgr@ agreed to modify our original schedule for deprecating some >> platforms back in 15.0 and to go ahead and remove i386 kernel support from >> main. >> >> Towards that end, I have been working on a branch for the past month or so >> trying to find all the bits and bobs associated with i386 kernels into a >> somewhat-organized list of commits. The recent fixes to acpi_timer(4) >> and the removal of older APM BIOS bits were part of this branch, and there >> are some more cleanups/fixes before the actual commit to remove most of >> sys/i386. At this point, what would be useful is for other folks who are >> familiar with i386-specific to look at the set of commits I have so far >> and maybe point out other things I have missed that should also be >> removed. >> >> I also have some open questions and things I'm specifically not doing: >> >> - The last few commits in this branch around stand/ I'm less certain of >> as it may still be useful (for example) to continue support booting >> FreeBSD/i386 guests in bhyve via bhyveload. So, in general I'm not >> sure how far down the path we want to go in removing stand/ support. >> Perhaps /boot/loader makes sense as if you want to boot an older >> version that has a kernel you probably want to use /boot/loader from >> that version. bhyveload is the tricky bit here I think. >> >> - I have made no attempt to "move" anything out of sys/x86. For >> most things that are there I don't think the churn is worth it to >> move them into sys/amd64. There are a few headers which are now >> only used on amd64 for which it may make sense to move to >> sys/amd64/include in the future. > sys/x86 is still needed to compile 32bit world, because enough of the > headers in i386 machine/ forward to x86. So it is not about churn. Not all of sys/x86 is about world though. Some of the headers in there are kernel-only. Three headers in particular that I think you could just move from sys/x86/include/foo.h to sys/amd64/include after these commits would be bus.h, dump.h, and frame.h. They aren't providing prototypes for code that lives in sys/x86, and they aren't used in userland. >> - Once the kernel is gone, i386 worlds can now only run under an amd64 >> kernel. This means we could adjust the ABI of i386 perhaps to >> assume the amd64 baseline (SSE2, etc.). We already assume 64-bit >> atomics via cmpxchg8b. This would be equivalent to using the lib32 >> library builds (e.g. specialness around FSBASE/GSBASE in lib32 is >> something we might want to enable for plain i386). I have not done > What specifically do you mean there about segbases? Hmm, I guess this is no longer true. In the early days of lib32, the code to munge TP was different for lib32, see commit 5bc7bd5ff24ce33440863f7c353f95f65890bbce. Though I guess that was cleaned up by adding new sysarch's on i386 to set the bases to deal with this in the kernel instead of out in userland a few months later (commits 4453c6dc677c67dba7385cbabd165577ceba8d1a, 8fa4081fe34e28f2216cd4d12511d6c69f068529, and 3b4399f6a7c6213ad6abffb909614c2fd67be41e). I guess the only difference now are the CFLAGS enabling SSE2 and the like. -- John Baldwin From nobody Tue Oct 6 14:45:08 2026 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 4hzfDz1k77z6vRlg for ; Tue, 06 Oct 2026 14:45:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzfDx75c0z4WBh for ; Tue, 06 Oct 2026 14:45:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20251104.gappssmtp.com header.s=20251104 header.b=RIff1Ocz; arc=pass ("google.com:s=arc-20260327:i=1"); spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::1034) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-3856d6fbcb3so1597146a91.2 for ; Tue, 06 Oct 2026 07:45:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1791297920; cv=none; d=google.com; s=arc-20260327; b=pJRBMgrufOHmdujmKLpBogCL/yY1fTkyT2zoLLK7znLRyoNdPmhKLCGJpcN7falGNX gPxbdMMn+z1AmRVKWpjlAswzDbXrmb8O4HmnDB2akVCNBCCMieEeC3EjRgPf2wqINYnR PvTUvCc1zruDEFjFzdlFVDV2LxnVZGGyRVkZi/tQkBYk5JCJ2UczBiq66patAF5+tkUD qbOYkUQoRbID78gI6SCRDOYtOoFk63JMo/0vLtFn7SVV86B1kb9LOI0uX3L1Tj+MghrR LPYdxyvRNG/AtSyUs33TafBMzFS5qxSZX1xVuKQhRdVbD0x/7npRVMMNlhBqzntt5UZ2 +fqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=ycSQLm7QsQ0GZR6xSy7bvciW2ibqS18gf//bYNkNzZM=; fh=RGNtlpVAmThvElEyWB7xUQNmlxr67eL769wK06jQXF0=; b=qrf22RKoZcZGlpk9B0NXz6bBTxm7vUF8BO7fpt5CRV02G4J+4u/53/0MRU1WiHrbmA h5snCP0ppG7Nq55QsDNqcbampYu2Y1F2MbmOFI8hEIl8Si7qfHz93qGknoSGutG598Zu EfV7s7zAPelKW2KuCexIdWDo6KIX6+5cT60gjg2jkbgF+tZYJIcL953gF5q4hG0ogjt5 Ceca3QNAOV03jFz9Tc+8hcACYXbdhNm5jebq75y3QBdzC5jzsZZe8oeii6BELoUlFGJR crX5JLzqm6tBFpv1D8aHUGe/DPegSJIQ5XHdQFGDioAVjsCpnf8r9hMEqt+N7UFTuhu0 rfqA==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20251104.gappssmtp.com; s=20251104; t=1791297920; x=1791902720; darn=freebsd.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ycSQLm7QsQ0GZR6xSy7bvciW2ibqS18gf//bYNkNzZM=; b=RIff1Ocz0MmwSn+XQlOVJV0rrtPG3yGAv0YO0NM9DHcx9prAAzLL2FgeRg5zykcZI3 ekw3srH/DJO8fl7mpNWDjZLDG62Ypb/MBf8xCCQWd+fpLQfTLuxBsYeLEGD3++lnTDPP WhaGLPquhPG+1gvdhlHylnJO6pFmNlmgb8zb7scMYSaWJ9dghbWxrRM0uZ8sPx72Ltpe B0Nk9kuMpbvCBSXf88J9YMSQpuFh21Kk7SheKousdKRCyb1q+U2M1BYtSQ5cAFXaa923 sR5VRms1EZu63obwkA7Rcl26dHgLhiap2eQ92sBAQIJkgLjyky0tOpVgTXw5KrWJmrPT WdTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791297920; x=1791902720; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=ycSQLm7QsQ0GZR6xSy7bvciW2ibqS18gf//bYNkNzZM=; b=ZefjbNxh/DHEvMjTp9vuCKyWzhYji6bQRGWKALhppq69a3uJLYP2K6PE3DZ8LdwyF9 HzpouTa3YJ9jAOHboVnTV+2vLGsSEKsZY7DfVTdxqN3Ps6q3syNYa0nTdXS+xKPkqPRl hJ7TVhq3PBCTIfh8ocuZdbIhvFolp4CaesK/So4+p2r7xAMGv1N/ycLmLKtjswEeUhRe TTR4L03kWkkPyGZs42LRxOj6NA78qAUWNhdyr+26xm05+o9ku4Ws2BN1SVZDUpkWFdzL e7a3xrsfbe7V5Q9kgnK0DO6Dc4TBPochKDKFK3SNxX+U3c7mfnhLT40iW9bCrjT6FQy1 Hthg== X-Gm-Message-State: AFq9FYLMtA0ETTBo0tTDuXfgrD+hi/ltylmPRFOsFqPcRcH7xux+Ad+H Rs0dMCzanivVZRgbJXFhV5TW6TrTcigy7DR6mOO3RMHTW4q0CFnh3ifTmIe37BT5J0yxpj6NLMo bXl6wrHYbkP9rcmmTQw2Eq9k6Wt9o9Hw0kBxV2uU9K+UH3CbD1Vh8rG0= X-Gm-Gg: AYBFou2HXdnGDGXugMGTMVm0Nrbe2M8irrAoY2bx+ZoVijqQZ45Wl8CfFMQx6+LBrh0 9ITD+T+JB4wYOPtWge4mmnV8It4BmTuTOp8MOMrHxsAEtiHDpAPXdYeiuTz9HBr8zRz6QG1BbBX VjDjCfFRZdwCXGMHFgfurSY0JtabnSe/yBV3qOETKPBCex6B1yk6EhupXAD9C3UGljjr054vABQ Eik8LxObthB6b4UlYfTx+yJF9Kpu1JdanbHAMF8MnueJRDT60KLX4Q4NWZ0ZJCPuWdGpcxMl52j 6U/o0rZ7AN32oFqMkBosDEzQiZQ7mrwZR5gRYP73xfy1gIIgbf1AGZWvxN/Ywi0TFSiLuBOcTK5 6ZjcdtdyReg== X-Received: by 2002:a17:90b:5870:b0:3a8:32f2:f4a5 with SMTP id 98e67ed59e1d1-3a832f2f5e2mr4083614a91.53.1791297919874; Tue, 06 Oct 2026 07:45:19 -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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Tue, 6 Oct 2026 08:45:08 -0600 X-Gm-Features: AclHuK9BsYu4MEL7dozBm4lef5ykVDQzs8WCu0224tMMl0Zies2DuoRYDutjaYA Message-ID: Subject: Re: i386 kernel removal To: John Baldwin Cc: freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003388f9065d2d0c8a" X-Spamd-Bar: - X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_ALLOW(-1.00)[google.com:s=arc-20260327:i=1]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20251104.gappssmtp.com:s=20251104]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1034:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20251104.gappssmtp.com:+] X-Rspamd-Queue-Id: 4hzfDx75c0z4WBh --0000000000003388f9065d2d0c8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 6, 2026 at 8:08=E2=80=AFAM John Baldwin wrote= : > On 10/5/26 23:23, Warner Losh wrote: > > On Mon, Oct 5, 2026 at 9:06=E2=80=AFPM John Baldwin w= rote: > > > >> After some threads on the committers mailing lists a couple of months > ago, > >> srcmgr@ agreed to modify our original schedule for deprecating some > >> platforms back in 15.0 and to go ahead and remove i386 kernel support > from > >> main. > >> > >> Towards that end, I have been working on a branch for the past month o= r > so > >> trying to find all the bits and bobs associated with i386 kernels into= a > >> somewhat-organized list of commits. The recent fixes to acpi_timer(4) > >> and the removal of older APM BIOS bits were part of this branch, and > there > >> are some more cleanups/fixes before the actual commit to remove most o= f > >> sys/i386. At this point, what would be useful is for other folks who > are > >> familiar with i386-specific to look at the set of commits I have so fa= r > >> and maybe point out other things I have missed that should also be > >> removed. > >> > >> I also have some open questions and things I'm specifically not doing: > >> > >> - The last few commits in this branch around stand/ I'm less certain o= f > >> as it may still be useful (for example) to continue support bootin= g > >> FreeBSD/i386 guests in bhyve via bhyveload. So, in general I'm no= t > >> sure how far down the path we want to go in removing stand/ suppor= t. > >> Perhaps /boot/loader makes sense as if you want to boot an older > >> version that has a kernel you probably want to use /boot/loader fr= om > >> that version. bhyveload is the tricky bit here I think. > >> > > > > I'd hold off on this. The benefit is small, and there's a couple of use > > cases > > still around. We've had a long-term stable interface here. Booting 14 a= nd > > even 15 should work for the foreseeable future. We have to use 32-bit > > mode in the loader to boot amd64.... > > > > The rest looks fine. > > > > Warner > > > > > >> - I have made no attempt to "move" anything out of sys/x86. For > >> most things that are there I don't think the churn is worth it to > >> move them into sys/amd64. There are a few headers which are now > >> only used on amd64 for which it may make sense to move to > >> sys/amd64/include in the future. > >> > >> - Once the kernel is gone, i386 worlds can now only run under an amd64 > >> kernel. This means we could adjust the ABI of i386 perhaps to > >> assume the amd64 baseline (SSE2, etc.). We already assume 64-bit > >> atomics via cmpxchg8b. This would be equivalent to using the lib3= 2 > >> library builds (e.g. specialness around FSBASE/GSBASE in lib32 is > >> something we might want to enable for plain i386). I have not don= e > >> any of this and do not intend to make any such changes in this > branch. > >> > >> - I have not stubbed out i386-specific things in userspace that won't > >> work without an i386 kernel (e.g. i386_vm86(2)). The amd64 kernel > >> will already fail these things, but there might be i386-only > >> programs or daemons similar to apmd(8) (recently removed) that my > >> branch doesn't yet remove that should be on the chopping block. I= f > >> you know of something I'm missing, please let me know. > >> > >> - When device drivers were not specifically tied to i386 just only > >> made sense / were enabled on i386, I have split removing those > >> out to separate commits to make it easier to fetch them out of > >> history in the future if they are ever needed for some other > >> architecture. > >> > >> - I'm currently stuck keeping sys/i386/linux as libsysdecode uses > >> it for SYSDECODE_ABO_LINUX on i386. Probably I should just > >> change the i386 build to use the amd64 linux32 tables instead. > >> > >> You can see the current branch here (note that I frequently rebase > >> it): > >> > >> > >> > https://github.com/freebsd/freebsd-src/compare/main...bsdjhb:freebsd:rm_i= 386_kernel > >> > >> -- > >> John Baldwin > >> > >> > >> > >> > >> > >> On Mon, Oct 5, 2026 at 9:06=E2=80=AFPM John Baldwin jhb@freebsd.org>> wrote: > >> > >> After some threads on the committers mailing lists a couple of > months ago, > >> srcmgr@ agreed to modify our original schedule for deprecating som= e > >> platforms back in 15.0 and to go ahead and remove i386 kernel > support from > >> main. > >> > >> Towards that end, I have been working on a branch for the past > month or so > >> trying to find all the bits and bobs associated with i386 kernels > into a > >> somewhat-organized list of commits. The recent fixes to > acpi_timer(4) > >> and the removal of older APM BIOS bits were part of this branch, > and there > >> are some more cleanups/fixes before the actual commit to remove > most of > >> sys/i386. At this point, what would be useful is for other folks > who are > >> familiar with i386-specific to look at the set of commits I have s= o > far > >> and maybe point out other things I have missed that should also be > >> removed. > >> > >> I also have some open questions and things I'm specifically not > doing: > >> > >> - The last few commits in this branch around stand/ I'm less > certain of > >> as it may still be useful (for example) to continue support > booting > >> FreeBSD/i386 guests in bhyve via bhyveload. So, in general I'm > not > >> sure how far down the path we want to go in removing stand/ > support. > >> Perhaps /boot/loader makes sense as if you want to boot an olde= r > >> version that has a kernel you probably want to use /boot/loader > from > >> that version. bhyveload is the tricky bit here I think. > >> > >> > >> I'd hold off on this. The benefit is small, and there's a couple of us= e > cases > >> still around. We've had a long-term stable interface here. Booting 14 > and > >> even 15 should work for the foreseeable future. We have to use 32-bit > >> mode in the loader to boot amd64.... > > To be clear, the only change here for /boot/loader is to remove the actua= l > bits > to load an i386 kernel, not executing the loader as a 32-bit binary. > Yea, I understand that. My comment was more that it only removes a small percentage of the code in the i386 loader. So if it's only for bhyveload, then yes. Remove it. bhyveload is much more coupled to the right versions, and you'd really want to use the bhyveload from the guest, though that limits its usefulness (the limit is already there, though). For qemu-system, you're booting with the same rev anyway, so that case wouldn't change anything. For bare metal, I can't think why you'd want it. My original thought was 'it's not much code and there's going to be users' is only half right. I'm not sure who would use this, absent a full kernel. Warner --0000000000003388f9065d2d0c8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Oct 6, = 2026 at 8:08=E2=80=AFAM John Baldwin <jhb@freebsd.org> wrote:
On 10/5/26 23:23, Warner Losh wrote:
> On Mon, Oct 5, 2026 at 9:06=E2=80=AFPM John Baldwin <jhb@freebsd.org> wrote:
>
>> After some threads on the committers mailing lists a couple of mon= ths ago,
>> srcmgr@ agreed to modify our original schedule for deprecating som= e
>> platforms back in 15.0 and to go ahead and remove i386 kernel supp= ort from
>> main.
>>
>> Towards that end, I have been working on a branch for the past mon= th or so
>> trying to find all the bits and bobs associated with i386 kernels = into a
>> somewhat-organized list of commits.=C2=A0 The recent fixes to acpi= _timer(4)
>> and the removal of older APM BIOS bits were part of this branch, a= nd there
>> are some more cleanups/fixes before the actual commit to remove mo= st of
>> sys/i386.=C2=A0 At this point, what would be useful is for other f= olks who are
>> familiar with i386-specific to look at the set of commits I have s= o far
>> and maybe point out other things I have missed that should also be=
>> removed.
>>
>> I also have some open questions and things I'm specifically no= t doing:
>>
>> - The last few commits in this branch around stand/ I'm less c= ertain of
>>=C2=A0 =C2=A0 =C2=A0as it may still be useful (for example) to cont= inue support booting
>>=C2=A0 =C2=A0 =C2=A0FreeBSD/i386 guests in bhyve via bhyveload.=C2= =A0 So, in general I'm not
>>=C2=A0 =C2=A0 =C2=A0sure how far down the path we want to go in rem= oving stand/ support.
>>=C2=A0 =C2=A0 =C2=A0Perhaps /boot/loader makes sense as if you want= to boot an older
>>=C2=A0 =C2=A0 =C2=A0version that has a kernel you probably want to = use /boot/loader from
>>=C2=A0 =C2=A0 =C2=A0that version.=C2=A0 bhyveload is the tricky bit= here I think.
>>
>
> I'd hold off on this. The benefit is small, and there's a coup= le of use
> cases
> still around. We've had a long-term stable interface here. Booting= 14 and
> even 15 should work for the foreseeable future. We have to use 32-bit<= br> > mode in the loader to boot amd64....
>
> The rest looks fine.
>
> Warner
>
>
>> - I have made no attempt to "move" anything out of sys/x= 86.=C2=A0 For
>>=C2=A0 =C2=A0 =C2=A0most things that are there I don't think th= e churn is worth it to
>>=C2=A0 =C2=A0 =C2=A0move them into sys/amd64.=C2=A0 There are a few= headers which are now
>>=C2=A0 =C2=A0 =C2=A0only used on amd64 for which it may make sense = to move to
>>=C2=A0 =C2=A0 =C2=A0sys/amd64/include in the future.
>>
>> - Once the kernel is gone, i386 worlds can now only run under an a= md64
>>=C2=A0 =C2=A0 =C2=A0kernel.=C2=A0 This means we could adjust the AB= I of i386 perhaps to
>>=C2=A0 =C2=A0 =C2=A0assume the amd64 baseline (SSE2, etc.).=C2=A0 W= e already assume 64-bit
>>=C2=A0 =C2=A0 =C2=A0atomics via cmpxchg8b.=C2=A0 This would be equi= valent to using the lib32
>>=C2=A0 =C2=A0 =C2=A0library builds (e.g. specialness around FSBASE/= GSBASE in lib32 is
>>=C2=A0 =C2=A0 =C2=A0something we might want to enable for plain i38= 6).=C2=A0 I have not done
>>=C2=A0 =C2=A0 =C2=A0any of this and do not intend to make any such = changes in this branch.
>>
>> - I have not stubbed out i386-specific things in userspace that wo= n't
>>=C2=A0 =C2=A0 =C2=A0work without an i386 kernel (e.g. i386_vm86(2))= .=C2=A0 The amd64 kernel
>>=C2=A0 =C2=A0 =C2=A0will already fail these things, but there might= be i386-only
>>=C2=A0 =C2=A0 =C2=A0programs or daemons similar to apmd(8) (recentl= y removed) that my
>>=C2=A0 =C2=A0 =C2=A0branch doesn't yet remove that should be on= the chopping block.=C2=A0 If
>>=C2=A0 =C2=A0 =C2=A0you know of something I'm missing, please l= et me know.
>>
>> - When device drivers were not specifically tied to i386 just only=
>>=C2=A0 =C2=A0 =C2=A0made sense / were enabled on i386, I have split= removing those
>>=C2=A0 =C2=A0 =C2=A0out to separate commits to make it easier to fe= tch them out of
>>=C2=A0 =C2=A0 =C2=A0history in the future if they are ever needed f= or some other
>>=C2=A0 =C2=A0 =C2=A0architecture.
>>
>> - I'm currently stuck keeping sys/i386/linux as libsysdecode u= ses
>>=C2=A0 =C2=A0 =C2=A0it for SYSDECODE_ABO_LINUX on i386.=C2=A0 Proba= bly I should just
>>=C2=A0 =C2=A0 =C2=A0change the i386 build to use the amd64 linux32 = tables instead.
>>
>> You can see the current branch here (note that I frequently rebase=
>> it):
>>
>>
>> https://= github.com/freebsd/freebsd-src/compare/main...bsdjhb:freebsd:rm_i386_kernel=
>>
>> --
>> John Baldwin
>>
>>
>>
>>
>>
>> On Mon, Oct 5, 2026 at 9:06=E2=80=AFPM John Baldwin <jhb@freebsd.org <mailto:<= a href=3D"mailto:jhb@freebsd.org" target=3D"_blank">jhb@freebsd.org>= > wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0After some threads on the committers mailing li= sts a couple of months ago,
>>=C2=A0 =C2=A0 =C2=A0srcmgr@ agreed to modify our original schedule = for deprecating some
>>=C2=A0 =C2=A0 =C2=A0platforms back in 15.0 and to go ahead and remo= ve i386 kernel support from
>>=C2=A0 =C2=A0 =C2=A0main.
>>
>>=C2=A0 =C2=A0 =C2=A0Towards that end, I have been working on a bran= ch for the past month or so
>>=C2=A0 =C2=A0 =C2=A0trying to find all the bits and bobs associated= with i386 kernels into a
>>=C2=A0 =C2=A0 =C2=A0somewhat-organized list of commits.=C2=A0 The r= ecent fixes to acpi_timer(4)
>>=C2=A0 =C2=A0 =C2=A0and the removal of older APM BIOS bits were par= t of this branch, and there
>>=C2=A0 =C2=A0 =C2=A0are some more cleanups/fixes before the actual = commit to remove most of
>>=C2=A0 =C2=A0 =C2=A0sys/i386.=C2=A0 At this point, what would be us= eful is for other folks who are
>>=C2=A0 =C2=A0 =C2=A0familiar with i386-specific to look at the set = of commits I have so far
>>=C2=A0 =C2=A0 =C2=A0and maybe point out other things I have missed = that should also be
>>=C2=A0 =C2=A0 =C2=A0removed.
>>
>>=C2=A0 =C2=A0 =C2=A0I also have some open questions and things I= 9;m specifically not doing:
>>
>>=C2=A0 =C2=A0 =C2=A0- The last few commits in this branch around st= and/ I'm less certain of
>>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0as it may still be useful (for exa= mple) to continue support booting
>>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0FreeBSD/i386 guests in bhyve via b= hyveload.=C2=A0 So, in general I'm not
>>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0sure how far down the path we want= to go in removing stand/ support.
>>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Perhaps /boot/loader makes sense a= s if you want to boot an older
>>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0version that has a kernel you prob= ably want to use /boot/loader from
>>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0that version.=C2=A0 bhyveload is t= he tricky bit here I think.
>>
>>
>> I'd hold off on this. The benefit is small, and there's a = couple of use cases
>> still around. We've had a long-term stable interface here. Boo= ting 14 and
>> even 15 should work for the foreseeable future. We have to use 32-= bit
>> mode in the loader to boot amd64....

To be clear, the only change here for /boot/loader is to remove the actual = bits
to load an i386 kernel, not executing the loader as a 32-bit binary.

Yea, I understand that. My comment was more t= hat it only removes a small
percentage of the code in the i386 lo= ader.

So if it's only for bhyveload, then yes.= Remove it. bhyveload is much more
coupled to the right versions,= and you'd really want to use the bhyveload from
the guest, t= hough that limits its usefulness (the limit is already there, though).

For qemu-system, you're booting with the same rev = anyway, so that case
wouldn't change anything.

=
For bare metal, I can't think why you'd want it.

My original thought was 'it's not much code and t= here's going to be users'
is only half right. I'm not= sure who would use this, absent a full kernel.

Wa= rner

--0000000000003388f9065d2d0c8a-- From nobody Tue Oct 6 14:47:41 2026 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 4hzfJ26pxbz6vRwW for ; Tue, 06 Oct 2026 14:48:02 +0000 (UTC) (envelope-from seuros@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzfJ26CcJz4WSr for ; Tue, 06 Oct 2026 14:48:02 +0000 (UTC) (envelope-from seuros@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791298082; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CK/5qYe8xmX8EUxKM8HXfyEgS1Ddkyw9uzgRIGqaDN0=; b=yrPPrsOLkkdrEjgBIH7WDvjsOc6vS+NDAYasmNd0viB7oGxAhUWmlJAhY2bU+7vCq2Ilbt PFzMHLP5w7L7UmLKUkRQcOCjSzhHwiXSObcuBqls7PIM4UKz2zMbyrcyrj9swjsMQvNXWF YX0DNl4xN7LQfvx9SVT7ljkmgV6ZFZOJXgHr0/D9L3gjPx7dyhky3ywz4RXupW1bQi22/J PQU/1+5PMlH4MbwQPFgnF/B0BoUQ3qCN957llAzNSycrLKsIaxeERGA1dPy3GVId0xExbw CuicGLT8YkqO31BtE80Rv5eecTvpvo6zTWsM4CzWnnx+Tc14unK1opE12bfxtA== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791298082; b=PbYAHAU+3F6yDE+u1yu+DxWVv6HRK02zYtY9KysyHxTlU1dKMS0cAzWY03tSNz1v56vK1r 37Bz27M5/phbRHi2168z/Xawp1zvY4h6VVa2LF8QVT3N4gfhYHLbRAw0aqX+rfRIXxuzQ1 PdPW8M05hkqlR1lyrPPaV79pFG1wo4JHpsxy2VM/ZFshfOQ4nlsF6O03g3U7+XGH3EC/Yw 7XtGmuQoiOu/ynSUqd6oqGNza4Oy3QxHkI7gCpa1JeVbWrxkLXk2M9KLw0xrWX3lpmmGnt R/QrywyvILZFzUn6mB7TEAzGTePhTD58lEu/wEV+yEaleRDIZMu0oy/Z1k13sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791298082; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CK/5qYe8xmX8EUxKM8HXfyEgS1Ddkyw9uzgRIGqaDN0=; b=aGgZ0amc4E1qBAUoFFq9B1Inii3z810RTMo1ok9cGQ8WOlxY+G0kvc6vg2Q7EwVErw7zMl IClvejVcezdkfjB9CqANzO/OkUs+6F900T8qgRmungu0IkmZmtaNP78yl+6Tx5vyioFGhC DWyutaLT5VsUETK0Cj2hSqws+1jiKYjNufPH6AiCcdz1djV8mA3tsdeyCXSp4HtkADCTY7 MPRZHN0G9M8ZeKVlPN2Z4vz42LS8D5QJVplRNR8/+YV654TYJNNZJNUXjgNxFpQxeUldaQ /cpf+n3deYBfei4j8JxhOmY2Po3H66YWQG4EDp9dnMndmNVT3R3w98p8LFqHvQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from fauth-a1-smtp.messagingengine.com (fauth-a1-smtp.messagingengine.com [103.168.172.200]) (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: seuros) by smtp.freebsd.org (Postfix) with ESMTPSA id 4hzfJ24vmcz17j0 for ; Tue, 06 Oct 2026 14:48:02 +0000 (UTC) (envelope-from seuros@FreeBSD.org) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfauth.phl.internal (Postfix) with ESMTP id D2291F40066 for ; Tue, 6 Oct 2026 10:48:01 -0400 (EDT) Received: from phl-imap-04 ([10.202.2.82]) by phl-compute-06.internal (MEProxy); Tue, 06 Oct 2026 10:48:01 -0400 X-ME-Sender: X-ME-Proxy-Cause: dmFkZTGt8yHVFZ1VM70WzrCPkhz0tzycOolqdkevU4Lfj4CUBdizR+94JfYLw43EPQt6Li foeiqagsXLSW7UT+6RDLqY5nzvrIwKyF3nrxGq95hyX3H8fdEFlG29aYesgSGStASXhOzQ Bo03xxXNYLObyH3ea2t1ktE4yezqUe+SjKAmb3p57v2xbQRs6MXL4erqJpW7++My2j28bA dxRlv7p6AkgpsmoSJssUYAFWc7Dt0bhPbyMLB3EJtIYDlFSnZTHEBI8H6RO7OPZz0H+8L+ 12upaSwp0pPx2s5lecJeVsUFE4kZPKMuR+9LYUDxRuHrb9w2zYr+9M5im8stYM7Txe7ErE IZObS6iLv0IKXqql2tsMULqinDgkC6gLECXGb7Yip2lfdDJRlod78Pdvrf2rjAV54en71h 1Hq1QEZJZaJYam9ywCAYtKQT+yENe3jWCzKB4OCOlxyJd6MSfa4iVdpnFXdd9N3XCsAO7H SWzw/grOSB2WZm14ys6LRN0f/XlMxU13d/acYs2kX8SGbj/WrWB0nlzvdPpXONaNopzDaW 01NCALo1mxDe0kDydGdIuOhGyacfJ9AvJpcPsHnCri6ZBz4EdXtUcXY3QGihxURY91GtDh aXlhVer/EyVBY7ZqMnd+ANqxyXqrZ5lXiHkU9hNy/7X2ho6TRMjMg2/en17g X-ME-Proxy: Feedback-ID: i323e4aa8:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 86B5FB6006E; Tue, 6 Oct 2026 10:48:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-ThreadId: AjEgz-Vs0qfs Date: Tue, 06 Oct 2026 14:47:41 +0000 From: "Abdelkader Boudih" To: freebsd-arch@FreeBSD.org Message-Id: <21705773-826e-4492-9f29-b5727ba5b383@app.fastmail.com> In-Reply-To: References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> Subject: Re: i386 kernel removal Content-Type: multipart/alternative; boundary=bfc72d893d29648e475eb99eac041af1082bb8b2 --bfc72d893d29648e475eb99eac041af1082bb8b2 Content-Type: text/plain Content-Transfer-Encoding: 7bit > The most hardware you find on the scrapyard now already has x86_64. > It is the standard architecture for 20 years now (I know that a few > exceptions, like some early Intel Atom, exist). in the last 25 years , all hardware have 64bit. Some have 32bit UEFI, but it can boot 64bit OS. Before 25 year.. unless you are a collector, the hardware will be in very bad shape, and the PSU or capacitor are already busted or leaking. Let not speak about the bugs (cockroaches and flies), dirt and humidity that was affecting in the hardware. Abdelkader --bfc72d893d29648e475eb99eac041af1082bb8b2 Content-Type: text/html Content-Transfer-Encoding: 7bit

The most hardware you find on the scrapyard now already has x86_64.
It is the standard architecture for 20 years now (I know that a few 
exceptions, like some early Intel Atom, exist).

in the last 25 years , all hardware have 64bit.  Some have 32bit UEFI, but it can boot 64bit OS.
Before 25 year.. unless you are a collector, the hardware will be in very bad shape, and the PSU or capacitor are already busted or leaking.

Let not speak about  the bugs (cockroaches and flies), dirt and humidity that was affecting in the hardware.

Abdelkader
--bfc72d893d29648e475eb99eac041af1082bb8b2-- From nobody Tue Oct 6 14:51:23 2026 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 4hzfN25R0Yz6vRrb for ; Tue, 06 Oct 2026 14:51:30 +0000 (UTC) (envelope-from mm@dorfdsl.de) Received: from srv1.dorfdsl.de (srv1.dorfdsl.de [IPv6:2a01:170:118f:3::22]) (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 (prime256v1) client-digest SHA256) (Client CN "srv1.dorfdsl.de", Issuer "YE1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzfN16p8Vz4XKm for ; Tue, 06 Oct 2026 14:51:29 +0000 (UTC) (envelope-from mm@dorfdsl.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dorfdsl.de header.s=default header.b=Bz+w1EJC; spf=pass (mx1.freebsd.org: domain of mm@dorfdsl.de designates 2a01:170:118f:3::22 as permitted sender) smtp.mailfrom=mm@dorfdsl.de; dmarc=pass (policy=none) header.from=dorfdsl.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorfdsl.de; s=default; t=1791298283; bh=wTxWyfmM/+lha7Rm9c6eHEwcYOgDY0azcBfayUpvrl4=; h=Date:Subject:To:References:From:In-Reply-To:From; b=Bz+w1EJCmMLPjdXe44MK/LHLyzNvTg6GHdgQoBaonFHhKaKAFBOtOM4W2ZCKLoxTV xmKTVDm8DtzG1l5qpgFwxpGCR4WjxF2/uyKayN1+Tqam8GRVZUpoDaxncs7/obeHDG oaZngNDd3TWYjiEYXdKLGcAC+4hGpe8F8/s/rHHThbsO/6U2IwnVfYoh8ZGsy6c8hl GDUlijthW4XC7/v1D5edAPqrODvjUk7SOM3ffQgMDRkMOV9OB100LWi7xrfiSqpI/O HSit/irhBkgZg1Bkqc/YO+7FFSci3E/kiMYruJ5dk8J1SOk24UTm+INxJbnD4X5y8z Up5qzF02E8oSg== Received: from [IPV6:2a01:170:118f:2:4243:9422:d1b9:bd77] ([IPv6:2a01:170:118f:2:4243:9422:d1b9:bd77]) (authenticated bits=0) by srv1.dorfdsl.de (8.18.1/8.18.1/Debian-6) with ESMTPSA id 696EpN19025939 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 6 Oct 2026 16:51:23 +0200 Message-ID: <4b30e1d0-74a5-4f9f-bcb4-297381512720@dorfdsl.de> Date: Tue, 6 Oct 2026 16:51:23 +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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: i386 kernel removal To: freebsd-arch@freebsd.org References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> <21705773-826e-4492-9f29-b5727ba5b383@app.fastmail.com> Content-Language: en-US, de-DE From: Marco Moock Autocrypt: addr=mm@dorfdsl.de; keydata= xsDNBGnlI3gBDADDY5KSROZxxR7vS37LLqDMm0DyhP+6ou/D79MU+w+44OuNicr384mEMVAg PRSoig//mla8oso9fhwcu8G2IqWGzIzE8YKVq40veyJPGeOATMIbsI69oIKBjYZt7Vnw8g0Z 6iQq/9JqYRmHprtm9DPS4PME528f29jCTXOhmd7+RIHnNPiAa8Q7DDILZADRY03ksxDPYmRY 543dnDqIEuECamRfaahfJrMSJkmTt4UJEe1ZxCp1rUdgBbxrOyQyF5gVIdWr06+fyFnxpg6u YfuHl7OzPHYzHoOrNY0U9AEldW4QrNDIOqAJZVjxeWa9u2oxnIUCGMxQ/dHg5tTk+CDl2mXE aCAqOaQ5lcKFsxx7KR/BQfuRQW+Sm6meJmQQLHcWablpafAWSnqrZjz+5qflYj3CiN3vYXjE rpjLzPov3gOlfOGDXqkHTXmaenmB1HUybdpKRX0PH0r+LGJlA5U1cfy1IlvB9ZY8C2gGGRE7 LQTl228a1nvCis7+MRQm/pkAEQEAAc0bTWFyY28gTW9vY2sgPG1tQGRvcmZkc2wuZGU+wsEO BBMBCgA4FiEEGHxuJD2s+A3zICvbVZ4aMxpGtGMFAmnlI3gCGwMFCwkIBwIGFQoJCAsCBBYC AwECHgECF4AACgkQVZ4aMxpGtGOiwQv8D202XflE5ipU1uhx6VyqcZ/IQ5/eiMs+gGbm3GFK SIBpQBy2c+QDRFf7zhB/r3omVB6PHrVJGBU/T1m3BKNmCdnp1JaczjOybt+MNQGtm5RgWhpk 3he7gyp0vnT3Vy8fs2fF+pnnrt4IOnHu6hKWGXINSUxcZknRI2SFcJuYYbg+EXD/ShyDIPA0 qihw74kSY+yoa09D+W6qxrSf0+dgUUWobPwhIrPG6ypFqu5rcy/ByvifRH4vz2+C7iWF4Rtt 1U+74CqiEspF/b9B6zzg3PsdEaiuRBI4S6bJXZiMLH1cUFY4sGjSW8Qbt5/hZB9NiToW3VoY lBHohdCPRI4haEJTyZ5n7irXozO6Z/3Ikq+7jDS5I4c5v1PqFgorqiRbbh2yMKi7F2WfJcjK b2JNz7wvLAKmfqH1JO0TmmzdzCidXUOJd3zti5PyTrRrZHNWK1aAG72mhug67zTgr81zW0ph F9diJYbQVBCe27TVssm9gN3eNGrZIBQkHfI/wNaBzsDNBGnlI3gBDADjXrGqJttd4WsQ/iiZ cUA+2Qh5HMJuLSuIjBTkv/sZX5kUwWhDbXFW28TlNwEk5ogtByLOq4kmgsygZU0nk1DfpDKw yumc1n6+ReBpYNTkWUfxF3unpMuO4BE+sfEFlCJe6fjC2yTzwrC/Ls+EjkbvRzHiCfJrddQx /iKEBWCJVlWuwB4iEvO0EZh9eYPulx+p0iJRRGdRH3RBIJyQXK8sEFsfMTzOCXHwVfjkVmBc CZHviGaG5Urn7f7aHfpfxV9mN8Idxa1Eksgi/9aCuTHFQwfeyrTsNVfp1MUKG/H85/uRieXc 5MnF8i7f7luBSJCnZcqTjN0q/jLD6GJyMbnoKA71pzAlEC0EaK9MIZgSz7m4nh/JCBXPL6+t bc26lD6HDNLqMCfD2uvbpdkY/gjOo661W9fIZ+V33N+veH0ckCI8SByiJRSOotYK2rBFlfnh JzucC0yQvNxtcxlnrPvb5mt5cUMlxI1xWO4aQ+pHmZALLItna0ODS6jujxZZNkkAEQEAAcLA 9gQYAQoAIBYhBBh8biQ9rPgN8yAr21WeGjMaRrRjBQJp5SN4AhsMAAoJEFWeGjMaRrRjNUQM AKivzYaSLxYCB/IVLZpexHssAN0IBOwuEFkfMfmzSRNPLakMA0PhzJvy0HkNVT9l+7X4Uu3X +5KkPdLKPs0Z8h8h18vxKUCkknEUY3dT5EVeNAgSshxjxmCAVvQvHdW6ZBxYNJoHQrU1xpkr EHwNP6I/VqH+C6aSncXq8TU3LeBT9l58douj6JknXaiEblQj9SUWtYWVVK4/+PqOpWrbE1kB fwkMGlFHpRQzIsAkIGqnUes/RoM1EszeYNjvKAuNaw5ghUDwgQbd8MIIoi0S82kpvflJSLzQ KziNuzyunAUeJeFW9PQ2BzOf4gK9G3+pqkpLQ2OdwDL/TAqlzElWX7O2hW0X+L2+6dPOYGey HTsU2eYMeB2q6VQpJEas3ebWHRANt31wA2mvSQKbYJJYofxThfCMUcKD0CUHduEXwdahB7Vy PDCIU7kwmN2JG5n4foywEym/i942UyTQu30MtPpuhwBhpka5jG6wiFfpQAdwsb0QF0Gpzcet MCwzZXR/AA== Organization: keine vorhanden, alles chaotisch In-Reply-To: <21705773-826e-4492-9f29-b5727ba5b383@app.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------4UkgQqXyQ9bnwPoyqfGhKbw5" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.80 / 15.00]; SIGNED_PGP(-2.00)[]; DMARC_POLICY_ALLOW(-0.50)[dorfdsl.de,none]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[dorfdsl.de:s=default]; R_SPF_ALLOW(-0.20)[+ip6:2a01:170:118f:3::22:c]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:8820, ipnet:2a01:170::/32, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; FREEFALL_USER(0.00)[mm]; MID_RHS_MATCH_FROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DKIM_TRACE(0.00)[dorfdsl.de:+] X-Rspamd-Queue-Id: 4hzfN16p8Vz4XKm This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------4UkgQqXyQ9bnwPoyqfGhKbw5 Content-Type: multipart/mixed; boundary="------------lYAcG3mPTP0nwgGG0vUX0fHn"; protected-headers="v1"; hp="clear" Message-ID: <4b30e1d0-74a5-4f9f-bcb4-297381512720@dorfdsl.de> Date: Tue, 6 Oct 2026 16:51:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: i386 kernel removal To: freebsd-arch@freebsd.org References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> <21705773-826e-4492-9f29-b5727ba5b383@app.fastmail.com> Content-Language: en-US, de-DE From: Marco Moock Autocrypt: addr=mm@dorfdsl.de; keydata= xsDNBGnlI3gBDADDY5KSROZxxR7vS37LLqDMm0DyhP+6ou/D79MU+w+44OuNicr384mEMVAg PRSoig//mla8oso9fhwcu8G2IqWGzIzE8YKVq40veyJPGeOATMIbsI69oIKBjYZt7Vnw8g0Z 6iQq/9JqYRmHprtm9DPS4PME528f29jCTXOhmd7+RIHnNPiAa8Q7DDILZADRY03ksxDPYmRY 543dnDqIEuECamRfaahfJrMSJkmTt4UJEe1ZxCp1rUdgBbxrOyQyF5gVIdWr06+fyFnxpg6u YfuHl7OzPHYzHoOrNY0U9AEldW4QrNDIOqAJZVjxeWa9u2oxnIUCGMxQ/dHg5tTk+CDl2mXE aCAqOaQ5lcKFsxx7KR/BQfuRQW+Sm6meJmQQLHcWablpafAWSnqrZjz+5qflYj3CiN3vYXjE rpjLzPov3gOlfOGDXqkHTXmaenmB1HUybdpKRX0PH0r+LGJlA5U1cfy1IlvB9ZY8C2gGGRE7 LQTl228a1nvCis7+MRQm/pkAEQEAAc0bTWFyY28gTW9vY2sgPG1tQGRvcmZkc2wuZGU+wsEO BBMBCgA4FiEEGHxuJD2s+A3zICvbVZ4aMxpGtGMFAmnlI3gCGwMFCwkIBwIGFQoJCAsCBBYC AwECHgECF4AACgkQVZ4aMxpGtGOiwQv8D202XflE5ipU1uhx6VyqcZ/IQ5/eiMs+gGbm3GFK SIBpQBy2c+QDRFf7zhB/r3omVB6PHrVJGBU/T1m3BKNmCdnp1JaczjOybt+MNQGtm5RgWhpk 3he7gyp0vnT3Vy8fs2fF+pnnrt4IOnHu6hKWGXINSUxcZknRI2SFcJuYYbg+EXD/ShyDIPA0 qihw74kSY+yoa09D+W6qxrSf0+dgUUWobPwhIrPG6ypFqu5rcy/ByvifRH4vz2+C7iWF4Rtt 1U+74CqiEspF/b9B6zzg3PsdEaiuRBI4S6bJXZiMLH1cUFY4sGjSW8Qbt5/hZB9NiToW3VoY lBHohdCPRI4haEJTyZ5n7irXozO6Z/3Ikq+7jDS5I4c5v1PqFgorqiRbbh2yMKi7F2WfJcjK b2JNz7wvLAKmfqH1JO0TmmzdzCidXUOJd3zti5PyTrRrZHNWK1aAG72mhug67zTgr81zW0ph F9diJYbQVBCe27TVssm9gN3eNGrZIBQkHfI/wNaBzsDNBGnlI3gBDADjXrGqJttd4WsQ/iiZ cUA+2Qh5HMJuLSuIjBTkv/sZX5kUwWhDbXFW28TlNwEk5ogtByLOq4kmgsygZU0nk1DfpDKw yumc1n6+ReBpYNTkWUfxF3unpMuO4BE+sfEFlCJe6fjC2yTzwrC/Ls+EjkbvRzHiCfJrddQx /iKEBWCJVlWuwB4iEvO0EZh9eYPulx+p0iJRRGdRH3RBIJyQXK8sEFsfMTzOCXHwVfjkVmBc CZHviGaG5Urn7f7aHfpfxV9mN8Idxa1Eksgi/9aCuTHFQwfeyrTsNVfp1MUKG/H85/uRieXc 5MnF8i7f7luBSJCnZcqTjN0q/jLD6GJyMbnoKA71pzAlEC0EaK9MIZgSz7m4nh/JCBXPL6+t bc26lD6HDNLqMCfD2uvbpdkY/gjOo661W9fIZ+V33N+veH0ckCI8SByiJRSOotYK2rBFlfnh JzucC0yQvNxtcxlnrPvb5mt5cUMlxI1xWO4aQ+pHmZALLItna0ODS6jujxZZNkkAEQEAAcLA 9gQYAQoAIBYhBBh8biQ9rPgN8yAr21WeGjMaRrRjBQJp5SN4AhsMAAoJEFWeGjMaRrRjNUQM AKivzYaSLxYCB/IVLZpexHssAN0IBOwuEFkfMfmzSRNPLakMA0PhzJvy0HkNVT9l+7X4Uu3X +5KkPdLKPs0Z8h8h18vxKUCkknEUY3dT5EVeNAgSshxjxmCAVvQvHdW6ZBxYNJoHQrU1xpkr EHwNP6I/VqH+C6aSncXq8TU3LeBT9l58douj6JknXaiEblQj9SUWtYWVVK4/+PqOpWrbE1kB fwkMGlFHpRQzIsAkIGqnUes/RoM1EszeYNjvKAuNaw5ghUDwgQbd8MIIoi0S82kpvflJSLzQ KziNuzyunAUeJeFW9PQ2BzOf4gK9G3+pqkpLQ2OdwDL/TAqlzElWX7O2hW0X+L2+6dPOYGey HTsU2eYMeB2q6VQpJEas3ebWHRANt31wA2mvSQKbYJJYofxThfCMUcKD0CUHduEXwdahB7Vy PDCIU7kwmN2JG5n4foywEym/i942UyTQu30MtPpuhwBhpka5jG6wiFfpQAdwsb0QF0Gpzcet MCwzZXR/AA== Organization: keine vorhanden, alles chaotisch In-Reply-To: <21705773-826e-4492-9f29-b5727ba5b383@app.fastmail.com> --------------lYAcG3mPTP0nwgGG0vUX0fHn Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 QW0gMDYuMTAuMjYgdW0gMTY6NDcgc2NocmllYiBBYmRlbGthZGVyIEJvdWRpaDoNCj4gaW4g dGhlIGxhc3QgMjUgeWVhcnMgLCBhbGwgaGFyZHdhcmUgaGF2ZSA2NGJpdC4NCg0KVGhhdCdz IHRvbyBlYXJseS4NCkVhcmx5IFBlbnRpdW0gNCBkb24ndCBoYXZlIGl0LCBBdGhsb24gWFAg ZG9lcyBub3QgaGF2ZSBpdCwgUGVudGl1bSBNIA0KZG9lcyBub3QgaGF2ZSBpdC4NCg0KLS0g DQpHcnXDnw0KTWFyY28NCk11ZWxsIHVuZCBTcGFtIGJpdHRlIGFuIGFiZmFsbGVpbWVyMjAw MkBzdGlua2Vkb3Jlcy5kb3JmZHNsLmRlDQo= --------------lYAcG3mPTP0nwgGG0vUX0fHn-- --------------4UkgQqXyQ9bnwPoyqfGhKbw5 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGHxuJD2s+A3zICvbVZ4aMxpGtGMFAmrFCusFAwAAAAAACgkQVZ4aMxpGtGPj /wv+KwADwPGQfuqZOpa8qRH7nCAEzTqFtCiVXESIuxCDGx7i44r3lK0Lj7Msg85wt9sSds+x3DxO w4T+RjDkOaCD1cvnrBY9vqad+9MLyJcSt4MK+iDCB+gw5cYYLHcbuafIKaSZraaxlYvSJQXN0C+/ YF3dJ+Ym5AF4H7+t8Qsg4kyx6fqdWHbNXzRMUGFaYLwTkGLS3V86GLtnza1lK0WjqBb63wobbknG a3+zb9rUWcXz0xGTM2yAmfyN8mcvojgTmt3wlTr5BPXBrNd4Nc2M6T5fOb7yuN92ciK+z8FMNH1p LtyHV/EeNOA4Xl2POq0ekXONKfBFwiNXEHc/hkHaLwMS+Z3+jGAe6DhOVLUEKF4cC3hJjGm2ngsA +u7bTMAG7ctzLQefwl/1id/kDEaatfzSx1aF7UHlcPTnl8dttvoxM5+/DkolTngbIo975RoZ8MmY JDyssfh6gKt+27NIW1Zdo2YpZRH0CQBGZ9I1ouFrEm5UNwt0wl2DUPqL/oxE =l9xi -----END PGP SIGNATURE----- --------------4UkgQqXyQ9bnwPoyqfGhKbw5-- From nobody Tue Oct 6 15:06:47 2026 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 4hzfjh5zFMz4n2bf for ; Tue, 06 Oct 2026 15:06:48 +0000 (UTC) (envelope-from jhb@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzfjh5cWVz4ZLl; Tue, 06 Oct 2026 15:06:48 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791299208; 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=qm9nOfzZuyqm9Ed20/7INVfpQR6g3HbkiyN5qpimEHc=; b=YSRKvUuYn2kFdC2t4AwxxB4ndyc7xYZQCF2jxZ1nYhq6krLLH/+Xx0FNV6hAlsuZKxaEFE 5kG7tc9fjglRJVho9Lw3cJKi1x+M5xjt/sfrLgitfoX1j+MsMo3egago5C93e8/mE0ar0l wyTIeAWL38xb8KkFwmcNLMsOLpFknuaht2C1mgki+OUogowX8owLqCgmFj5WdxR4qBPz65 729m56T8PR9tryaajI2dwRLdCU3KVAQ5d5ACnKjR13tuf6soNMIi51/64oZG0cdWkEDD/S WYZrlImwlEBCgNmcUCZ4X0j+trapOfUmx7B4Jmqt4QbZ0awmNNvmN4UAV19B7A== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791299208; b=cfSog7q72EdewkcvmTQy6Lxje0KIjVw3iTKGJlkVnDEQpHVhhl8ArF3Y1q/DxJydp7H7Db GMKrNQwndTdJ3RrAIL+z1x/scekeLKr4TUbpKOMSUtGj026W7BdWSsPEKnTPVk/W97CyV0 KL5nRvT5KkN4w07AVskbWHoFnFCT3qcNylQW29ysc2e8evpetqx4FCwodR8jlXxeybcsO3 JaIx/eHbtiSC/rqD3uNZQOhoYyEhiSKivCdzt0G0A0vhN1BE20nZiL7xLyxpzbdDuBeOol sC5dej+8abcl5vkn8W/LDtlf93HJ4GlZvulT1a+b0ewO7CTxQdxm6GPJMAJ3bQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791299208; 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=qm9nOfzZuyqm9Ed20/7INVfpQR6g3HbkiyN5qpimEHc=; b=oBktqbf+fjQ0S974qpt2/5g/cAozQqtD7KGnwF643vPOtzFDRwA/C571HFWQFLNIw9jkZI YSNvnWqbWsUBmj42v1PDyZVYf5KvwIBLyP05TGslLOazCH7dkCj32PmJAp9TnUsnR8YL9w vg1/npPZGrZV6bp4QVW/c7Ja0Hw1cd76wSdsuH3DanfnznIhhtr5FS+GjPJg/K9PYNYUCh 9gkcdEGo9JZbuCjS6cLjJJHLDHW1d6tYpS4xtzIPwo8Bk9Lx3vB1jogwUueKHlbSsMBKd5 IdprNjv6UGAKh3LcshO/Nn/z0fCNBsWsBiL46RSoqV3wmpXjekGSPlzOSgEYKQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2601:5cc:4480:1036:3129:49c9:2e6c:45d7] (unknown [IPv6:2601:5cc:4480:1036:3129:49c9:2e6c:45d7]) (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 4hzfjh3dpFz17KW; Tue, 06 Oct 2026 15:06:48 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Tue, 6 Oct 2026 11:06:47 -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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: i386 kernel removal Content-Language: en-US To: Warner Losh Cc: freebsd-arch@freebsd.org References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/6/26 10:45, Warner Losh wrote: > On Tue, Oct 6, 2026 at 8:08 AM John Baldwin wrote: > >> On 10/5/26 23:23, Warner Losh wrote: >>> On Mon, Oct 5, 2026 at 9:06 PM John Baldwin wrote: >>> >>>> After some threads on the committers mailing lists a couple of months >> ago, >>>> srcmgr@ agreed to modify our original schedule for deprecating some >>>> platforms back in 15.0 and to go ahead and remove i386 kernel support >> from >>>> main. >>>> >>>> Towards that end, I have been working on a branch for the past month or >> so >>>> trying to find all the bits and bobs associated with i386 kernels into a >>>> somewhat-organized list of commits. The recent fixes to acpi_timer(4) >>>> and the removal of older APM BIOS bits were part of this branch, and >> there >>>> are some more cleanups/fixes before the actual commit to remove most of >>>> sys/i386. At this point, what would be useful is for other folks who >> are >>>> familiar with i386-specific to look at the set of commits I have so far >>>> and maybe point out other things I have missed that should also be >>>> removed. >>>> >>>> I also have some open questions and things I'm specifically not doing: >>>> >>>> - The last few commits in this branch around stand/ I'm less certain of >>>> as it may still be useful (for example) to continue support booting >>>> FreeBSD/i386 guests in bhyve via bhyveload. So, in general I'm not >>>> sure how far down the path we want to go in removing stand/ support. >>>> Perhaps /boot/loader makes sense as if you want to boot an older >>>> version that has a kernel you probably want to use /boot/loader from >>>> that version. bhyveload is the tricky bit here I think. >>>> >>> >>> I'd hold off on this. The benefit is small, and there's a couple of use >>> cases >>> still around. We've had a long-term stable interface here. Booting 14 and >>> even 15 should work for the foreseeable future. We have to use 32-bit >>> mode in the loader to boot amd64.... >>> >>> The rest looks fine. >>> >>> Warner >>> >>> >>>> - I have made no attempt to "move" anything out of sys/x86. For >>>> most things that are there I don't think the churn is worth it to >>>> move them into sys/amd64. There are a few headers which are now >>>> only used on amd64 for which it may make sense to move to >>>> sys/amd64/include in the future. >>>> >>>> - Once the kernel is gone, i386 worlds can now only run under an amd64 >>>> kernel. This means we could adjust the ABI of i386 perhaps to >>>> assume the amd64 baseline (SSE2, etc.). We already assume 64-bit >>>> atomics via cmpxchg8b. This would be equivalent to using the lib32 >>>> library builds (e.g. specialness around FSBASE/GSBASE in lib32 is >>>> something we might want to enable for plain i386). I have not done >>>> any of this and do not intend to make any such changes in this >> branch. >>>> >>>> - I have not stubbed out i386-specific things in userspace that won't >>>> work without an i386 kernel (e.g. i386_vm86(2)). The amd64 kernel >>>> will already fail these things, but there might be i386-only >>>> programs or daemons similar to apmd(8) (recently removed) that my >>>> branch doesn't yet remove that should be on the chopping block. If >>>> you know of something I'm missing, please let me know. >>>> >>>> - When device drivers were not specifically tied to i386 just only >>>> made sense / were enabled on i386, I have split removing those >>>> out to separate commits to make it easier to fetch them out of >>>> history in the future if they are ever needed for some other >>>> architecture. >>>> >>>> - I'm currently stuck keeping sys/i386/linux as libsysdecode uses >>>> it for SYSDECODE_ABO_LINUX on i386. Probably I should just >>>> change the i386 build to use the amd64 linux32 tables instead. >>>> >>>> You can see the current branch here (note that I frequently rebase >>>> it): >>>> >>>> >>>> >> https://github.com/freebsd/freebsd-src/compare/main...bsdjhb:freebsd:rm_i386_kernel >>>> >>>> -- >>>> John Baldwin >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Oct 5, 2026 at 9:06 PM John Baldwin > jhb@freebsd.org>> wrote: >>>> >>>> After some threads on the committers mailing lists a couple of >> months ago, >>>> srcmgr@ agreed to modify our original schedule for deprecating some >>>> platforms back in 15.0 and to go ahead and remove i386 kernel >> support from >>>> main. >>>> >>>> Towards that end, I have been working on a branch for the past >> month or so >>>> trying to find all the bits and bobs associated with i386 kernels >> into a >>>> somewhat-organized list of commits. The recent fixes to >> acpi_timer(4) >>>> and the removal of older APM BIOS bits were part of this branch, >> and there >>>> are some more cleanups/fixes before the actual commit to remove >> most of >>>> sys/i386. At this point, what would be useful is for other folks >> who are >>>> familiar with i386-specific to look at the set of commits I have so >> far >>>> and maybe point out other things I have missed that should also be >>>> removed. >>>> >>>> I also have some open questions and things I'm specifically not >> doing: >>>> >>>> - The last few commits in this branch around stand/ I'm less >> certain of >>>> as it may still be useful (for example) to continue support >> booting >>>> FreeBSD/i386 guests in bhyve via bhyveload. So, in general I'm >> not >>>> sure how far down the path we want to go in removing stand/ >> support. >>>> Perhaps /boot/loader makes sense as if you want to boot an older >>>> version that has a kernel you probably want to use /boot/loader >> from >>>> that version. bhyveload is the tricky bit here I think. >>>> >>>> >>>> I'd hold off on this. The benefit is small, and there's a couple of use >> cases >>>> still around. We've had a long-term stable interface here. Booting 14 >> and >>>> even 15 should work for the foreseeable future. We have to use 32-bit >>>> mode in the loader to boot amd64.... >> >> To be clear, the only change here for /boot/loader is to remove the actual >> bits >> to load an i386 kernel, not executing the loader as a 32-bit binary. >> > > Yea, I understand that. My comment was more that it only removes a small > percentage of the code in the i386 loader. > > So if it's only for bhyveload, then yes. Remove it. bhyveload is much more > coupled to the right versions, and you'd really want to use the bhyveload > from > the guest, though that limits its usefulness (the limit is already there, > though). > > For qemu-system, you're booting with the same rev anyway, so that case > wouldn't change anything. > > For bare metal, I can't think why you'd want it. > > My original thought was 'it's not much code and there's going to be users' > is only half right. I'm not sure who would use this, absent a full kernel. > > Warner > > > > > On Tue, Oct 6, 2026 at 8:08 AM John Baldwin > wrote: > > On 10/5/26 23:23, Warner Losh wrote: > > On Mon, Oct 5, 2026 at 9:06 PM John Baldwin > wrote: > > > >> After some threads on the committers mailing lists a couple of months ago, > >> srcmgr@ agreed to modify our original schedule for deprecating some > >> platforms back in 15.0 and to go ahead and remove i386 kernel support from > >> main. > >> > >> Towards that end, I have been working on a branch for the past month or so > >> trying to find all the bits and bobs associated with i386 kernels into a > >> somewhat-organized list of commits.  The recent fixes to acpi_timer(4) > >> and the removal of older APM BIOS bits were part of this branch, and there > >> are some more cleanups/fixes before the actual commit to remove most of > >> sys/i386.  At this point, what would be useful is for other folks who are > >> familiar with i386-specific to look at the set of commits I have so far > >> and maybe point out other things I have missed that should also be > >> removed. > >> > >> I also have some open questions and things I'm specifically not doing: > >> > >> - The last few commits in this branch around stand/ I'm less certain of > >>     as it may still be useful (for example) to continue support booting > >>     FreeBSD/i386 guests in bhyve via bhyveload.  So, in general I'm not > >>     sure how far down the path we want to go in removing stand/ support. > >>     Perhaps /boot/loader makes sense as if you want to boot an older > >>     version that has a kernel you probably want to use /boot/loader from > >>     that version.  bhyveload is the tricky bit here I think. > >> > > > > I'd hold off on this. The benefit is small, and there's a couple of use > > cases > > still around. We've had a long-term stable interface here. Booting 14 and > > even 15 should work for the foreseeable future. We have to use 32-bit > > mode in the loader to boot amd64.... > > > > The rest looks fine. > > > > Warner > > > > > >> - I have made no attempt to "move" anything out of sys/x86.  For > >>     most things that are there I don't think the churn is worth it to > >>     move them into sys/amd64.  There are a few headers which are now > >>     only used on amd64 for which it may make sense to move to > >>     sys/amd64/include in the future. > >> > >> - Once the kernel is gone, i386 worlds can now only run under an amd64 > >>     kernel.  This means we could adjust the ABI of i386 perhaps to > >>     assume the amd64 baseline (SSE2, etc.).  We already assume 64-bit > >>     atomics via cmpxchg8b.  This would be equivalent to using the lib32 > >>     library builds (e.g. specialness around FSBASE/GSBASE in lib32 is > >>     something we might want to enable for plain i386).  I have not done > >>     any of this and do not intend to make any such changes in this branch. > >> > >> - I have not stubbed out i386-specific things in userspace that won't > >>     work without an i386 kernel (e.g. i386_vm86(2)).  The amd64 kernel > >>     will already fail these things, but there might be i386-only > >>     programs or daemons similar to apmd(8) (recently removed) that my > >>     branch doesn't yet remove that should be on the chopping block.  If > >>     you know of something I'm missing, please let me know. > >> > >> - When device drivers were not specifically tied to i386 just only > >>     made sense / were enabled on i386, I have split removing those > >>     out to separate commits to make it easier to fetch them out of > >>     history in the future if they are ever needed for some other > >>     architecture. > >> > >> - I'm currently stuck keeping sys/i386/linux as libsysdecode uses > >>     it for SYSDECODE_ABO_LINUX on i386.  Probably I should just > >>     change the i386 build to use the amd64 linux32 tables instead. > >> > >> You can see the current branch here (note that I frequently rebase > >> it): > >> > >> > >> https://github.com/freebsd/freebsd-src/compare/main...bsdjhb:freebsd:rm_i386_kernel > >> > >> -- > >> John Baldwin > >> > >> > >> > >> > >> > >> On Mon, Oct 5, 2026 at 9:06 PM John Baldwin >> wrote: > >> > >>     After some threads on the committers mailing lists a couple of months ago, > >>     srcmgr@ agreed to modify our original schedule for deprecating some > >>     platforms back in 15.0 and to go ahead and remove i386 kernel support from > >>     main. > >> > >>     Towards that end, I have been working on a branch for the past month or so > >>     trying to find all the bits and bobs associated with i386 kernels into a > >>     somewhat-organized list of commits.  The recent fixes to acpi_timer(4) > >>     and the removal of older APM BIOS bits were part of this branch, and there > >>     are some more cleanups/fixes before the actual commit to remove most of > >>     sys/i386.  At this point, what would be useful is for other folks who are > >>     familiar with i386-specific to look at the set of commits I have so far > >>     and maybe point out other things I have missed that should also be > >>     removed. > >> > >>     I also have some open questions and things I'm specifically not doing: > >> > >>     - The last few commits in this branch around stand/ I'm less certain of > >>        as it may still be useful (for example) to continue support booting > >>        FreeBSD/i386 guests in bhyve via bhyveload.  So, in general I'm not > >>        sure how far down the path we want to go in removing stand/ support. > >>        Perhaps /boot/loader makes sense as if you want to boot an older > >>        version that has a kernel you probably want to use /boot/loader from > >>        that version.  bhyveload is the tricky bit here I think. > >> > >> > >> I'd hold off on this. The benefit is small, and there's a couple of use cases > >> still around. We've had a long-term stable interface here. Booting 14 and > >> even 15 should work for the foreseeable future. We have to use 32-bit > >> mode in the loader to boot amd64.... > > To be clear, the only change here for /boot/loader is to remove the actual bits > to load an i386 kernel, not executing the loader as a 32-bit binary. > > > Yea, I understand that. My comment was more that it only removes a small > percentage of the code in the i386 loader. > > So if it's only for bhyveload, then yes. Remove it. bhyveload is much more > coupled to the right versions, and you'd really want to use the bhyveload from > the guest, though that limits its usefulness (the limit is already there, though). > > For qemu-system, you're booting with the same rev anyway, so that case > wouldn't change anything. > > For bare metal, I can't think why you'd want it. > > My original thought was 'it's not much code and there's going to be users' > is only half right. I'm not sure who would use this, absent a full kernel. Humm, my reaction is the reverse. For bare metal you are more tied, whereas for bhyveload you are less tied. I still have i386 VMs on my main desktop (though I no longer use them) and for several major releases would boot both older stables (I had a VM per stable branch) and head using bhyveload for both i386 and amd64. These VMs all use UFS so they all worked fine and I never had an issue ranging from fbsd9 up through fbsd15 (my desktop tends to run the newest stable and at any give time I have VMs for head plus all supported stable branches I use for testing MFCs). So that is why I have bhyveload to be the one were it might make sense to keep support a bit longer than for the bare metal case. That is, my desktop running 16 might want to boot a fbsd14-i386 VM, but I will never use a /boot/loader running bare metal to load an i386 kernel. -- John Baldwin From nobody Tue Oct 6 15:38:03 2026 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 4hzgPy2GXBz4n58w for ; Tue, 06 Oct 2026 15:38:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzgPv6yJYz4f2Q; Tue, 06 Oct 2026 15:38:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none) Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTPS id 696Fc3LE030637 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 6 Oct 2026 18:38:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 696Fc3LE030637 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 696Fc3bw030636; Tue, 6 Oct 2026 18:38:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 6 Oct 2026 18:38:03 +0300 From: Konstantin Belousov To: Minsoo Choo Cc: freebsd-arch@freebsd.org Subject: Re: i386 kernel removal Message-ID: References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on tom.home X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; HAS_XAW(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4hzgPv6yJYz4f2Q On Tue, Oct 06, 2026 at 10:11:09AM -0400, Minsoo Choo wrote: > On 2026-10-06 07:51, Eugene Andrienko wrote: > > > So, I'm also joining to the same question: Why remove i386 support if it > > works and there are no new hardware in the near future? As I understand > > this is something like "complete software" [1], which will not rot while > > lying in the source tree? > > > > [1]https://my-notes.dragas.net/2026/01/06/the-virtue-of-finished-things/ > > > > -- > > Eugene Andrienko > > i386 is already broken. To quote seuros@: > > On 2026-10-06 09:16, Abdelkader Boudih wrote: > > I probably have lot antique hardware here, and even I have exactly one > > 32-bit FreeBSD machine still running: an Xbox console. Not even a PC, > > and I had to necromancer the code from Git history. > > The 32-bit code is already broken in many places and has accumulated > > bugs. I opened a few diffs while just trying to compile the 32-bit > > version. There are more, but nobody is going to review them. > > DragonFlyBSD removed 32-bit kernel support years ago, and they still > > have an OS that boots on modern hardware. > > And I believe me and you are already dealing with broken i386 code, although > you might not have noticed. The sigtramp.S test case failure affects i386 as > well and it needs update on llvm/libunwind side. I'm not doing that work 32bit userspace is not going away. > because llvm already suffers from lack of reviewers and there is no > reviewers left especially for i386. Removing i386 is not our own problem, > but it is connected to third-party dependencies (especially llvm) that we > rely on. armv7 still seems to be supported thanks to developers hired by > Arm, but once Arm gives up maintaining armv7-A, we might need to drop it. > > One might ask keeping our own i386 patch in the base system but based on how > frequently llvm change their private APIs, I don't know if the churn is > worth it. It might further delay MFVing next llvm release which I don't want > to see. > > -- > > Minsoo Choo From nobody Tue Oct 6 15:47:06 2026 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 4hzgcC15Hbz4n5sf for ; Tue, 06 Oct 2026 15:47:07 +0000 (UTC) (envelope-from mchoo@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzgcC0PT6z4g3B; Tue, 06 Oct 2026 15:47:07 +0000 (UTC) (envelope-from mchoo@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791301627; 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=NCCE85Wst4ocn7T+Aeqm0uYSSnKo6fnW5DbChnAt1kw=; b=iy5mVzKLNbKj65x01+z25opfOh1nFyC2LqB+E5pEJuoQ6VqmJbvarTWn5csVdUpo22blvd 9AEV18gtdSqtZXeY5hwHmmjO2mZxqRODbY29W6A/eIetqPfLZ0+JamSBwJGDrZHA4RYjgZ muplJ0KURi02DbfXoryeZwJtFhkCMTAjRWtlmOQiqHW7AaYjWFU0KOP52iP474jDYUNrG/ ZVSjTBzlQCBj5Ha2ASqhNDRWnf48AOMf6pbxMVXwRmjiOG6qaAfqaE1T15rufjrZ9K8PG9 xWUdd//kRF9eKgqvQuCm64gQmFI5fM+L9ivJY8OeqxL/onc82Nprxrhzhtf7sQ== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791301627; b=cD8ySHqEe0e2G8qA8BtO09lI0fb9s5Mb31uSoOzZP9J01QTTgbIQl11AhggAbk0FriryGM +/YXoaefBDsVNHYoAR2DnWhGvV0b0azvnKxFRymOYlsuZ4VLpOC84e0CcQK2kkZZ/ZwCEG sCGRlVGCno7kxrN3j6UaX2LjbugUrKCPt7VQ/yl+vkEGPhJHAUwoNLdM6KvKQnn0hOaWiB L9KQQz+ECdNBco3SmhwK9d/aLIMsP7ECmW/EFSmu+dHsZ4kR7l+RJAEWjgVDk9svb+ABjI MU8t7/INyCdAunXNoHmxFyyXeuKSfjXXUVdTwcia4Yz+e4jEjxLqkeqqTOoBAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791301627; 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=NCCE85Wst4ocn7T+Aeqm0uYSSnKo6fnW5DbChnAt1kw=; b=WCkM+lqoBjesP6rv9H7Q0EzXkiLXLgp7nIn+n+Mfr7Y231c04sPxBCVZgjv5PGu/TtCC/g /vbKJkOWw7YZ2s7kuMit/ML28EjlLMIL6GNoNgooKdZoGsYPa2UABT7+lz29Eb3r6IXruF HP7qXX6dJ3BbV5Xxq7Y0EwamTLTG+pgg8MlXQfAZGvp6sde7XsVtX0Rj+TZIepKAeUve4K FoADzQ39xPcJTzFIOsr76CIFpCAPz1QMDV0r5JwU4dJL7kJABs3AdBpxlCoX7SAkBtb2+z vobYBIEP96oyS+lPEbj+1vLFQNrGaZmpys3F+0A0DPAMLtntytoCBK3Fls0aEw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [10.31.133.153] (unknown [72.142.18.42]) (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: mchoo/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4hzgcB5cG9z18Y4; Tue, 06 Oct 2026 15:47:06 +0000 (UTC) (envelope-from mchoo@FreeBSD.org) Content-Type: multipart/alternative; boundary="------------gRuAFQ2gOBz2bB13rPZTEO8h" Message-ID: Date: Tue, 6 Oct 2026 11:47:06 -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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: i386 kernel removal To: Konstantin Belousov Cc: freebsd-arch@freebsd.org References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> Content-Language: en-US From: Minsoo Choo In-Reply-To: This is a multi-part message in MIME format. --------------gRuAFQ2gOBz2bB13rPZTEO8h Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026-10-06 11:38, Konstantin Belousov wrote: > On Tue, Oct 06, 2026 at 10:11:09AM -0400, Minsoo Choo wrote: >> On 2026-10-06 07:51, Eugene Andrienko wrote: >> >>> So, I'm also joining to the same question: Why remove i386 support if it >>> works and there are no new hardware in the near future? As I understand >>> this is something like "complete software" [1], which will not rot while >>> lying in the source tree? >>> >>> [1]https://my-notes.dragas.net/2026/01/06/the-virtue-of-finished-things/ >>> >>> -- >>> Eugene Andrienko >> i386 is already broken. To quote seuros@: >> >> On 2026-10-06 09:16, Abdelkader Boudih wrote: >>> I probably have lot antique hardware here, and even I have exactly one >>> 32-bit FreeBSD machine still running: an Xbox console. Not even a PC, >>> and I had to necromancer the code from Git history. >>> The 32-bit code is already broken in many places and has accumulated >>> bugs. I opened a few diffs while just trying to compile the 32-bit >>> version. There are more, but nobody is going to review them. >>> DragonFlyBSD removed 32-bit kernel support years ago, and they still >>> have an OS that boots on modern hardware. >> And I believe me and you are already dealing with broken i386 code, although >> you might not have noticed. The sigtramp.S test case failure affects i386 as >> well and it needs update on llvm/libunwind side. I'm not doing that work > 32bit userspace is not going away. Never mind, I thought 64a73d1b6dc93d92daea1e2d0603fda1dddadf4a touched i386/sigtramp.S not ia32_sigtramp.S, which is not true. -- Minsoo Choo --------------gRuAFQ2gOBz2bB13rPZTEO8h Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 2026-10-06 11:38, Konstantin Belousov wrote:
On Tue, Oct 06, 2026 at 10:11:09AM -0400, Minsoo Choo wrote:

On 2026-10-06 07:51, Eugene Andrienko wrote:


So, I'm also joining to the same question: Why remove i386 support if it
works and there are no new hardware in the near future? As I understand
this is something like "complete software" [1], which will not rot while
lying in the source tree?

[1]https://my-notes.dragas.net/2026/01/06/the-virtue-of-finished-things/

--
Eugene Andrienko

i386 is already broken. To quote seuros@:

On 2026-10-06 09:16, Abdelkader Boudih wrote:

I probably have lot antique hardware here, and even I have exactly one
32-bit FreeBSD machine still running: an Xbox console. Not even a PC,
and I had to necromancer the code from Git history.
The 32-bit code is already broken in many places and has accumulated
bugs. I opened a few diffs while just trying to compile the 32-bit
version. There are more, but nobody is going to review them.
DragonFlyBSD removed 32-bit kernel support years ago, and they still
have an OS that boots on modern hardware.

And I believe me and you are already dealing with broken i386 code, although
you might not have noticed. The sigtramp.S test case failure affects i386 as
well and it needs update on llvm/libunwind side. I'm not doing that work

32bit userspace is not going away.

Never mind, I thought 64a73d1b6dc93d92daea1e2d0603fda1dddadf4a touched i386/sigtramp.S not ia32_sigtramp.S, which is not true.

-- 
Minsoo Choo
--------------gRuAFQ2gOBz2bB13rPZTEO8h-- From nobody Tue Oct 6 17:32:56 2026 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 4hzjyZ64Ffz4nGX7 for ; Tue, 06 Oct 2026 17:33:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzjyY2XhCz3G5S; Tue, 06 Oct 2026 17:33:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none) Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTPS id 696HWuZf034914 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 6 Oct 2026 20:32:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 696HWuZf034914 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 696HWuar034913; Tue, 6 Oct 2026 20:32:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 6 Oct 2026 20:32:56 +0300 From: Konstantin Belousov To: Minsoo Choo Cc: freebsd-arch@freebsd.org Subject: Re: i386 kernel removal Message-ID: References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on tom.home X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; HAS_XAW(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4hzjyY2XhCz3G5S On Tue, Oct 06, 2026 at 11:47:06AM -0400, Minsoo Choo wrote: > > On 2026-10-06 11:38, Konstantin Belousov wrote: > > On Tue, Oct 06, 2026 at 10:11:09AM -0400, Minsoo Choo wrote: > > > On 2026-10-06 07:51, Eugene Andrienko wrote: > > > > > > > So, I'm also joining to the same question: Why remove i386 support if it > > > > works and there are no new hardware in the near future? As I understand > > > > this is something like "complete software" [1], which will not rot while > > > > lying in the source tree? > > > > > > > > [1]https://my-notes.dragas.net/2026/01/06/the-virtue-of-finished-things/ > > > > > > > > -- > > > > Eugene Andrienko > > > i386 is already broken. To quote seuros@: > > > > > > On 2026-10-06 09:16, Abdelkader Boudih wrote: > > > > I probably have lot antique hardware here, and even I have exactly one > > > > 32-bit FreeBSD machine still running: an Xbox console. Not even a PC, > > > > and I had to necromancer the code from Git history. > > > > The 32-bit code is already broken in many places and has accumulated > > > > bugs. I opened a few diffs while just trying to compile the 32-bit > > > > version. There are more, but nobody is going to review them. > > > > DragonFlyBSD removed 32-bit kernel support years ago, and they still > > > > have an OS that boots on modern hardware. > > > And I believe me and you are already dealing with broken i386 code, although > > > you might not have noticed. The sigtramp.S test case failure affects i386 as > > > well and it needs update on llvm/libunwind side. I'm not doing that work > > 32bit userspace is not going away. > > Never mind, I thought 64a73d1b6dc93d92daea1e2d0603fda1dddadf4a touched > i386/sigtramp.S not ia32_sigtramp.S, which is not true. But it is the signal trampoline used for 32bit AKA i386 processes on amd64 kernels. Also note that the support non-GPR registers in DWARF is needed for all platforms, not just FreeBSD. From nobody Tue Oct 6 22:20:27 2026 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 4hzrLF5swtz6cb2S for ; Tue, 06 Oct 2026 22:20:37 +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 4hzrLD38JQz4rZn; Tue, 06 Oct 2026 22:20:36 +0000 (UTC) (envelope-from fuz@fuz.su) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of fuz@fuz.su designates 2001:41d0:8:e508::1 as permitted sender) smtp.mailfrom=fuz@fuz.su; dmarc=none Received: from fuz.su (localhost [127.0.0.1]) by fuz.su (8.18.1/8.18.1) with ESMTPS id 696MKRfR085018 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 7 Oct 2026 00:20:27 +0200 (CEST) (envelope-from fuz@fuz.su) Received: (from fuz@localhost) by fuz.su (8.18.1/8.18.1/Submit) id 696MKRoK085017; Wed, 7 Oct 2026 00:20:27 +0200 (CEST) (envelope-from fuz) Date: Wed, 7 Oct 2026 00:20:27 +0200 From: Robert Clausecker To: John Baldwin Cc: freebsd-arch@freebsd.org Subject: Re: i386 kernel removal Message-ID: References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> X-Spamd-Bar: / X-Spamd-Result: default: False [-0.30 / 15.00]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[fuz]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[fuz.su]; RCVD_TLS_LAST(0.00)[]; MISSING_XM_UA(0.00)[] X-Rspamd-Queue-Id: 4hzrLD38JQz4rZn Hi all, Am Mon, Oct 05, 2026 at 11:06:08PM -0400 schrieb John Baldwin: > After some threads on the committers mailing lists a couple of months ago, > srcmgr@ agreed to modify our original schedule for deprecating some > platforms back in 15.0 and to go ahead and remove i386 kernel support from > main. > > Towards that end, I have been working on a branch for the past month or so > trying to find all the bits and bobs associated with i386 kernels into a > somewhat-organized list of commits. The recent fixes to acpi_timer(4) > and the removal of older APM BIOS bits were part of this branch, and there > are some more cleanups/fixes before the actual commit to remove most of > sys/i386. At this point, what would be useful is for other folks who are > familiar with i386-specific to look at the set of commits I have so far > and maybe point out other things I have missed that should also be > removed. > > I also have some open questions and things I'm specifically not doing: > > - The last few commits in this branch around stand/ I'm less certain of > as it may still be useful (for example) to continue support booting > FreeBSD/i386 guests in bhyve via bhyveload. So, in general I'm not > sure how far down the path we want to go in removing stand/ support. > Perhaps /boot/loader makes sense as if you want to boot an older > version that has a kernel you probably want to use /boot/loader from > that version. bhyveload is the tricky bit here I think. > > - I have made no attempt to "move" anything out of sys/x86. For > most things that are there I don't think the churn is worth it to > move them into sys/amd64. There are a few headers which are now > only used on amd64 for which it may make sense to move to > sys/amd64/include in the future. > > - Once the kernel is gone, i386 worlds can now only run under an amd64 > kernel. This means we could adjust the ABI of i386 perhaps to > assume the amd64 baseline (SSE2, etc.). We already assume 64-bit > atomics via cmpxchg8b. This would be equivalent to using the lib32 > library builds (e.g. specialness around FSBASE/GSBASE in lib32 is > something we might want to enable for plain i386). I have not done > any of this and do not intend to make any such changes in this branch. This is a good idea. Please move to amd64 baseline for i386 builds. Helps tremendously with performance and probably simplifies a bunch of ports. > - I have not stubbed out i386-specific things in userspace that won't > work without an i386 kernel (e.g. i386_vm86(2)). The amd64 kernel > will already fail these things, but there might be i386-only > programs or daemons similar to apmd(8) (recently removed) that my > branch doesn't yet remove that should be on the chopping block. If > you know of something I'm missing, please let me know. > > - When device drivers were not specifically tied to i386 just only > made sense / were enabled on i386, I have split removing those > out to separate commits to make it easier to fetch them out of > history in the future if they are ever needed for some other > architecture. > > - I'm currently stuck keeping sys/i386/linux as libsysdecode uses > it for SYSDECODE_ABO_LINUX on i386. Probably I should just > change the i386 build to use the amd64 linux32 tables instead. > > You can see the current branch here (note that I frequently rebase > it): > > https://github.com/freebsd/freebsd-src/compare/main...bsdjhb:freebsd:rm_i386_kernel Yours, Robert Clausecker -- () ascii ribbon campaign - for an encoding-agnostic world /\ - against html email - against proprietary attachments From nobody Tue Oct 6 23:26:26 2026 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 4hzspF29tjz6jt07 for ; Tue, 06 Oct 2026 23:26:29 +0000 (UTC) (envelope-from truckman@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hzspF1hN4z3K4Y; Tue, 06 Oct 2026 23:26:29 +0000 (UTC) (envelope-from truckman@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791329189; 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=FuUF5VpzpvErW4ycYzF2Gl11m9AchrWnYAPI2r6iP+I=; b=OskqkZApE4uzOhcm8wehRu7F58mZxGwuoiQWS16rXEf8RehA4InscRSWaBuMnoUt4IMpgc u3hoe1E2sabRKO3A4zjlVBXcQnSXQ1rYWLuVMLRNTBKPDHNlEwBlZZF9YN66nxpYipd94C /xzjQ7qOKf2JwCf70FFWQsnt+isOq3NzjfkkZ4cU418LnjSHqrCyVTTQNRnCula2XbgBVd fQMIyVpCoJVu18vsq7tyyLOU9qSR+4YGVJnEAQ5pelYi7J9c5k7v3VPMW1mvojt/EqUBiU GvDOaRXjvyFDUCjRf+u/276kjSOrIlszqu7HFXyquzOQ4hFAUWtRz4Na7BibLg== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791329189; b=Uynp4BfVwssJ8Knm5Jf+Sok76CUi7R3k7wOfsfyqrxR/TikC1r7CTNZ9EPKxjllMS0lZYu zq8gSifJVbhAwnEB/xu4+8G6M+fEh57ogsmMO4U1TZ613Pkci+fpWKMCWKhiHc+vI8aQVX SEL51cz2qhG67cful2kSNC/MzVmF8+N+wdMvBsCFwSApiMpOlMRxuTrpD3D7pSjMV5ChXS 5NC3wtvKhsWS/Ec97w5WKKTMaLeajWHqx4YbQHQ7D2uD0PA1jT7x0O7CyysUdd1H7uh26r YfFkBR38ZBPSIZgXku7fxiRwG2267HLD6UKpsjEN8/ySYKGg/gor7UfJwaiL0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791329189; 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=FuUF5VpzpvErW4ycYzF2Gl11m9AchrWnYAPI2r6iP+I=; b=Of/fvteSpvPjvDwstNvvPa69FV+xrVVHx6dK73H+MCxiRrB59FHw3PJC45rX2qFESv5TmG lWxMovjzw2iC/Vc/dnx7WUvvkkTuYOvF475AqUUV3byhSE7QsPBpqNZdCln1rZDXhikPLh Y8/Aw2xtE/Y2BZedqM5ESWgdz+Gcn8QR2PSfyxN6BCPqKX1H4V7lH6AHpMRTbE508mM6q0 xZ574d2ovArtaD8YVolBqm3LVRocMqKAYb62DshzGNHTYyvhBO2WPTbwj41c4lWuX+qy6Q lEOLroYrgCulVjidYH2GfL8BtH5mI8f4mu7HpKOZXmnpFvv+6As0FMwnb4DvTQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mousie.catspoiler.org (unknown [76.212.85.177]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: truckman) by smtp.freebsd.org (Postfix) with ESMTPSA id 4hzspD3WPnz1KXx; Tue, 06 Oct 2026 23:26:28 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Tue, 6 Oct 2026 16:26:26 -0700 (PDT) From: Don Lewis Subject: Re: i386 kernel removal To: Abdelkader Boudih cc: Vadim Goncharov , Jessica Clarke , freebsd-arch@freebsd.org In-Reply-To: Message-ID: References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <20261006132349.69e40508@nuclight.lan> 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-7 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Disposition: INLINE On 6 Oct, Abdelkader Boudih wrote: > I love this thread. We started by trying to remove 32-bit kernel, and > somehow derailed into designing a FreeBSD contingency plan for when > SkyNet is fully activated. >=20 > Just to entertain the scenario: if WW3 happens, FreeBSD is probably > one of the worst operating systems to pick for your post-apocalyptic > computer. We are already missing drivers for plenty of hardware that > exists today, and we only recently started getting serious about > modern power management in FreeBSD 16 thanks to olce@ and others. We > dont have a portable nuclear power unit like Fallout universe... 90nm is good enough to get you an AMD Athlon 64 X2. I hope you will be happy with the 500 GB HDD and 1 GB of RAM that comes with it in a bleeding edge machine. > I probably have lot antique hardware here, and even I have exactly one > 32-bit FreeBSD machine still running: an Xbox console. Not even a PC, > and I had to necromancer the code from Git history. The 32-bit code > is already broken in many places and has accumulated bugs. I opened a > few diffs while just trying to compile the 32-bit version. There are > more, but nobody is going to review them. DragonFlyBSD removed 32-bit > kernel support years ago, and they still have an OS that boots on > modern hardware. >=20 > And if the semiconductor industry somehow collapses back to 90 nm, I > suspect 'where is the FreeBSD i386 kernel ?' will rank slightly below > food, electricity, functioning fabs, packaging, RAM, storage, > networking equipment, and figuring out why the only surviving monitor > has VGA but your cable is HDMI. If humanity survives WW3, rebuilds > semiconductor factories, gets electricity and networking working > again, clones the FreeBSD repository, and discovers that i386 is > suddenly strategically important, I=A2m pretty sure we can figure it > out. >=20 > But since we are already this deep into the scenario: what if the > Pyramids were the ASML of the ancient world? Then their WW3 happened, > the documentation was lost, and 5,000 years later we are still trying > to reverse-engineer the README. My theory makes even more sense > because when I visited Egypt, I saw emojis all over the pyramids just > like a tik-tok feed. >=20 > Maybe the real lesson here is not to remove i386. Maybe the wisdom is > to put the FreeBSD Git repository inside a pyramid to protect it from > an EMP. >=20 > Also, Remember Stuxnet was 32-bit. Removing i386 is part of the > FreeBSD anti-SkyNet security strategy. >=20 > Abdelkader From nobody Wed Oct 7 01:26:39 2026 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 4hzwT31mvhz6k31L for ; Wed, 07 Oct 2026 01:26:47 +0000 (UTC) (envelope-from freebsd-arch-freebsd-org789@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4hzwT15sjFz4MyB for ; Wed, 07 Oct 2026 01:26:45 +0000 (UTC) (envelope-from freebsd-arch-freebsd-org789@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=DD15eXIb; spf=pass (mx1.freebsd.org: domain of freebsd-arch-freebsd-org789@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-arch-freebsd-org789@ketas.si.pri.ee; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee X-Clacks-Overhead: GNU Terry Pratchett DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1791336399; bh=OePy72O+ck4rgww3p7EfITuHDrhCVug5Jhz9R6QB38I=; h=Date:From:To:Subject:In-Reply-To:References; b=DD15eXIbpeKzTexH8aj1J/fXwjY6RQ83jM0triwTqxGYfYPoyiLRDkui3TZ1jJfaO tPHjCoT9VqzLpVej3o8i3W6pohdCvWuPZYynhYFaTL9mrDFGEBVjBf4SiMoenlpNxT BSCQQqZLe60aV430KUh9kpat9WNCrGE/LISFjP6W/1vL3cKfceIzfNxdcliHVXA6K4 yYTftcMowBBCO7pgpWn0uFHabMM7W5wq2OVRRwMsaiT2CsLAM7IFK0bcspfTlP2rjA KIhkO0G9uv4D5SjunhgdFzNGh/btl8UHDr9x38SzLRKdIwm+5NC18K7LVHoy4Q1QyL qhVitco1pK1sajn7haAUtDyQ0Hb55xsQLxX+zjGa10/B7Y/sG+sSZlvqQ4q+PqKymb rK/MGxzP/R0GHV98jDSq8B2JcmEL5aZQ+DGUkp6F4ADtnB9o75KJJJxsxWdRWYfcjC VswQorhP7pmIbwG1zF2UCALDH5XfRMIbFSzvO8cYBsokkuuLHsfUFRELfaRn4EM6Og LuBLEGEY6eQHgx9Coz9KGJFprsFQ8Vx9e2U0sA7XwUkVLgVoQqBAAYAWlENbZ9A5QG x3nui11f/I++6J1C6wQXm3FJouQZYeYt71Z6n13YwMBH0Qc/OV8VEqbHK8neZsshsH wr5JgkZYmikWRcljJ+2KUz2M= X-Passed-Through: http://ketas.si.pri.ee/ Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (MTA) with ESMTPSA id 41F2C5FE148 for ; Wed, 07 Oct 2026 04:26:39 +0300 (EEST) Date: Wed, 07 Oct 2026 04:26:39 +0300 From: Sulev-Madis Silber To: freebsd-arch@freebsd.org Subject: Re: i386 kernel removal User-Agent: K-9 Mail for Android In-Reply-To: References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <20261006132349.69e40508@nuclight.lan> Message-ID: <6BEF1EB9-9885-42DC-A0C2-B1D4AB45B188@ketas.si.pri.ee> 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.20 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4hzwT15sjFz4MyB i have mirrored entire fbsd three repo set for fun i also have distfiles archived going past ~15 years containing sources for= every version of most common software it all fits within ~128g=2E ok perhaps all distfiles go beyond=2E some old= ones aren't in active storage there are installers around too=2E one is even on my keychain=2E yes i now= carry fbsd around, along with firesteel, flashlight, mini multitool, with = my keys i also have generator, radio, pv, some food=2E no prepper level amounts also tools and what else=2E quite a good set=2E plus a brain tbh, some of that doomstay stuff earlier sounded more like russian propaga= nda than real life scenario that whole nuclear winter=2E back to stone age=2E etc maybe those things shouldn't interfere with fbsd src decisions otherwise, yeah sad=2E because fbsd could still run on those i386 machines= quite well in armv7 it's even sadder=2E armv7 is not yet going out but it wants=2E un= like i386 (correct me, which 2026 hw is 32bit x86?), armv7 is still sold=2E= it's not performance hw=2E it's one that works for decades i bet both of those piss off people who need it=2E where they will go, no = idea some fbsd running machines are "appliances" too oh and removed mips is currently like still used by whole one guy btw, loosely related, i was surprised that some network switches don't do = 10m anymore=2E maybe it's assumed that everything does at least 100m but ca= bling or nic might not no idea when exotic things like 10base-t1l will become common hw=2E never? anyway that's all offtopic, even from the start From nobody Wed Oct 7 06:46:30 2026 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 4j03ZH208Lz6vPHk for ; Wed, 07 Oct 2026 06:46:47 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yx1-xb136.google.com (mail-yx1-xb136.google.com [IPv6:2607:f8b0:4864:20::b136]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4j03ZG2bFkz4DrP for ; Wed, 07 Oct 2026 06:46:46 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=cSgUrw8y; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::b136) smtp.mailfrom=tomek@cedro.info; dmarc=none Received: by mail-yx1-xb136.google.com with SMTP id 956f58d0204a3-67583c777abso1899465d50.1 for ; Tue, 06 Oct 2026 23:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1791355605; x=1791960405; darn=freebsd.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=sdqAY0qbBlLXlpblioNU18Od82YwsubmPi8Di9/bkMc=; b=cSgUrw8yL1Gjq+OlTwJ2ba+JnPu4kfSSw0fn/StlQ0//8HzakBxkl4lQErNLMSMBl8 Sv7k9O2ccxghcZeZwuCBOTjLSVJskqCq0RaQIiRUhgbofIYYlVlzAXc862G39la+RzNx Rpzyd8l9sdd2QnyaPt5ohNH11YxLavflMx17YKGDizid4E2+iPwtkxf4WHWNCUwgFqAp bBdTI/SRwwirvsd6z4T/kBPBQ5U0Hj1HQBrEKgBMmQLCZduChgLZqzIsnLt81p0Io2t5 oP3VLCO/gZ8R5jx8viwc9DNR0cRZGoDwTY6y9z3Aub4d6tmYK4WfC+rnZa5hYCDu9krA 7Q1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791355605; x=1791960405; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=sdqAY0qbBlLXlpblioNU18Od82YwsubmPi8Di9/bkMc=; b=yjCypQ5S70i+1+D2URErNsSbMLgtbdMG0Ke7SNSTV/GmRmhxtfRINvo1iPoMtF6HAH wgakbgQ+mb8OKmGg51kv2bNN7tgQVCKklhCCAZF5oJie0kJ5PSuBXNvcHY7e8T8Yj0AC Xqn4WXXx7yKMss2Y1sRFFTiiz+OBCUe4RNPKvpI0JObvgqXfHCrf/VtZgrZb8j6nNMM9 VrSLS4Ky+fsA9By5C0yFrv/Dcxj5ynWWz0qHuGuinSXhl1wD6huJo53BkjhT5mbY5qEj EjIuFxHQne9yX6IBEABtGW4kXV/VsreGOaHXl/jdFvP7r9+xjhoyYBpR8FTMBGolSrJM gtyQ== X-Forwarded-Encrypted: i=1; AKwUvBxK+3sRN/+8uEZUMRcqm2tSQwh9+YToJnh859rW8ihUS3N5SaqM4feHQvCdidxGwF3C/bDK8HMQF+CncrA=@freebsd.org X-Gm-Message-State: AFq9FYKiTDG062HpionEocI9/L6AB5aVP2aiFZ5NIPW7UYD7Kul3mHUk 3GsAVxD06MyZTyA8yvBPnvANv7RTaWCZMR5aXEP4xFgCG8zuJhR+17goxls7puP2wTgSP6mJv8r enWE= X-Gm-Gg: AYBFou1u+Kq70gwNk9WR/2J12c5nZXz9EWI+V0bososRX5F+P4bTwbICkJ0wwlYQgCJ 5OCHhrtI2uVkttj5E5NeRVIkd7QVRelwOVI9J/BZbzRHFWhzeJtnUP6N48UlfaWxdgAtlamlx03 qzk18iBbM0j/4iuoKCG2nYCPUIvdmd3Tz3RTTENMSw1DsXOvGyJVHL4KgED9S8nKKMU75/hzfxh tEFMluk3uB6y2BLYgh2zE73y7QANNJaD4CvqIQsOj/lw+5uUh6YoDDX8Q7Uohhs3ctAXleoxFwm Wo6EtjB9+DSiuZuLMhvwFHOEwlApIBtAEWQdUBm6oXUY2ySVy+xn8TCToAfmOEOA0M6MePv4l1h blc2SSfiJjHvujoNJLfb+OTyuj+SmwUawUCazq5D4MGSMr3Kp89aXskZdXl9EoTqRuMhphFZFn8 oUxIDJf0zY/VC/7f7NLvDizEmC5yBInW9N+s6gx3rEZ3LqmY7I4xbn4qgKOenjVT3EjprQVu1m3 nFb07uwtjV2zctXCVmErEd2sRMigUVOkPU= X-Received: by 2002:a05:690e:1449:b0:677:deb1:2aee with SMTP id 956f58d0204a3-67909dd1b50mr1098890d50.7.1791355604842; Tue, 06 Oct 2026 23:46:44 -0700 (PDT) Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com. [209.85.128.174]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-679099bfd9asm494939d50.23.2026.10.06.23.46.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2026 23:46:43 -0700 (PDT) Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-8ac8a2ac52bso19158377b3.0 for ; Tue, 06 Oct 2026 23:46:41 -0700 (PDT) X-Forwarded-Encrypted: i=1; AKwUvBwY7xAEmPSiEdo5cvhJhHQjULGBkbGK2cOJkxLIcDPWimICUAwit53ujenJB6FkWKSfF0epeAvNoL6Vyzg=@freebsd.org X-Received: by 2002:a05:690c:e3c2:b0:8ac:e48c:4f95 with SMTP id 00721157ae682-8b05ad76aa6mr13511737b3.1.1791355600939; Tue, 06 Oct 2026 23:46:40 -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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> In-Reply-To: <864iez82sg.fsf@drag0n-laptop.lair.internal> From: Tomek CEDRO Date: Wed, 7 Oct 2026 08:46:30 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK_hyxjJ4ZyvVoAb72kTqU_-ardO0gi-T2xKbE7Usdw9NUnBHisT2j4E1Zk Message-ID: Subject: Re: i386 kernel removal To: Eugene Andrienko Cc: Jessica Clarke , Vadim Goncharov , freebsd-arch Content-Type: multipart/alternative; boundary="00000000000042b2db065d3a7a00" X-Spamd-Bar: / X-Spamd-Result: default: False [-0.30 / 15.00]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[cedro.info]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b136:from,209.85.128.174:received]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; ALIAS_RESOLVED(0.00)[]; DKIM_TRACE(0.00)[cedro.info:+] X-Rspamd-Queue-Id: 4j03ZG2bFkz4DrP --00000000000042b2db065d3a7a00 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 6, 2026, 13:52 Eugene Andrienko wrote: > Jessica Clarke writes: > > > If survivors of the apocalypse have access to the FreeBSD Git > > repository, they can always go back through the history and reinstate > > it. But given the content of your message I struggle to believe any of > > this is a serious question. > > I think, the "If" is the most questionable thing here. E.g. I'm already > stored some FreeBSD installation images just in case (Internet blackout > like in Iran, etc), but I didn't store the FreeBSD Git repository - > because the disk space is not infinite and I'm, as an end-user, didn't > need source code - I need the resulting artifact (the mentioned > installation images). And I pretty sure that a lot of people, who > performing the same task, also didn't store the mentioned Git repo. > > I agree with Vadim Goncharov here, but I want to bring not so > apocalyptic scenarios, but events that are happening right now. The new > and modern computer hardware nowadays may be inaccessible because of > inflation (too big prices - better to buy food, than HiEnd, not so well > repairable computer), it may be inaccessible because of sanctions > (waving from Russia, most of new hardware for usual people now comes > from AliExpress and other Chinese marketplaces), or it may be too > expensive because of new taxes, imposed by government (waving from the > same country). And also worth to mention RAM, SSD and HDD shortages > because of LLMs. > > So, the old hardware from closets are in use again. And not only from > closets, e.g. I could by a second-hand industrual PC (highly likely with > i386 based CPU inside) from some broken industrual machine and use it as > a PC for usual tasks, like e-mail reading, text editing, etc. E.g. my > main server is a cash register for 30$ and with Intel Atom N2800 (x86_64 > from 2011 year!) inside. > > Ofc it is with NetBSD inside, because I heard news about removing > "obsolete" CPU architectures from FreeBSD at near a year ago and I was > concerned about support of old hardware in use by FreeBSD. Definitely, I > don't want to make pkg upgrade one day and find that my server no longer > booting. > > So, I'm also joining to the same question: Why remove i386 support if it > works and there are no new hardware in the near future? As I understand > this is something like "complete software" [1], which will not rot while > lying in the source tree? > > [1] https://my-notes.dragas.net/2026/01/06/the-virtue-of-finished-things/ > > -- > Eugene Andrienko > Full agree here with Eugene on the i386 removal this is bad move and already migrates some people away from FreeBSD. Whether fast or slow apocalypse it is already happening :-( -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > --00000000000042b2db065d3a7a00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 6, 2026, 13:52 Eugene Andri= enko <evg.andrienko@gmail.com= > wrote:
Jessica Clarke = <jrtc27@freebsd.org> writes:

> If survivors of the apocalypse have access to the FreeBSD Git
> repository, they can always go back through the history and reinstate<= br> > it. But given the content of your message I struggle to believe any of=
> this is a serious question.

I think, the "If" is the most questionable thing here. E.g. I'= ;m already
stored some FreeBSD installation images just in case (Internet blackout
like in Iran, etc), but I didn't store the FreeBSD Git repository -
because the disk space is not infinite and I'm, as an end-user, didn= 9;t
need source code - I need the resulting artifact (the mentioned
installation images). And I pretty sure that a lot of people, who
performing the same task, also didn't store the mentioned Git repo.

I agree with Vadim Goncharov here, but I want to bring not so
apocalyptic scenarios, but events that are happening right now. The new
and modern computer hardware nowadays may be inaccessible because of
inflation (too big prices - better to buy food, than HiEnd, not so well
repairable computer), it may be inaccessible because of sanctions
(waving from Russia, most of new hardware for usual people now comes
from AliExpress and other Chinese marketplaces), or it may be too
expensive because of new taxes, imposed by government (waving from the
same country). And also worth to mention RAM, SSD and HDD shortages
because of LLMs.

So, the old hardware from closets are in use again. And not only from
closets, e.g. I could by a second-hand industrual PC (highly likely with i386 based CPU inside) from some broken industrual machine and use it as a PC for usual tasks, like e-mail reading, text editing, etc. E.g. my
main server is a cash register for 30$ and with Intel Atom N2800 (x86_64 from 2011 year!) inside.

Ofc it is with NetBSD inside, because I heard news about removing
"obsolete" CPU architectures from FreeBSD at near a year ago and = I was
concerned about support of old hardware in use by FreeBSD. Definitely, I don't want to make pkg upgrade one day and find that my server no longe= r
booting.

So, I'm also joining to the same question: Why remove i386 support if i= t
works and there are no new hardware in the near future? As I understand
this is something like "complete software" [1], which will not ro= t while
lying in the source tree?

[1] https://my-notes= .dragas.net/2026/01/06/the-virtue-of-finished-things/

--
Eugene Andrienko

Full agree here with Eugene on the i386 removal this is bad move = and already migrates some people away from FreeBSD. Whether fast or slow ap= ocalypse it is already happening :-(

--
CeDeROM, SQ7MHZ, <= a href=3D"http://www.tomek.cedro.info">http://www.tomek.cedro.info
--00000000000042b2db065d3a7a00-- From nobody Wed Oct 7 08:45:24 2026 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 4j06CN1DTCz6vYGK for ; Wed, 07 Oct 2026 08:45:36 +0000 (UTC) (envelope-from freebsd-arch-freebsd-org789@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4j06CM1kxDz4RWm for ; Wed, 07 Oct 2026 08:45:34 +0000 (UTC) (envelope-from freebsd-arch-freebsd-org789@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=zRDfN65A; spf=pass (mx1.freebsd.org: domain of freebsd-arch-freebsd-org789@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-arch-freebsd-org789@ketas.si.pri.ee; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee X-Clacks-Overhead: GNU Terry Pratchett DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1791362725; bh=FDernmvYZqe1tdi7ZQAxzvwzWwY1w1zcZn9efP6jnT8=; h=Date:From:To:Subject:In-Reply-To:References; b=zRDfN65ANkDTwQYl4Q5qLvLWCYXvesf8/4OTjvRk88uCTA7gASH/Zr4oYCVFGgMLL uR6YBirBaRqQ1BDpWSwaVVheHsmaiKL+VjoCzWryyvPgcP5Lv1zcGZ6EXFhOnWYqWh pV7XO6tZlZB+jXzp/UskzoWWtBzV29pu8xPUCXBsrqg5pYo18m6Ifq1jjRC0LKqXgq i3Qv9thXPCylF5GCyoF9/EgMJQhwX7hvEs8aXH6lDE4aziIrgPk4xplyyA4weoASf+ 3SgEBAq+h1KkxuYCUuM61oeEsP5icUYbG7NeokWslOFB0RrroWnnukN4gzbymrIFMp YluSA+tQ1SksXjffq1mgWF4Reg5Dwfx4bIvmU5CENROaNaYkpFDkb2n8Jcap90pTmm bXJS+FazaGsVEJ9YC7dBL3O9OyuCpdwh3K67nQv8PIMKPaYDYG8opWgbh0L5oycwyT Aik7sHb2VWaO7x2M5YaQRHqrBbftmEMuOWJDGG0efMa9SYvRLYZ/BDlthGvOztPcwx pJ9040GjtqGIwjawDCaI4pLjK2MzVxU+otJmLS2wDSGDdvXaaw/IQQ7MmHSqlfBpjm hjwBHUJXRzYXxwDKohgszUj9Ka50LiIMTcwv5h4iGGp07Cr1siQ5gY6mPvZMdo0mCy 4FeVbj22mKCnn3ID+wzlVEmg= X-Passed-Through: http://ketas.si.pri.ee/ Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (MTA) with ESMTPSA id F11DD5D98CD for ; Wed, 07 Oct 2026 11:45:24 +0300 (EEST) Date: Wed, 07 Oct 2026 11:45:24 +0300 From: Sulev-Madis Silber To: freebsd-arch@freebsd.org Subject: Re: i386 kernel removal User-Agent: K-9 Mail for Android In-Reply-To: References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> Message-ID: 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.20 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4j06CM1kxDz4RWm On October 7, 2026 9:46:30 AM GMT+03:00, Tomek CEDRO = wrote: >Full agree here with Eugene on the i386 removal this is bad move and >already migrates some people away from FreeBSD=2E Whether fast or slow >apocalypse it is already happening :-( i get the reasons tho it's not like fbsd has those people who look into ceiling and whistle and = say hmm now how do we make life hell for users altho i like to imagine that most private and public institutions have tho= se user piss off departments but no, there are certain technical reasons=2E 32bit can be burden=2E upst= ream loses 32bit due burden=2E including llvm / clang=2E some not very clea= r to me code issues here=2E and it must be supported by someone however i don't like this we discussed this in private and it's already do= ne=2E in a public os! often seen in governments too=2E also publics somebody said in on fbsd ml msg that info to make decisions (or there, the= docs) is provided in the bottom on last drawer in locked file cabinet in e= nd of the corridor in last room that has sign beware of dog or, in a place nobody knows or wants to look into first place i actually learned that fbsd wants to get rid of i386 was when= kernel boot log (who watches that too, always?) started telling how 32bit = is going away at first i was like, you're joking right? you can't be serious?! it's the = pillar of decades of modern computing!!! but sadly it was indeed true but i don't like it nevertheless btw, do you recall going from 9600 to 115200 in serial consoles? 115200 wa= s supposed to be standard=2E but if it's console, 9600 could be enough=2E u= nsure why 9600 was chosen=2E i guess it was at time good optimal speed you = can build uart transceivers for=2E but speed isn't some magical software nu= mber you can whip around just like that=2E it involves faster electrical si= gnaling and lines might not be able to do that another weirs / bad decision also what happened with csh vs=2E sh defaults? to this day, sh hasn't gotten features the csh has (like partial command h= istory search (df;ls;uname -> d -> df (not uname)), or mv aaa{b,c})=2E = or tcsh as it's since forever (i installed 4=2E6 in 2002 being 19yo)=2E exc= use was that everyone has always used bash=2E i didn't=2E i used on linux w= hat was there and on fbsd what was there=2E note the age too, you can only = have so many years there but if everybody uses bash, why sh? bash is not in the base so you need to= chain-load it anyway=2E or replace user / root shell if you are extra brav= e=2E so what was change for then? same with everybody using sudo (possibly with user pw) as root shell is da= ngerous=2E well, guess what, pocket knife is dangerous, that why after cutt= ing you put it away=2E but you absolutely need to use it "raw" way too much arch offtopics here i guess now From nobody Wed Oct 7 09:04:49 2026 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 4j06g40S3Hz6vZmJ for ; Wed, 07 Oct 2026 09:06:08 +0000 (UTC) (envelope-from seuros@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4j06g405pvz4TCr; Wed, 07 Oct 2026 09:06:08 +0000 (UTC) (envelope-from seuros@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791363968; 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=0vWHS67G1CUVcqeAsiYlE3zqyQMWfKD0jt4AalZWsyY=; b=lyyZaRNeGQTbdur/YpwHC6pwNAWt/CHmztLNtfnm0Ii7/U5lQ1II2L4tVRpLZa+zvrB7NM pDRL5EPZUYWcJS5oDP3q647MYVA+sKBUOGDpZGRLHAOIUesIzvThirvYAQthdjsDBihkka xWgyeoXHHu0TJfe+roa0I60rTkjWe9C6/DbzZyfx8Bo4lKs2Q5R8x9c3NHfc9fW+atG1A/ on997GiXwvvCBydOmArZLiqMTTRsIC38SoXxg6E0kkFT3HwzfZG3L+2vri1V9fXEeF+FcV JkkZqa6h4zIUysLhxZTZTZcptEuZlUhvwh/O9/ZgtXYaGhTghacrj/XS0L9tQA== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791363968; b=U/TvadcBMUOyVB21TMCnvfJg1VpQi2SCapF0wetlNT4h+szPbtdHDg42Ap6m9wecVJnYpJ 4Jz6JlX4YckhgGE0FsFLrwCXH6BgNaMKZKfxkxgks/PpZDgXw8fO75nc268qlFSa1zByQT qyj/9jmIZeBU379aH7RJ+NGjp/RxlVx9u710F1QvyTS367+FWjpPGIxVVcyrvwhSKqzXnt qboWZpZkTSMFvKgXkceQkcrCnw6pIkbNTHfknhazEGyfu8V2HpHhxnFPj7RnafCWLAtIX5 Njprle9kHbJm1xUbRdSmrcuZ+spRi4f0+Z45CsHNoG/j67hDThq0fxAkHMID8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791363968; 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=0vWHS67G1CUVcqeAsiYlE3zqyQMWfKD0jt4AalZWsyY=; b=a3GpnTRbq2SUTSLonc0uhk9PMZHzf+lKnEjJdHxrBaMWO96701ymGsvOIbYV7uNFjOccFH qB8XtnH5dO+ChqL+H/SLTVnS+zsHIBlT9hfI5fMV/TwMLiXN4qtSlRixGS9y9mNN4ryKpO BAkz3hdFSSnzf3fCe2bxBhSuegd/TIVsVgLdoLNuzyMQ2WfusfSI0l1y2qPocbidFiOEKB A/LzfH+HUsYTpBRDPORNekw7SfurWtIkG2NSfT0U4IKmEdWNsCG5iZL+jHDjLHQhH5djl7 vbH1IUDYZ8iJwhun1E+x9rQ85QGBfy1bTdgyrP/Q43E/LC2L7ZPCas0+y9fgRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com [103.168.172.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 did not present a certificate) (Authenticated sender: seuros) by smtp.freebsd.org (Postfix) with ESMTPSA id 4j06g35VMvzYZ6; Wed, 07 Oct 2026 09:06:07 +0000 (UTC) (envelope-from seuros@freebsd.org) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfauth.phl.internal (Postfix) with ESMTP id 9134FF40068; Wed, 7 Oct 2026 05:06:07 -0400 (EDT) Received: from phl-imap-04 ([10.202.2.82]) by phl-compute-06.internal (MEProxy); Wed, 07 Oct 2026 05:06:07 -0400 X-ME-Sender: X-ME-Proxy-Cause: dmFkZTGTpl7O5oTN33TgbZOTl7VwFoC6EslzWVat/DrdWGyPJ5NbRmS4PmFzSjQkPo0SYd XpWIWCuCIFVwQL0LTSXsoGKAxmTCMehBb9VioxZrt534annXXXxDyjo3RnRJZy81yVwmOl WFvxwO9Qa3nDsLttIlnTSOMt/vHomrTNMNsM8+x2u2J9z4OXM/GCE7/F479GyBbuFDyceg BakfmRnI8qeIwh3J62Fa6ZYTofmCgmhbGqcKbhOMZLZngddrW+3mGHwebzAr7h5ziATQfU JT7peKmlYelx3bq7zuION1xZYb5zWP8sasKEkvR5qCYteX7rY82wOlB5JP7Il3lBsUZUGS cRLgvjhsCK7WKt5obhKOxW4WkX3nP5sYfKYPgJZMZ078elE3G90dqadJvuuefRrYd8NFeT XpXrmJAxk08/uC3VVllxw5DWyZDgwsalfJlB+PwwNi4cgpDkjaumycX+UIz/4eJfjuTK2W afVu8pzLdgihYS2lY1Bqpf6Pkz83DnXPLBenAubB3M8tx697JgDao9p/F6OhIsCt6gm8su 84bItmijPEN/6ZoiodZfETNvISaZSSJTAKMZAT91rhsGryBwP3wryIoWTgSoq7Nshjwyef Xufk7dY5vrebFA4OTXs6Rfd4lu2MuYO1Z/0MmbGaPhkoozRRhUMl4tSjLQUg X-ME-Proxy: Feedback-ID: i323e4aa8:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 731F3B60070; Wed, 7 Oct 2026 05:06:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-ThreadId: AjEgz-Vs0qfs Date: Wed, 07 Oct 2026 09:04:49 +0000 From: "Abdelkader Boudih" To: "Tomek CEDRO" , "Eugene Andrienko" Cc: "Jessica Clarke" , "Vadim Goncharov" , freebsd-arch Message-Id: <7700025c-5167-4a05-93c0-3fc1864ef648@app.fastmail.com> In-Reply-To: References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> Subject: Re: i386 kernel removal Content-Type: multipart/alternative; boundary=be362215d00e7e4d06c45f7b6ef49c819926ddec --be362215d00e7e4d06c45f7b6ef49c819926ddec Content-Type: text/plain Content-Transfer-Encoding: 7bit I really want to understand who these people are, and why they are not upgrading their hardware. I want to understand their way of thinking. I feel we are doing the same dance Linux did around the removal of i486. For a long time people kept saying that support should stay, but when they were asked to show an actual booting, working machine with a current Linux release, they folded and got busy with other things. FreeBSD is an OS, not a SaaS. If we removed an architecture from CURRENT tomorrow, the machines already running it would not suddenly stop working. People would lose the ability to upgrade to future releases, and some may decide to fork(which I doubt), but the old releases, ISOs, source trees and installations would continue to work on that hardware. I maintain Flashrom, or as I describe myself: I am the janitor there. I have deleted much more code than I have added. Flashrom had programmers tested in CI that were sold worldwide to maybe 10 people. *Ten*. Some of that code existed as an alternative to the vendor recovery tool, so people could unbrick a machine after a bad flash. The code compiled, stayed in the tree for more than a decade, and kept being shipped. Other programmers I removed also compiled, but nobody had tested them in more than twenty years. The code was wrong for a modern operating system anyway, because in 2026 you cannot just write directly to the *EEPROM* from userspace without additional kernel or privilege handling. I did not bother fixing that code. I removed it. Those programmers now cost around $700 on eBay, if you can even find them. At that point they are museum or collector hardware. It makes no sense to expect someone maintaining Flashrom to buy one just so a piece of dead code can continue compiling. That is the point I am trying to raise. We are in 2026, and we need a modern maintenance model. Old does not automatically mean bad, but unsupported and unmaintained is a problem. As some of you know, the *FIREWIRE* driver was planned for removal in FreeBSD 16. I wanted it to stay, so I worked on it. I modernized it, read the specification, and with help from Adrian@ we got fwcam and other drivers working again. While fixing it, I found latent bugs that still exist in the Linux FireWire driver and can crash the machine if the cable is plugged and unplugged quickly. Those bugs are fixed in CURRENT. When I started working on FireWire, somebody on Discord wrote, "*FireWire! I didn't hear this word since 2003.*" At that time the hardware was cheap. FireWire cards were less than $10 and three-meter cables were around $2-$3. Adrian ordered some cameras about a week before a YouTuber made a video about FireWire with a Raspberry Pi and price went parabolic. A *Guppy PRO GPF-125B* camera that used to cost around $60 suddenly went to more than $1000. This camera has no AI, no RAM, nothing magical. It is worse than a smartphone camera from more than a decade ago. I even told Adrian that if the FreeBSD Foundation offered to pay the $60, I would refuse because that camera is not worth it price then (at $60). The same thing happens with other retro hardware. A 4 GB DDR2 stick that used to be $15 can now cost close to $100. DDR TWO. not a typo. So there is another problem with waiting forever. By the time somebody finally decides that old hardware needs active maintenance, the hardware may already have become collector-priced no apocalyptic scenario needed. This brings me back to i386. Who are the people supposedly migrating away from FreeBSD because i386 is disappearing ? Where did they go ? What hardware were they actually using ? Were they using i386 because the CPU cannot run amd64, or were they simply running a 32-bit installation on a 64-bit capable machine ? And if this architecture matters that much to them, why are they not stepping in now and taking ownership of it ? Keeping i386 is not free. It creates work for developers who may not use it at all. ngie@ has OpenSSL-related work, imp@ and Adrian@ have reviews and sign-offs, ziaee@ has documentation work, and other developers still have to deal with compiler behavior, ports, VM assumptions, boot loaders, release engineering and CI. This is the part that gets lost in these discussions. Saying "please keep i386" costs almost nothing. Maintaining i386 costs real developer time that none of us is really paid for. If we want numbers, I installed FreeBSD and Linux this year on more than *20000* machines (10% Linux (where we dont have drivers)). That sounds huge until I explain that I have disk duplicators and more than 60 people helping. Those are still many more incoming users than the number who may leave because i386 disappears. Most of those users received the hardware for free. They will use the machines for reading news, Facebook, school work, browsing and other basic tasks (2-4gb ram). They will probably never donate money, submit a patch or become FreeBSD developers. That fine. FreeBSD does not require users to contribute. I used FreeBSD via opnsense for years without donating anything back. There could be 10000 i386 users and nobody maintaining i386. There could also be thirty serious users with hardware, CI, knowledge and a couple of developers actively fixing regressions, and that may be enough to justify keeping it. The important number is not only the number of users. It is the number of people willing and able to maintain the platform. So my question is still the same. If we want to keep i386, who is taking the maintenance burden ? Who is still using it as a real daily driver ? What hardware are they using, and how much of it cannot run amd64 ? Who is willing to regularly test CURRENT and investigate breakage instead of waiting for unrelated developers to keep doing that work ? I still have a few hundred machines in the warehouse. I can probably swap some of my 64-bit machines for their 32-bit hardware. I am not trying to destroy old hardware support. My FireWire work should make that clear. What I am saying is that "old" cannot automatically mean "keep forever.". Adrian removed the WEP support, and it just an algorithm. We also need to remember that this is 2026. Compilers, operating systems, security tooling changed, and now automated analysis and AI systems can generate reports against code that nobody has touched in decades. I still receive critical advisories in my repositories for things that are practically impossible to trigger. The DragonFly repository was at one point bombarded with reports about code related to tape(4) that had apparently gone untouched since the 1950s. FreeBSD dont have that code anymore, but the other project has less activity than FreeBSD. So for me, the i386 discussion should be is there is still an active group of people willing to own i386 as a supported FreeBSD architecture. If they are they can step forward and get their group in pharbricator so we can tag them. PS: In flashrom, I proposed to remove Windows and DOS unless maintainers step in. We have 3 maintainers in Windows and DOS was evicted. PS2: flashrom build natively in freeBSD now, no patching needed --- Abdelkader On Wed, 7 Oct 2026, at 06:46, Tomek CEDRO wrote: > Full agree here with Eugene on the i386 removal this is bad move and already migrates some people away from FreeBSD. Whether fast or slow apocalypse it is already happening :-( > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >> --be362215d00e7e4d06c45f7b6ef49c819926ddec Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I really want to understand who th= ese people are, and why they are not upgrading their hardware. I want to= understand their way of thinking.

I feel we are doing the same dance Linux did around the = removal of i486. For a long time people kept saying that support should = stay, but when they were asked to show an actual booting, working machin= e with a current Linux release, they folded and got busy with other thin= gs.

FreeBSD is an O= S, not a SaaS. If we removed an architecture from CURRENT tomorrow, the = machines already running it would not suddenly stop working. People woul= d lose the ability to upgrade to future releases, and some may decide to= fork(which I doubt), but the old releases, ISOs, source trees and insta= llations would continue to work on that hardware.

I maintain Flashrom, or as I describe mys= elf: I am the janitor there. I have deleted much more code than I have a= dded.

Flashrom had = programmers tested in CI that were sold worldwide to maybe 10 people. Ten. Some of that code existed as an alternative to the vendor reco= very tool, so people could unbrick a machine after a bad flash. The code= compiled, stayed in the tree for more than a decade, and kept being shi= pped.

Other program= mers I removed also compiled, but nobody had tested them in more than tw= enty years. The code was wrong for a modern operating system anyway, bec= ause in 2026 you cannot just write directly to the EEPROM from us= erspace without additional kernel or privilege handling. I did not bothe= r fixing that code. I removed it.

Those programmers now cost around $700 on eBay, if you can = even find them. At that point they are museum or collector hardware. It = makes no sense to expect someone maintaining Flashrom to buy one just so= a piece of dead code can continue compiling.

That is the point I am trying to raise. We ar= e in 2026, and we need a modern maintenance model. Old does not automati= cally mean bad, but unsupported and unmaintained is a problem.

As some of you know, the FI= REWIRE driver was planned for removal in FreeBSD 16. I wanted it to = stay, so I worked on it. I modernized it, read the specification, and wi= th help from Adrian@ we got fwcam and other drivers working again.
=

While fixing it, I found= latent bugs that still exist in the Linux FireWire driver and can crash= the machine if the cable is plugged and unplugged quickly. Those bugs a= re fixed in CURRENT.

When I started working on FireWire, somebody on Discord wrote, "FireWire! I didn't hear this word since 2003."

At that time the hardware was cheap. Fi= reWire cards were less than $10 and three-meter cables were around $2-$3= . Adrian ordered some cameras about a week before a YouTuber made a vide= o about FireWire with a Raspberry Pi and price went parabolic.

A Guppy PRO GPF-125B ca= mera that used to cost around $60 suddenly went to more than $1000. This= camera has no AI, no RAM, nothing magical. It is worse than a smartphon= e camera from more than a decade ago.

I even told Adrian that if the FreeBSD Foundation off= ered to pay the $60, I would refuse because that camera is not worth it = price then (at $60).

The same thing happens with other retro hardware. A 4 GB DDR2 stick th= at used to be $15 can now cost close to $100. DDR TWO. not a typo.
=

So there is another prob= lem with waiting forever. By the time somebody finally decides that old = hardware needs active maintenance, the hardware may already have become = collector-priced no apocalyptic scenario needed.

This brings me back to i386.

Who are the people supposedly mi= grating away from FreeBSD because i386 is disappearing ? Where did they = go ? What hardware were they actually using ? Were they using i386 becau= se the CPU cannot run amd64, or were they simply running a 32-bit instal= lation on a 64-bit capable machine ?

And if this architecture matters that much to them, wh= y are they not stepping in now and taking ownership of it ?

Keeping i386 is not free. It cr= eates work for developers who may not use it at all. ngie@ has OpenSSL-r= elated work, imp@ and Adrian@ have reviews and sign-offs, ziaee@ has doc= umentation work, and other developers still have to deal with compiler b= ehavior, ports, VM assumptions, boot loaders, release engineering and CI= .

=
This is the part = that gets lost in these discussions. Saying "please keep i386" costs alm= ost nothing. Maintaining i386 costs real developer time that none of us = is really paid for.

If we want numbers, I installed FreeBSD and Linux this year on more tha= n 20000 machines (10% Linux (where we dont have drivers)). That s= ounds huge until I explain that I have disk duplicators and more than 60= people helping.
Those are still many more incoming users than the number who may le= ave because i386 disappears.

Most of those users received the hardware for free. They will = use the machines for reading news, Facebook, school work, browsing and o= ther basic tasks (2-4gb ram). They will probably never donate money, sub= mit a patch or become FreeBSD developers. That fine.

FreeBSD does not require users to cont= ribute. I used FreeBSD via opnsense for years without donating anything = back.

There could b= e 10000 i386 users and nobody maintaining i386. There could also be thir= ty serious users with hardware, CI, knowledge and a couple of developers= actively fixing regressions, and that may be enough to justify keeping = it.

The important n= umber is not only the number of users. It is the number of people willin= g and able to maintain the platform.

So my question is still the same. If we want to keep i= 386, who is taking the maintenance burden ? Who is still using it as a r= eal daily driver ? What hardware are they using, and how much of it cann= ot run amd64 ? Who is willing to regularly test CURRENT and investigate = breakage instead of waiting for unrelated developers to keep doing that = work ?

<= /div>
I still have= a few hundred machines in the warehouse. I can probably swap some of my= 64-bit machines for their 32-bit hardware.

I am not trying to destroy old hardware support= . My FireWire work should make that clear.

What I am saying is that "old" cannot automatica= lly mean "keep forever.". Adrian removed the WEP support, and it just an= algorithm.
=
We also= need to remember that this is 2026. Compilers, operating systems, secur= ity tooling changed, and now automated analysis and AI systems can gener= ate reports against code that nobody has touched in decades.

I still receive critical advis= ories in my repositories for things that are practically impossible to t= rigger. The DragonFly repository was at one point bombarded with reports= about code related to tape(4) that had apparently gone untouched since = the 1950s. FreeBSD dont have that code anymore, but the other project ha= s less activity than FreeBSD.

So for me, the i386 discussion should be is there is still an= active group of people willing to own i386 as a supported FreeBSD archi= tecture. If they are they can step forward and get their group in pharbr= icator so we can tag them.

PS: In flashrom, I proposed to remove Windows and DOS unless mai= ntainers step in. 
We have 3 maintainers in Windows and DOS was evicted.
<= div class=3D"align-start" style=3D"text-align:start;">PS2: flashrom buil= d natively in freeBSD now, no patching needed 

---
Abdelkader



On = Wed, 7 Oct 2026, at 06:46, Tomek CEDRO wrote:
Full agr= ee here with Eugene on the i386 removal this is bad move and already mig= rates some people away from FreeBSD. Whether fast or slow apocalypse it = is already happening :-(

--
=
=
--be362215d00e7e4d06c45f7b6ef49c819926ddec-- From nobody Wed Oct 7 09:57:42 2026 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 4j07pv4YFcz6vdx9 for ; Wed, 07 Oct 2026 09:57:59 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4j07pv00ZWz4ZLq for ; Wed, 07 Oct 2026 09:57:59 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=R5QheSG0; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::1132) smtp.mailfrom=tomek@cedro.info; dmarc=none Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-8ab3aaf416dso16114417b3.2 for ; Wed, 07 Oct 2026 02:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1791367078; x=1791971878; darn=freebsd.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=a5qNG0PUwiCIk0lZ96gMpH1kVzFDg3B2dN9kIbpv7XM=; b=R5QheSG0xntDIF5b4c1klAijVG8YmhoTTVb2xoMVQOz2LI0040P7R7L209haRwEk+n rQW4LFIEtDKyAeBn2SmfKiQGXiU5FSbXsEqWw35I9dSLGEtbJqgEm3U4nQT92vDJCUII 3+CRa8fumRKlCFt2wuINkxmuklbVMlfYRQWP+Ue8AV4x+nmgQRl9P4pJ8Go5ig85pHn9 R0CZkiuaMhTqfYS+dADJmWUe/OhXhciW9O7eKTlu/eQMWf+ABkSIsn46/STmRmCQPEFL 2yLEflRoQHwxyYSvAuNKaAPOaNO7P5/VXWKzc3/k/xCT5UAHj7oe1bXsrEI74syPARaj mqMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791367078; x=1791971878; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=a5qNG0PUwiCIk0lZ96gMpH1kVzFDg3B2dN9kIbpv7XM=; b=kW1piddCrwgRuXc1PnyhxOeMFVp0404bbCwc7mVj6A40joOK+eL/KmTIcZmOA1XX55 Xi5nUP4Ne/NRmwXPPC5Gu0p8ay2qQOCyLS5O9O3TW2hl+598PRh+pVClY7susCsq7hwi xNxgogHKTTJ9gKegNkHKZo3bqXfjOEjel7flioANXE7lwknhF0YlGl9ffn4Pc8Gj7hzv qAOjWC2KOGqWsandvUhqv2fYjTQm/IIKOtRE+6N2O38CmbCjt4JUlgJXLi2vk4Tkm/vW WLQOSum17Ghpf0Xl5LU3c1xbux7ilowsQarm0MdZBelCW/67yBM1AAuCFOVyAJxAKIPc APmQ== X-Forwarded-Encrypted: i=1; AKwUvBwPhUzjNdqfPolxni5siRHYvkcHQ+GveBhOv/AfkeiLEiPAxtCiJTP1l49Yj7h2wCZkxq+0KBuJxMhU8kU=@freebsd.org X-Gm-Message-State: AFq9FYLQcH8oZbpO3XEYG5wH6MS3u7gODYreY7DSXafgu3pHU3k1Z0hs 26bB9dXB5wDP0DNqc2A8XolfXDQ59LliInB8VtGeE6ho5x2REKAvZa4Vq87IRop1SO/3JWFIVzV AWWc= X-Gm-Gg: AYBFou2faW7bPp/j0fT5GLmwS46Ki410oZXzk9F/EEYNslXqWnkaQeX8ENKd2LWE63L MgIU3T4PDhH0WwaJR5NzrtGEPnJoiX7vU8ajYNQ8dIStuip+jwAUmO27ej+JEcVvIAKZbOUGIBO /2shNiDyaJjXUNV39boBtOFzSuDLmTjqbvHVGZAKM6yZQSbp9KhI058Z6gdWKpmk7eCoGxQzEXX 9ZgyKdAqSclriXGUR40PaQRev/UyS3hyDhG9mzmT1/wNJwbf11XT8WwKou7isnF+OOorrMfQdRv QXRy7SXukTClfaYP/1V8z5Sgc7oGvhBHodSqpbSyijYDb9UyNun+5oIt5g0rE+0L54i0bM/AKh1 e2di1JFtQdHXjMhCHK8QOctBnI+UAYzKHAvn/PdzgHyqEyEwmgD1JTYUu22wAyMgOsGHJyqlEzm EZq3svhFjfSYXMS2wCdBf75+/FpeDEmD6FS3n6G46wrknsRa0nxDxNUtL8tCVqh7fJTkKSbUFra KDlZ2mK270G/+cif8ZerMrPMftJGk/vDgY= X-Received: by 2002:a05:690c:312:b0:8b0:6866:c55f with SMTP id 00721157ae682-8b06866cda9mr264417b3.46.1791367077690; Wed, 07 Oct 2026 02:57:57 -0700 (PDT) Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com. [209.85.128.178]) by smtp.gmail.com with ESMTPSA id 00721157ae682-8b05a9b5329sm6987067b3.2.2026.10.07.02.57.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2026 02:57:56 -0700 (PDT) Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-8ab3aaf416dso16114137b3.2 for ; Wed, 07 Oct 2026 02:57:55 -0700 (PDT) X-Forwarded-Encrypted: i=1; AKwUvBy60GFBf9aVD1orbVllGn9nbKGmTO7/czWlQCiA61S7C6jwP8d30Ua+8Vb+NcyhMvHPvzVU2VhyOqTmdJ0=@freebsd.org X-Received: by 2002:a05:690c:c231:b0:8a8:7fda:15db with SMTP id 00721157ae682-8b05ae95f2bmr17604727b3.22.1791367074828; Wed, 07 Oct 2026 02:57:54 -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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> <7700025c-5167-4a05-93c0-3fc1864ef648@app.fastmail.com> In-Reply-To: <7700025c-5167-4a05-93c0-3fc1864ef648@app.fastmail.com> From: Tomek CEDRO Date: Wed, 7 Oct 2026 11:57:42 +0200 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK_OSK_TGZbovtZntoGV8xvIWymS9jdiKinNHu4gSEQAG75OcouHfmCk0-Y Message-ID: Subject: Re: i386 kernel removal To: Abdelkader Boudih Cc: Eugene Andrienko , Jessica Clarke , Vadim Goncharov , freebsd-arch Content-Type: multipart/alternative; boundary="000000000000285902065d3d26f9" X-Spamd-Bar: / X-Spamd-Result: default: False [-0.30 / 15.00]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[cedro.info]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1132:from,209.85.128.178:received]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; ALIAS_RESOLVED(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCPT_COUNT_FIVE(0.00)[5]; FROM_EQ_ENVFROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cedro.info:+] X-Rspamd-Queue-Id: 4j07pv00ZWz4ZLq --000000000000285902065d3d26f9 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 7, 2026, 11:06 Abdelkader Boudih wrote: > I really want to understand who these people are, and why they are not > upgrading their hardware. I want to understand their way of thinking. > (..) > You read back and see that in year 2026 people from two sides of military conflict of a so called modern world are talking together here trying to survive daily life with old enough computer hardware because only this one is still available. They are talking not only about their fears but also everyday reality. We experienced communism first hand. This is coming fast to so called civilized west. It always ends up the same way - terror and starvation. Some people experienced that in the past, some already do or will experience soon. Thus our resistance against destroying something that was already working fine.. because it may (and probably will) be useful again one day. On the other hand if the 32bit maintenance problems are caused by external projects like LLVM maybe these external dependencies should be pushed harder for long term self compatibility? Have you wondered why they may want to drop 32bit support in the first place? Should we also switch microcontrollers from 32 to 64 bits because of exactly the same reasons? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info --000000000000285902065d3d26f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 7, 2026, 11:06 Abdelkader B= oudih <seuros@freebsd.org> = wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I really want to understand who these people are, and why= they are not upgrading their hardware. I want to understand their way of t= hinking.
(..)

You read back and see that in y= ear 2026 people from two sides of military conflict of a so called modern w= orld are talking together here trying to survive daily life with old enough= computer hardware because only this one is still available. They are talki= ng not only about their fears but also everyday reality.

We experienced communism first hand. This = is coming fast to so called civilized west. It always ends up the same way = - terror and starvation.

Some people experienced that in the past, some already do or will experien= ce soon. Thus our resistance against destroying something that was already = working fine.. because it may (and probably will) be useful again one day.<= /div>

On the other hand if the= 32bit maintenance problems are caused by external projects like LLVM maybe= these external dependencies should be pushed harder for long term self com= patibility? Have you wondered why they may want to drop 32bit support in th= e first place?

Should we= also switch microcontrollers from 32 to 64 bits because of exactly the sam= e reasons?

--
--000000000000285902065d3d26f9-- From nobody Wed Oct 7 10:54:12 2026 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 4j094F3qxdz6vjrX for ; Wed, 07 Oct 2026 10:54:37 +0000 (UTC) (envelope-from seuros@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4j094F3Hfvz4gRl; Wed, 07 Oct 2026 10:54:37 +0000 (UTC) (envelope-from seuros@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791370477; 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=KyIV7oV6KSu6u9FYn8c8VWE/PtH9z93LOYDklnrAiBU=; b=mm2WxdKtUpEH8owgTDxV3MrnrcsHJXQ5rvKOcL4Tszv9DRFTz6R/d89f1LWsxJpT51VYhX xYmW4HR7Q29qYBCcdEr+InCuSTNGevfOhppkR1fJV+LZQmed2t6vrqpS00i2zjNZMBxC/m 1abT/GqxLSE5FhTMFYJ3wAmOrMP2Bb3gpmoLwauLnnWazE+ICdqshRz1U6nyE+bN2It/pR TohgFFoR6mk/tny7j9oXsaSzKCrDNIy8tX6TWxMZMRjnJR2EjKGD9n33GQ1yFrYZYZq+wF +DVplnwDUaAmOMPcTneZepbDgmjbpgnykvG4gMUooFZdbTwoIbTp9obIVv2fLQ== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791370477; b=wTCCGc9cRzpJWpJS7wxKuDQ27w0yR0al3LKNk31KGOOOIzKoKpaLnUiGWazo6KkaZpPJnd CtSypbqI2lhcw8w/6NAmN4JOLlrQUDoFv94ajqzsnGq+wlJLet1RT+IdPn29Dte2DsNwGD +PLorJApii7qs9IspQDzZr5RqCLTbkslf4DUey1qSmRLhLPH9ZbGmF/eFmPqqhXWSjObVp 1BkMfjd97GR3cEkxz2Js5wQfpjm6Qh3U9KVtuzIjX8TcZKg85/1iTEm1U3iQUtALVnXDsN uW3fyzBLE8+ClEDVYHYCV4zmCNYKMv4CzhoDmIQ6DdW4BCXokXuMWBr24vbCMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791370477; 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=KyIV7oV6KSu6u9FYn8c8VWE/PtH9z93LOYDklnrAiBU=; b=XqaxAh8hHIAMpwukeaOssleJbgl6cAdt2oh3pPjxxfNSX/4zDrI8NxKoiwSkEl6jfvt2pV nLBmBBbBn27W1hqamISL3CGDLBhIiVoPgKScNXC/6hAidj42RIQy7uTfWetabc4n9GpfoB Q9d0s4jHdCABZIgZQm0UcLJJ4sFSxfd/r25PwNRGumoNlBflpilWUnF8IfDnfYXzWTX8Lc +8cNM5VbRhJZjLSauB2nqUSOEzp8ZxVWZlsVilfJSTqEhCNDztsk1/f3+uFkB3eph1e9dE eH2nswq0IJiQB4AEMQRCrEpn840OR8k63rqg6Rc5L/XJkjvOLyBxMpfn8QiFaQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from fauth-a1-smtp.messagingengine.com (fauth-a1-smtp.messagingengine.com [103.168.172.200]) (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: seuros) by smtp.freebsd.org (Postfix) with ESMTPSA id 4j094F1kCtzZHY; Wed, 07 Oct 2026 10:54:37 +0000 (UTC) (envelope-from seuros@freebsd.org) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfauth.phl.internal (Postfix) with ESMTP id EF17CF40066; Wed, 7 Oct 2026 06:54:35 -0400 (EDT) Received: from phl-imap-04 ([10.202.2.82]) by phl-compute-06.internal (MEProxy); Wed, 07 Oct 2026 06:54:35 -0400 X-ME-Sender: X-ME-Proxy-Cause: dmFkZTF2qrnjaREPNPRr//gJZIqdBWqaAADqwI17iQtGz8PHPHtje44KO9cbt8EMX0phb3 RKlDBehfedgZ9KMBaBHNNk0RY/hecnpkIe/oqbqdW0J0THH1kjftglSP9BzzCCcm4ubzxI LSYmA76IbZPDZ815WaF9yIWTrueIqHHZZxu7yreqUqpsutbvLbb6XLaGmoEJIQTrxVi145 UmyX/vicKbVJ2IOy8iFUkCj7HCqwPi0nPomxv1hZknZeZekxRTCVGg2lInBt5pc6JPRdnS KrMaEoWeodYOhR1K9epn0VNHiY0h5X0bYuQpl92NaUKutAiHZ1cZqymNqNeD0y5IWjjgSJ nXg99Dkg3mVORVyqbrmfv+jnVn6V5ttVR7UEYfMXHPk3Rh58KS9TycKHoepxbHjBzLIq5q 1Nx9wynBtwdT1QMJ+d9sr6rW/VwU7qoIUkENdWgoYBn7nMN6uQCOTpg73jHq+lKwtgSc0E LHi17pBIfxL8ggEtiCFfhbYI4tOE6K6pjtT+RczVwHZThlYRVTl8es1Uhz16v6QFPTidwI tQSArrkqN3dJZ7UWFsaEuocwLk37lfo4ufYMs1pK8Gsji6XjYHdbVXuoeQmsE85P04on8E 4rbBInf2mo2XbHIZooosExUSe7ZbiajKorsBiTIQjHyQVM8ugxlgyU2OiupA X-ME-Proxy: Feedback-ID: i323e4aa8:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 9EE93B6006E; Wed, 7 Oct 2026 06:54:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-ThreadId: AjEgz-Vs0qfs Date: Wed, 07 Oct 2026 10:54:12 +0000 From: "Abdelkader Boudih" To: "Tomek CEDRO" Cc: "Eugene Andrienko" , "Jessica Clarke" , "Vadim Goncharov" , freebsd-arch Message-Id: In-Reply-To: References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> <7700025c-5167-4a05-93c0-3fc1864ef648@app.fastmail.com> Subject: Re: i386 kernel removal Content-Type: multipart/alternative; boundary=c856b75d6675f3f3bd4221ef080dcc43dd010751 --c856b75d6675f3f3bd4221ef080dcc43dd010751 Content-Type: text/plain Content-Transfer-Encoding: 7bit I already said in my email that the OS is not a SaaS. If you have old hardware, you install old software. I am not asking Nintendo to add USB support to retro consoles just because somebody may still be using one twenty years later. I am speaking from first hand experience, and I wrote this in my other emails too. Show me a real scenario, not an imagined one. When I recycled thousands of computers to run FreeBSD, I had the machines physically in front of me. I knew what CPUs they had, how much RAM they had, what was broken, what could be replaced, and what people were actually going to use them for. That is very different from constructing a hypothetical situation where society collapses and suddenly i386 becomes strategically important again. The 32-bit maintenance problem is mostly caused by the supply chain and by demographics. New chips are 64-bit, old machines are being replaced, and the people who grew up with 32-bit systems and understand the limitations and assumptions of that era are retiring. At the same time, fewer developers have access to that hardware and fewer people are interested in spending time on architecture-specific problems that no longer affect most systems. The new generation of engineers also does not feel the same friction we did. Last year I gave a talk at a university about old hardware and showed a picture of one of my old computers with 64 MB of RAM. The audience thought I was very then rich because they read it as 64 GB. Their brain did not even process the possibility that a usable operating system could run in 64 MB of RAM, while today a ReactJS application can sit idle using close to 900 MB. The 2GB HDD I showed them, had rust on it (not the language). and probably wiped itself, nobody except the professors understood/saw an ATA port. Just for info, I compiled LLVM from scratch with a 2006 machine with 8gb of ram as an experiment. The build took *27 days!*. I'm afraid of try it in a 32bit cpu only, it might finish by next conference in 2027. And to answer your last question, because I worked in hardware before. No we don't have to switch from 32 to 64bits in microcontrollers unless you need the 64bit features, I still use 8bit MCU when it needed, they use less power and I buy them per 10 thousands instead of few hundreds. But compiling 8bit mcu just require it special compiler that did not get an update since 2019. I want real example 32 bit usage in 2026 that is vital . I offered to swap those machine with a 64bit one, because I know that there is maybe 10 machines worldwide that still hit that criteria , 3 of those machines are in Adrian's workspace. Best, Abdelkader On Wed, 7 Oct 2026, at 09:57, Tomek CEDRO wrote: > You read back and see that in year 2026 people from two sides of military conflict of a so called modern world are talking together here trying to survive daily life with old enough computer hardware because only this one is still available. They are talking not only about their fears but also everyday reality. > > We experienced communism first hand. This is coming fast to so called civilized west. It always ends up the same way - terror and starvation. > > Some people experienced that in the past, some already do or will experience soon. Thus our resistance against destroying something that was already working fine.. because it may (and probably will) be useful again one day. > > On the other hand if the 32bit maintenance problems are caused by external projects like LLVM maybe these external dependencies should be pushed harder for long term self compatibility? Have you wondered why they may want to drop 32bit support in the first place? > > Should we also switch microcontrollers from 32 to 64 bits because of exactly the same reasons? > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > --c856b75d6675f3f3bd4221ef080dcc43dd010751 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I already said in my email that th= e OS is not a SaaS. If you have old hardware, you install old software. = I am not asking Nintendo to add USB support to retro consoles just becau= se somebody may still be using one twenty years later.

I am speaking from first hand experie= nce, and I wrote this in my other emails too. Show me a real scenario, n= ot an imagined one. When I recycled thousands of computers to run FreeBS= D, I had the machines physically in front of me.
I knew what CPUs they had, how muc= h RAM they had, what was broken, what could be replaced, and what people= were actually going to use them for.
That is very different from constructing a hy= pothetical situation where society collapses and suddenly i386 becomes s= trategically important again.

The 32-bit maintenance problem is mostly caused by the supply= chain and by demographics. New chips are 64-bit, old machines are being= replaced, and the people who grew up with 32-bit systems and understand= the limitations and assumptions of that era are retiring. At the same t= ime, fewer developers have access to that hardware and fewer people are = interested in spending time on architecture-specific problems that no lo= nger affect most systems.

The new generation of engineers also does not feel the same frict= ion we did. Last year I gave a talk at a university about old hardware a= nd showed a picture of one of my old computers with 64 MB of RAM. The au= dience thought I was very then rich because they read it as 64 GB. Their= brain did not even process the possibility that a usable operating syst= em could run in 64 MB of RAM, while today a ReactJS application can sit = idle using close to 900 MB. The 2GB HDD I showed them, had rust on it (n= ot the language). and probably wiped itself, nobody except the professor= s understood/saw an ATA port.

Just for info, I compiled LLVM from scratch with a 2006 machi= ne with 8gb of ram as an experiment. The build took 27 days!. &nb= sp;I'm afraid of try it in a 32bit cpu only, it might finish by next con= ference in 2027.

An= d to answer your last question, because I worked in hardware before.&nbs= p;
No we don= 't have to switch from 32 to 64bits in microcontrollers unless you need = the 64bit features, I still use 8bit MCU when it needed, they use less p= ower and I buy them per 10 thousands instead of few hundreds. But compil= ing 8bit mcu just require it special compiler that did not get an update= since 2019.

I want= real example 32 bit usage in 2026 that is vital . I offered to swap tho= se machine with a 64bit one, because I know that there is maybe 10 machi= nes worldwide that still hit that criteria , 3 of those machines are in = Adrian's workspace.

Best,
Abdel= kader

On Wed, 7 Oct 2026, at 09:57, Tomek CEDRO wrote:
You read back and see that in year 2026 people from two sides of m= ilitary conflict of a so called modern world are talking together here t= rying to survive daily life with old enough computer hardware because on= ly this one is still available. They are talking not only about their fe= ars but also everyday reality.

We experienced communism first hand. This is coming fast to so= called civilized west. It always ends up the same way - terror and star= vation.

Some people e= xperienced that in the past, some already do or will experience soon. Th= us our resistance against destroying something that was already working = fine.. because it may (and probably will) be useful again one day.
=

On the other hand if the 3= 2bit maintenance problems are caused by external projects like LLVM mayb= e these external dependencies should be pushed harder for long term self= compatibility? Have you wondered why they may want to drop 32bit suppor= t in the first place?

Should we also switch microcontrollers from 32 to 64 bits because of ex= actly the same reasons?

--
--c856b75d6675f3f3bd4221ef080dcc43dd010751-- From nobody Wed Oct 7 11:12:57 2026 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 4j09TZ5qykz6vkg6 for ; Wed, 07 Oct 2026 11:13:06 +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 4j09TY5QlPz4hPb for ; Wed, 07 Oct 2026 11:13:05 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk; dmarc=none Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1D98D9CC01 for ; Wed, 07 Oct 2026 11:12:58 +0000 (UTC) Received: from phk (uid 488) (envelope-from phk@critter.freebsd.dk) id 28711 by critter.freebsd.dk (DragonFly Mail Agent v0.13+ on critter.freebsd.dk); Wed, 07 Oct 2026 11:12:58 +0000 To: "Abdelkader Boudih" cc: "Tomek CEDRO" , "Eugene Andrienko" , "Jessica Clarke" , "Vadim Goncharov" , freebsd-arch Subject: Re: i386 kernel removal In-reply-to: From: "Poul-Henning Kamp" References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> <7700025c-5167-4a05-93c0-3fc1864ef648@app.fastmail.com> 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <43882.1791371577.1@critter.freebsd.dk> Date: Wed, 07 Oct 2026 11:12:57 +0000 Message-Id: <6ac6293a.28711.4d9211c1@critter.freebsd.dk> X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.00 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; HFILTER_FROMHOST_NORESOLVE_MX(0.50)[s2gw.ddhf.dk]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[phk]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[cedro.info,gmail.com,freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[freebsd.dk]; TO_DN_ALL(0.00)[]; ALIAS_RESOLVED(0.00)[]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4j09TY5QlPz4hPb -------- Abdelkader Boudih writes: > I want real example 32 bit usage in 2026 that is vital . I offered > to swap those machine with a 64bit one, because I know that there > is maybe 10 machines worldwide that still hit that criteria, 3 of > those machines are in Adrian's workspace. I pretty sure you are wrong about "10", because I know where some Soekris computers are still doing something very nearly important relating to ATC. But dont worry: My customer has already has made plans that will eliminate their role, so I will not forward your offer ;-) To me the deciding factor is: We may think we have i386 support in -CURRENT, but does not get used enough that we can have any confidence in it. Therefore please add my vote to the "still run i386 in production, but wants it removed from -CURRENT" column. -- 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 Wed Oct 7 12:38:59 2026 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 4j0CNv54zbz6vrJy for ; Wed, 07 Oct 2026 12:39:11 +0000 (UTC) (envelope-from mm@dorfdsl.de) Received: from srv1.dorfdsl.de (srv1.dorfdsl.de [IPv6:2a01:170:118f:3::22]) (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 (prime256v1) client-digest SHA256) (Client CN "srv1.dorfdsl.de", Issuer "YE1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4j0CNt4sMZz4t4k for ; Wed, 07 Oct 2026 12:39:10 +0000 (UTC) (envelope-from mm@dorfdsl.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dorfdsl.de header.s=default header.b="s+5QSJY/"; spf=pass (mx1.freebsd.org: domain of mm@dorfdsl.de designates 2a01:170:118f:3::22 as permitted sender) smtp.mailfrom=mm@dorfdsl.de; dmarc=pass (policy=none) header.from=dorfdsl.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dorfdsl.de; s=default; t=1791376736; bh=gtgiWMHpMye3VCEgU84+zPJuI2Bi1QdO1WWtKbVMwdM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=s+5QSJY/TxNXbtohJZ6F//iE59e+6VMsQiZL3dtbBjGHsgmQ/ISuUz7yJoJVTZ8XV l0+k+jixnY9lHgLPln9sYO0xVHbDpZzJ4pccKOmTVEuE3593kfFmRG5qQCdt0Xi17c 1KWKG44Ekpk+nihQiD0iuuHmZgYruFDZoOywOf3RnJzAJSRM5KK5kujXWLMxumQd1s ifaT8AYBfjWqMctQ2uWx0mr47YbEELSQ07CD7ikj233tJi8dvpJPwJIZm4BYVAfpWw 6OoAvmkZVESsqAL/VtvZvSC+PrbvAep3PAROVc3p2RIj0jNpgOy+ied6+Rx89g1i8T P+Q3e0WTxBisA== Received: from [IPV6:2a01:170:118f:2:894c:5e0f:ffaa:31ae] ([IPv6:2a01:170:118f:2:894c:5e0f:ffaa:31ae]) (authenticated bits=0) by srv1.dorfdsl.de (8.18.1/8.18.1/Debian-6) with ESMTPSA id 697CcuLR029368 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 7 Oct 2026 14:38:56 +0200 Message-ID: Date: Wed, 7 Oct 2026 14:38:59 +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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: i386 kernel removal To: freebsd-arch@freebsd.org References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> <7700025c-5167-4a05-93c0-3fc1864ef648@app.fastmail.com> Content-Language: en-US, de-DE From: Marco Moock Autocrypt: addr=mm@dorfdsl.de; keydata= xsDNBGnlI3gBDADDY5KSROZxxR7vS37LLqDMm0DyhP+6ou/D79MU+w+44OuNicr384mEMVAg PRSoig//mla8oso9fhwcu8G2IqWGzIzE8YKVq40veyJPGeOATMIbsI69oIKBjYZt7Vnw8g0Z 6iQq/9JqYRmHprtm9DPS4PME528f29jCTXOhmd7+RIHnNPiAa8Q7DDILZADRY03ksxDPYmRY 543dnDqIEuECamRfaahfJrMSJkmTt4UJEe1ZxCp1rUdgBbxrOyQyF5gVIdWr06+fyFnxpg6u YfuHl7OzPHYzHoOrNY0U9AEldW4QrNDIOqAJZVjxeWa9u2oxnIUCGMxQ/dHg5tTk+CDl2mXE aCAqOaQ5lcKFsxx7KR/BQfuRQW+Sm6meJmQQLHcWablpafAWSnqrZjz+5qflYj3CiN3vYXjE rpjLzPov3gOlfOGDXqkHTXmaenmB1HUybdpKRX0PH0r+LGJlA5U1cfy1IlvB9ZY8C2gGGRE7 LQTl228a1nvCis7+MRQm/pkAEQEAAc0bTWFyY28gTW9vY2sgPG1tQGRvcmZkc2wuZGU+wsEO BBMBCgA4FiEEGHxuJD2s+A3zICvbVZ4aMxpGtGMFAmnlI3gCGwMFCwkIBwIGFQoJCAsCBBYC AwECHgECF4AACgkQVZ4aMxpGtGOiwQv8D202XflE5ipU1uhx6VyqcZ/IQ5/eiMs+gGbm3GFK SIBpQBy2c+QDRFf7zhB/r3omVB6PHrVJGBU/T1m3BKNmCdnp1JaczjOybt+MNQGtm5RgWhpk 3he7gyp0vnT3Vy8fs2fF+pnnrt4IOnHu6hKWGXINSUxcZknRI2SFcJuYYbg+EXD/ShyDIPA0 qihw74kSY+yoa09D+W6qxrSf0+dgUUWobPwhIrPG6ypFqu5rcy/ByvifRH4vz2+C7iWF4Rtt 1U+74CqiEspF/b9B6zzg3PsdEaiuRBI4S6bJXZiMLH1cUFY4sGjSW8Qbt5/hZB9NiToW3VoY lBHohdCPRI4haEJTyZ5n7irXozO6Z/3Ikq+7jDS5I4c5v1PqFgorqiRbbh2yMKi7F2WfJcjK b2JNz7wvLAKmfqH1JO0TmmzdzCidXUOJd3zti5PyTrRrZHNWK1aAG72mhug67zTgr81zW0ph F9diJYbQVBCe27TVssm9gN3eNGrZIBQkHfI/wNaBzsDNBGnlI3gBDADjXrGqJttd4WsQ/iiZ cUA+2Qh5HMJuLSuIjBTkv/sZX5kUwWhDbXFW28TlNwEk5ogtByLOq4kmgsygZU0nk1DfpDKw yumc1n6+ReBpYNTkWUfxF3unpMuO4BE+sfEFlCJe6fjC2yTzwrC/Ls+EjkbvRzHiCfJrddQx /iKEBWCJVlWuwB4iEvO0EZh9eYPulx+p0iJRRGdRH3RBIJyQXK8sEFsfMTzOCXHwVfjkVmBc CZHviGaG5Urn7f7aHfpfxV9mN8Idxa1Eksgi/9aCuTHFQwfeyrTsNVfp1MUKG/H85/uRieXc 5MnF8i7f7luBSJCnZcqTjN0q/jLD6GJyMbnoKA71pzAlEC0EaK9MIZgSz7m4nh/JCBXPL6+t bc26lD6HDNLqMCfD2uvbpdkY/gjOo661W9fIZ+V33N+veH0ckCI8SByiJRSOotYK2rBFlfnh JzucC0yQvNxtcxlnrPvb5mt5cUMlxI1xWO4aQ+pHmZALLItna0ODS6jujxZZNkkAEQEAAcLA 9gQYAQoAIBYhBBh8biQ9rPgN8yAr21WeGjMaRrRjBQJp5SN4AhsMAAoJEFWeGjMaRrRjNUQM AKivzYaSLxYCB/IVLZpexHssAN0IBOwuEFkfMfmzSRNPLakMA0PhzJvy0HkNVT9l+7X4Uu3X +5KkPdLKPs0Z8h8h18vxKUCkknEUY3dT5EVeNAgSshxjxmCAVvQvHdW6ZBxYNJoHQrU1xpkr EHwNP6I/VqH+C6aSncXq8TU3LeBT9l58douj6JknXaiEblQj9SUWtYWVVK4/+PqOpWrbE1kB fwkMGlFHpRQzIsAkIGqnUes/RoM1EszeYNjvKAuNaw5ghUDwgQbd8MIIoi0S82kpvflJSLzQ KziNuzyunAUeJeFW9PQ2BzOf4gK9G3+pqkpLQ2OdwDL/TAqlzElWX7O2hW0X+L2+6dPOYGey HTsU2eYMeB2q6VQpJEas3ebWHRANt31wA2mvSQKbYJJYofxThfCMUcKD0CUHduEXwdahB7Vy PDCIU7kwmN2JG5n4foywEym/i942UyTQu30MtPpuhwBhpka5jG6wiFfpQAdwsb0QF0Gpzcet MCwzZXR/AA== Organization: keine vorhanden, alles chaotisch In-Reply-To: <7700025c-5167-4a05-93c0-3fc1864ef648@app.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------b00821D6I8cmWXoneqsD7ghd" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.80 / 15.00]; SIGNED_PGP(-2.00)[]; DMARC_POLICY_ALLOW(-0.50)[dorfdsl.de,none]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[dorfdsl.de:s=default]; R_SPF_ALLOW(-0.20)[+ip6:2a01:170:118f:3::22:c]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:8820, ipnet:2a01:170::/32, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; FREEFALL_USER(0.00)[mm]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[dorfdsl.de:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4j0CNt4sMZz4t4k This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------b00821D6I8cmWXoneqsD7ghd Content-Type: multipart/mixed; boundary="------------n6D6om5Pqtj016MBU5L7w0nX"; protected-headers="v1"; hp="clear" Message-ID: Date: Wed, 7 Oct 2026 14:38:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: i386 kernel removal To: freebsd-arch@freebsd.org References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> <7700025c-5167-4a05-93c0-3fc1864ef648@app.fastmail.com> Content-Language: en-US, de-DE From: Marco Moock Autocrypt: addr=mm@dorfdsl.de; keydata= xsDNBGnlI3gBDADDY5KSROZxxR7vS37LLqDMm0DyhP+6ou/D79MU+w+44OuNicr384mEMVAg PRSoig//mla8oso9fhwcu8G2IqWGzIzE8YKVq40veyJPGeOATMIbsI69oIKBjYZt7Vnw8g0Z 6iQq/9JqYRmHprtm9DPS4PME528f29jCTXOhmd7+RIHnNPiAa8Q7DDILZADRY03ksxDPYmRY 543dnDqIEuECamRfaahfJrMSJkmTt4UJEe1ZxCp1rUdgBbxrOyQyF5gVIdWr06+fyFnxpg6u YfuHl7OzPHYzHoOrNY0U9AEldW4QrNDIOqAJZVjxeWa9u2oxnIUCGMxQ/dHg5tTk+CDl2mXE aCAqOaQ5lcKFsxx7KR/BQfuRQW+Sm6meJmQQLHcWablpafAWSnqrZjz+5qflYj3CiN3vYXjE rpjLzPov3gOlfOGDXqkHTXmaenmB1HUybdpKRX0PH0r+LGJlA5U1cfy1IlvB9ZY8C2gGGRE7 LQTl228a1nvCis7+MRQm/pkAEQEAAc0bTWFyY28gTW9vY2sgPG1tQGRvcmZkc2wuZGU+wsEO BBMBCgA4FiEEGHxuJD2s+A3zICvbVZ4aMxpGtGMFAmnlI3gCGwMFCwkIBwIGFQoJCAsCBBYC AwECHgECF4AACgkQVZ4aMxpGtGOiwQv8D202XflE5ipU1uhx6VyqcZ/IQ5/eiMs+gGbm3GFK SIBpQBy2c+QDRFf7zhB/r3omVB6PHrVJGBU/T1m3BKNmCdnp1JaczjOybt+MNQGtm5RgWhpk 3he7gyp0vnT3Vy8fs2fF+pnnrt4IOnHu6hKWGXINSUxcZknRI2SFcJuYYbg+EXD/ShyDIPA0 qihw74kSY+yoa09D+W6qxrSf0+dgUUWobPwhIrPG6ypFqu5rcy/ByvifRH4vz2+C7iWF4Rtt 1U+74CqiEspF/b9B6zzg3PsdEaiuRBI4S6bJXZiMLH1cUFY4sGjSW8Qbt5/hZB9NiToW3VoY lBHohdCPRI4haEJTyZ5n7irXozO6Z/3Ikq+7jDS5I4c5v1PqFgorqiRbbh2yMKi7F2WfJcjK b2JNz7wvLAKmfqH1JO0TmmzdzCidXUOJd3zti5PyTrRrZHNWK1aAG72mhug67zTgr81zW0ph F9diJYbQVBCe27TVssm9gN3eNGrZIBQkHfI/wNaBzsDNBGnlI3gBDADjXrGqJttd4WsQ/iiZ cUA+2Qh5HMJuLSuIjBTkv/sZX5kUwWhDbXFW28TlNwEk5ogtByLOq4kmgsygZU0nk1DfpDKw yumc1n6+ReBpYNTkWUfxF3unpMuO4BE+sfEFlCJe6fjC2yTzwrC/Ls+EjkbvRzHiCfJrddQx /iKEBWCJVlWuwB4iEvO0EZh9eYPulx+p0iJRRGdRH3RBIJyQXK8sEFsfMTzOCXHwVfjkVmBc CZHviGaG5Urn7f7aHfpfxV9mN8Idxa1Eksgi/9aCuTHFQwfeyrTsNVfp1MUKG/H85/uRieXc 5MnF8i7f7luBSJCnZcqTjN0q/jLD6GJyMbnoKA71pzAlEC0EaK9MIZgSz7m4nh/JCBXPL6+t bc26lD6HDNLqMCfD2uvbpdkY/gjOo661W9fIZ+V33N+veH0ckCI8SByiJRSOotYK2rBFlfnh JzucC0yQvNxtcxlnrPvb5mt5cUMlxI1xWO4aQ+pHmZALLItna0ODS6jujxZZNkkAEQEAAcLA 9gQYAQoAIBYhBBh8biQ9rPgN8yAr21WeGjMaRrRjBQJp5SN4AhsMAAoJEFWeGjMaRrRjNUQM AKivzYaSLxYCB/IVLZpexHssAN0IBOwuEFkfMfmzSRNPLakMA0PhzJvy0HkNVT9l+7X4Uu3X +5KkPdLKPs0Z8h8h18vxKUCkknEUY3dT5EVeNAgSshxjxmCAVvQvHdW6ZBxYNJoHQrU1xpkr EHwNP6I/VqH+C6aSncXq8TU3LeBT9l58douj6JknXaiEblQj9SUWtYWVVK4/+PqOpWrbE1kB fwkMGlFHpRQzIsAkIGqnUes/RoM1EszeYNjvKAuNaw5ghUDwgQbd8MIIoi0S82kpvflJSLzQ KziNuzyunAUeJeFW9PQ2BzOf4gK9G3+pqkpLQ2OdwDL/TAqlzElWX7O2hW0X+L2+6dPOYGey HTsU2eYMeB2q6VQpJEas3ebWHRANt31wA2mvSQKbYJJYofxThfCMUcKD0CUHduEXwdahB7Vy PDCIU7kwmN2JG5n4foywEym/i942UyTQu30MtPpuhwBhpka5jG6wiFfpQAdwsb0QF0Gpzcet MCwzZXR/AA== Organization: keine vorhanden, alles chaotisch In-Reply-To: <7700025c-5167-4a05-93c0-3fc1864ef648@app.fastmail.com> --------------n6D6om5Pqtj016MBU5L7w0nX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 QW0gMDcuMTAuMjYgdW0gMTE6MDQgc2NocmllYiBBYmRlbGthZGVyIEJvdWRpaDoNCj4gSSBy ZWFsbHkgd2FudCB0byB1bmRlcnN0YW5kIHdobyB0aGVzZSBwZW9wbGUgYXJlLCBhbmQgd2h5 IHRoZXkgYXJlDQo+IG5vdCB1cGdyYWRpbmcgdGhlaXIgaGFyZHdhcmUuIEkgd2FudCB0byB1 bmRlcnN0YW5kIHRoZWlyIHdheSBvZg0KPiB0aGlua2luZy4NCg0KU29tZSBwZW9wbGUgZG8g bm90IHdhbnQgb2xkIHN0dWZmIHRvIGdvLiBTb21lIChJIHRoaW5rIGEgbXVjaCBzbWFsbGVy IA0KYW1vdW50KSBzdGlsbCB1c2VzIGl0LiBDZXJ0YWluIGk2ODYgaGFyZHdhcmUgKEF0aGxv biBYUCwgZWFybHkgUGVudGl1bSANCjQpIGNhbiBzdGlsbCBiZSB1c2VkIGZvciBzb21lIHVz ZSBjYXNlcywgZS5nLiBydW5uaW5nIGEgc21hbGwgc2VydmVyLg0KDQo+IEkgZmVlbCB3ZSBh cmUgZG9pbmcgdGhlIHNhbWUgZGFuY2UgTGludXggZGlkIGFyb3VuZCB0aGUgcmVtb3ZhbCBv Zg0KPiBpNDg2LiBGb3IgYSBsb25nIHRpbWUgcGVvcGxlIGtlcHQgc2F5aW5nIHRoYXQgc3Vw cG9ydCBzaG91bGQgc3RheSwNCj4gYnV0IHdoZW4gdGhleSB3ZXJlIGFza2VkIHRvIHNob3cg YW4gYWN0dWFsIGJvb3RpbmcsIHdvcmtpbmcgbWFjaGluZQ0KPiB3aXRoIGEgY3VycmVudCBM aW51eCByZWxlYXNlLCB0aGV5IGZvbGRlZCBhbmQgZ290IGJ1c3kgd2l0aCBvdGhlcg0KPiB0 aGluZ3MuDQoNCkV4YWN0bHkuIFRoZXJlIGFyZSBub3QgbWFueSB2b2x1bnRlZXJzIHRvIGFj dHVhbGx5IG1haW50YWluIGFuZCB0ZXN0IHRoZQ0KY29kZSBvbiBvbGQgaGFyZHdhcmUuDQoN Cj4gVGhlIHNhbWUgdGhpbmcgaGFwcGVucyB3aXRoIG90aGVyIHJldHJvIGhhcmR3YXJlLiBB IDQgR0IgRERSMiBzdGljaw0KPiB0aGF0IHVzZWQgdG8gYmUgJDE1IGNhbiBub3cgY29zdCBj bG9zZSB0byAkMTAwLiBERFIgVFdPLiBub3QgYSB0eXBvLg0KDQpBbHRob3VnaCwgbm9ybWFs IEREUjIgMSBvciAyIEdpQiBzdGlja3MgYXJlIHJhdGhlciBjaGVhcCBhbmQgY2FuIGFsc28g YmUgDQpmb3VuZCBvbiB0aGUgc2NyYXB5YXJkLg0KPiBUaGlzIGJyaW5ncyBtZSBiYWNrIHRv IGkzODYuDQo+IFdobyBhcmUgdGhlIHBlb3BsZSBzdXBwb3NlZGx5IG1pZ3JhdGluZyBhd2F5 IGZyb20gRnJlZUJTRCBiZWNhdXNlDQo+IGkzODYgaXMgZGlzYXBwZWFyaW5nID8gV2hlcmUg ZGlkIHRoZXkgZ28gPyBXaGF0IGhhcmR3YXJlIHdlcmUgdGhleQ0KPiBhY3R1YWxseSB1c2lu ZyA/IFdlcmUgdGhleSB1c2luZyBpMzg2IGJlY2F1c2UgdGhlIENQVSBjYW5ub3QgcnVuDQo+ IGFtZDY0LCBvciB3ZXJlIHRoZXkgc2ltcGx5IHJ1bm5pbmcgYSAzMi1iaXQgaW5zdGFsbGF0 aW9uIG9uIGEgNjQtYml0DQo+IGNhcGFibGUgbWFjaGluZSA/DQoNClRoZXJlIGlzIHN0aWxs IHNvbWUgeDg2IGhhcmR3YXJlIGFyb3VuZCB0aGF0IGlzIGluIHVzZS4gVGhlIG90aGVycyB3 aXRoIA0KYW1kNjQgY2FwYWJsZSBwcm9jZXNzb3JzIGNhbiBpbnN0YWxsIGFtZDY0Lg0KDQo+ IFRoZXJlIGNvdWxkIGJlIDEwMDAwIGkzODYgdXNlcnMgYW5kIG5vYm9keSBtYWludGFpbmlu ZyBpMzg2LiBUaGVyZQ0KPiBjb3VsZCBhbHNvIGJlIHRoaXJ0eSBzZXJpb3VzIHVzZXJzIHdp dGggaGFyZHdhcmUsIENJLCBrbm93bGVkZ2UgYW5kIGENCj4gY291cGxlIG9mIGRldmVsb3Bl cnMgYWN0aXZlbHkgZml4aW5nIHJlZ3Jlc3Npb25zLCBhbmQgdGhhdCBtYXkgYmUNCj4gZW5v dWdoIHRvIGp1c3RpZnkga2VlcGluZyBpdC4NCg0KSSBoYXZlIGRvdWJ0LiBhbWQ2NCBpcyBj b21tb24gZm9yIDIwIHllYXJzIHdpdGggYSBmZXcgZXhjZXB0aW9ucy4NClRoZSBwb3dlciB1 c2FnZSBvZnRlbiBhbHJlYWR5IG1ha2VzIGJ1eWluZyBhIG5ldywgc21hbGwgc3lzdGVtIGNo ZWFwZXIgDQp0aGF0IGtlZXBpbmcgdGhlIG9sZCBtYWNoaW5lIHJ1bm5pbmcuDQoNCg0KDQot LSANCkdydcOfDQpNYXJjbw0KTXVlbGwgdW5kIFNwYW0gYml0dGUgYW4gYWJmYWxsZWltZXIy MDAyQHN0aW5rZWRvcmVzLmRvcmZkc2wuZGUNCg== --------------n6D6om5Pqtj016MBU5L7w0nX-- --------------b00821D6I8cmWXoneqsD7ghd Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wsD5BAABCAAjFiEEGHxuJD2s+A3zICvbVZ4aMxpGtGMFAmrGPWMFAwAAAAAACgkQVZ4aMxpGtGOG YgwAsvoSa0jaqp4dI9M5Ac+Fb+FvAUeNH0N17JuoHzU2XYrLfd5TqPqnV3zz0lDB6Fb8Z166ioPH 16sQNFZVT6HSt3Y+pFDw6n82o17aWS94MAskLxrNxL3+sxM+oR2Q4gmdGzZSxRMPsn4MVY8S8FR/ ap0zZaSrMtWXWQIdLU6Ihc6hB8DqS4wsCsE0cSataWEdPdUw3cs9Muuq2sXfL7bNcaD6pPnkhWGk lXmg9PbohMjNBl19TpcB3+LQ4L0ZnS46bKwRYD7ubnMpoAHkg1EJqanI3e3csvhDnLfEiZ8bh7jv UM0Sj5izN4rjFmmcz69RAOW4o+Bx1QcSRk5j6mV+H8ALEpqqWMAk4dvk+bk6mJz6jDSsmr0yqBNp DaFwigLePKH01I90GNcYqBuVIQ55XmnKKCL/W+GqkZR8ILKCWuSE6VnEtp6zkav/XNpFh+5RNqyq IRQB9F5hcJCvkB3cy5yJEa+nkThQcJG3dRJYDPTpNirGfcdzXWdZjoRplQTI =tjVj -----END PGP SIGNATURE----- --------------b00821D6I8cmWXoneqsD7ghd-- From nobody Wed Oct 7 15:19:28 2026 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 4j0GyT4c07z6w3Y7 for ; Wed, 07 Oct 2026 15:20:01 +0000 (UTC) (envelope-from seuros@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4j0GyT44Dhz4LmK for ; Wed, 07 Oct 2026 15:20:01 +0000 (UTC) (envelope-from seuros@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791386401; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0oKfRHTpAvG489CHhFkcNhwgNmtjAfegLZwdGtJGlyM=; b=axD7nIPaJ6lS5Qaxxyjm4WnBrzqdx8ycYVgyrwcHxfGF6fq7tW01ycZf3F5ozAeSizjC4P ncOjlwNbYREdIFFfaI12DK5MAzrWvmOAxdnUP6ZWmSxZPNrWFQ8CDNVjKmd4FYwQNAqCTT bBkUQQWefeSSm/UIHO5S0kuUrMoFOe8XV6pybxj1QCdRuWxmQE4kRAO+rk4fe+YqctAaU4 9WuVNCdYT2nIGOqdqghCrudRSmc117I2ztsr0Wwbg2lA2Lb8Cp2zj4Eik52KVFroyc2BhA Nn+uFW5EseC86syASyWyA1oUr49Md2vL7sydxMP7chAnud7DFFi80Rjui28rSg== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791386401; b=MGxxACucb29pMcVuXephcSMqYnn1HmVnMUGmkG/M+ID3/tdNley4BvRiPI9vRelfLtRXMY g565MHcsNljfavxHTARHxOxFS028RjxXPvQ+X5psI/KXum2vWwf6dApbjqkByDUNk0ZCLv EOkjmyfr7q7zxZe2azFwDiWVvil6CqAUvAAU6byrloapXOjX10Yu4TOKY/AdFqqzDr6gRc EHGf9tc+Jzan4Ge6NGX9x/HBhXb7k1USDq3eOIahN9mECIRkuX0cI94Xmbo/mR2HKNik4y Fb980+RcHYzdJWUP7AC7Xvnon9ZoBRO9Vbalrxhp3+jQBgYINMKNpopcXQK7fA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791386401; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0oKfRHTpAvG489CHhFkcNhwgNmtjAfegLZwdGtJGlyM=; b=Umr56qI/QcY0OfPXv5FPsYWA6/GU53APhCgQgRZNxc0MFoD7j65N/EFEWqYhD42L1rYNCW bE8uMxnSUYcDjjj/P7aC4wea5T7faY5gTfkzwQSeUuq1Yos2AAoDdgzRq8tawaOa2hePRY ySurrby4Sn7XI7tufamFQ1fSG/ZX3LB2fPHxnhBuhWfZC1jBND0v2ImS+plIfmOUq/FDib 0C/Wa7CNmzfuQRS4u5EAjHXwDdI1+Q1T/ojULV2O/1vJSM5x4XFcv7mj5upzUdyCk/hWBX L/L7DbLwpeC5d96+Jp84WzHN1EJMBbCKZIDP/fG5dqheX9vibc1M/tXW22tl5A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com [103.168.172.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 did not present a certificate) (Authenticated sender: seuros) by smtp.freebsd.org (Postfix) with ESMTPSA id 4j0GyT2fnhzhZD for ; Wed, 07 Oct 2026 15:20:01 +0000 (UTC) (envelope-from seuros@freebsd.org) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfauth.phl.internal (Postfix) with ESMTP id 2A2B7F40066 for ; Wed, 7 Oct 2026 11:20:01 -0400 (EDT) Received: from phl-imap-04 ([10.202.2.82]) by phl-compute-06.internal (MEProxy); Wed, 07 Oct 2026 11:20:01 -0400 X-ME-Sender: X-ME-Proxy-Cause: dmFkZTE1XpDHKNghaJWS0sAA6hJTRi9WDtLppvs9z1TcrMJ2yW/JiuL48hinzas+rPrdww JkTPH2ErlpebXlcZOe8oV8hbjnm45B7hCaHXttM9BkZo38md+FYGvcm6BewseCkoRJo5pQ KUtIrmbD6MpN5BkDRFbtR47L06XqARrBorZA7VDzAb0PRGEJccssgVUMKby+3p6TtaCe5Z Ir6z5pFPMBieOv6ByMr4XFmDYNj9CBV0uPGPeO6xuexze3KmaMNTZ3159dZSjuSbhyMPJG IOTLkGRIKa1YyHrHlEUexry+DQM79kJo01Ul6h8f0epX5hlC3mhkJKSdsGNHDS9kj5zeUs AIhOii72ttqlPEyX4o5JO2NiNSlSecanYC/CByaZdDOY8dk5g91nZ8ebY4g0z4SVOzn4A+ Kuxt3d3XMBktcoxkYsncuBSOQWzl5Q0/vzzBKqddt1+uSRgGMu8WMUSHH2guUWdZQDevQU IQIdh1ifII+HCADZlwyjiBr6rDtd4/dk5n5Sch0kyymTuN5b7TaPPUHBvPDkIlzmFWrPA9 eJml4sserb7oLuDnQDgFP2NJFG7I3PnBi0ALyGMqGJ3wC6shKGeCs8pTjtvnXxDUVUBrSm COgVvhlSABIQTS0UEdr2deNpHVKTOip54dF0nhylIzhqCCBCDiRCdHjAfH+w X-ME-Proxy: Feedback-ID: i323e4aa8:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 11C39B6006E; Wed, 7 Oct 2026 11:20:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-ThreadId: AjEgz-Vs0qfs Date: Wed, 07 Oct 2026 15:19:28 +0000 From: "Abdelkader Boudih" To: freebsd-arch@freebsd.org Message-Id: <8f49e71d-79eb-469b-9aee-832d82116733@app.fastmail.com> In-Reply-To: References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> <7700025c-5167-4a05-93c0-3fc1864ef648@app.fastmail.com> Subject: Re: i386 kernel removal Content-Type: multipart/alternative; boundary=540554b1913f7e04b75d89ba69ef4064fcc07756 --540554b1913f7e04b75d89ba69ef4064fcc07756 Content-Type: text/plain Content-Transfer-Encoding: 7bit > Some people do not want old stuff to go. Some (I think a much smaller > amount) still uses it. Certain i686 hardware (Athlon XP, early Pentium > 4) can still be used for some use cases, e.g. running a small server. It doesn't matter. No maintainer, daily driver, niche community == out. Bring the maintainer with real scenario, we revert the eviction commit. Right now, nobody want to take responsibility. I have 2 diffs in pharb that nobody is looking at, because nobody has time to review them, i have 13 others locally. I will not bother others maintainer with 15 diff that will switch their mental context to validate something vintage. Note: I didnt event spend much time on the 15 diffs, maybe 1-2h. Compiler warned about the error, i fixed it, i recompiled, compiler was happy. then i tested on the hardware. Linux purged ARM 32 bit drivers https://itsfoss.com/news/linux-kernel-old-arm-code-removal/, because they got hit by people running AI in a loop and no maintainer to review it. > Exactly. There are not many volunteers to actually maintain and test the > code on old hardware. That the point, code without ownership slow down everybody else, we cannot upgrade because that piece of code still assume 32 bit only. > Although, normal DDR2 1 or 2 GiB sticks are rather cheap and can also be > found on the scrapyard. True, but normal laptop have 1-2 slots max and Ubuntu latest require 6gb min. So if you going to eco mode, you better top up the laptop to 2x4gb... 8gb to at least open chrome and reply to this message with 99% memory usage. > There is still some x86 hardware around that is in use. The others with > amd64 capable processors can install amd64. Still for x86, they can install FreeBSD 15.1+ until one of their capacitors explode. > I have doubt. amd64 is common for 20 years with a few exceptions. > The power usage often already makes buying a new, small system cheaper > that keeping the old machine running. The number is exaggerated in the upper level, i'm not speaking about 32 bit hardware worldwide, there are more than 10k. But there is 0% that we have 10k+ 32-bit only FreeBSD user willing to upgrade to 16 later and none of them joined this thread or filled a bug in the last years. So my guess is people that want to have just in case. PS: We removed support to ARM7 too. NOTE: i'm not speaking on behalf of all the team, this is just a discussion and my personal opinion based on past experiences. I spend years believing that backward compatibility was a virtue, until i realized that it was slowing me down. --- Abdelkader --540554b1913f7e04b75d89ba69ef4064fcc07756 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Some people do not wan= t old stuff to go. Some (I think a much smaller 
amount) = still uses it. Certain i686 hardware (Athlon XP, early Pentium 
4) can still be used for some use cases, e.g. running a small ser= ver.
It doesn't matter. No maintainer, daily driv= er, niche community =3D=3D out.
Bring the maintainer with real= scenario, we revert the eviction commit. Right now, nobody want to take= responsibility.

I have 2 diffs in pharb that n= obody is looking at, because nobody has time to review them, i have 13 o= thers locally. 
I will not bother others maintainer with = 15 diff that will switch their mental context to validate something vint= age.

Note: I didnt event spend much time on the= 15 diffs, maybe 1-2h.  Compiler warned about the error, i fixed it= , i recompiled, compiler was happy. then i tested on the hardware.
=

Linux purged ARM 32 bit drivers https://itsfoss= .com/news/linux-kernel-old-arm-code-removal/, because they got hit b= y people running AI in a loop and no maintainer to review it.
=
Exactly. T= here are not many volunteers to actually maintain and test the
code on old hardware.

That the po= int, code without ownership slow down everybody else, we cannot upgrade = because that piece of code still assume 32 bit only.

<= /div>
Although, norma= l DDR2 1 or 2 GiB sticks are rather cheap and can also be 
found on the scrapyard.

True, bu= t normal laptop have 1-2 slots max and Ubuntu latest require 6gb min.
So if you going to eco mode, you better top up the laptop to 2x4= gb... 8gb to at least open chrome and reply to this message with 99% mem= ory usage.

There is still some x86 hardware around that is in use. The o= thers with 
amd64 capable processors can install amd64.
Still for x86, they can install FreeBSD 15.1+ unti= l one of their capacitors explode.

I have doubt. amd64 is common for 20 ye= ars with a few exceptions.
The power usage often already makes= buying a new, small system cheaper 
that keeping the old= machine running.

The number is ex= aggerated in the upper level, i'm not speaking about 32 bit hardware wor= ldwide, there are more than 10k.
But there is 0% that we have = 10k+ 32-bit only FreeBSD user willing to upgrade to 16 later and none of= them joined this thread or filled a bug in the last years. So my guess = is people that want to have just in case.
PS: We removed suppo= rt to ARM7 too.

NOTE: i'm not speaking on behal= f of all the team, this is just a discussion and my personal opinion bas= ed on past experiences.
I spend years believing that backward = compatibility was a virtue, until i realized that it was slowing me down= .

---
Abdelkader
--540554b1913f7e04b75d89ba69ef4064fcc07756-- From nobody Wed Oct 7 15:48:19 2026 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 4j0Hb93VZHz6w59f for ; Wed, 07 Oct 2026 15:48:21 +0000 (UTC) (envelope-from jhibbits@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4j0Hb932c6z4Q4k; Wed, 07 Oct 2026 15:48:21 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791388101; 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=CM1fRpiefKGBEoIjP4I3ljI8tlbIMmTkrBxytHitANA=; b=eqX/q2KN0qAerW039b1rGG2hrE/+5evPBAyuxtLjMdceXi0JKbyAQoi+5h8QHESmrcQQ1f Gvysvz7zcVXhrX3kzkxIQbhI0zfoXQGOI1Qz99A+zw/gMxVxYQKVwvSP35mJrTzju9tAmH qGlqYpdVsU1vHHjilnnNVsSJifFBtBYAeaLkiSoVFu1eH8AcWzCMLPj1Qem1Z7asYGzNPT Mh8NihY4fB5SszcCrkP6b0k5u9eiQBuNyzse5tZ7QsU0X9S3EJ1A48p38UxiF9qT835OjU Lw4xNvbgfLFojXcGEBhgkz0jQ1o7a2U6nYYCKtBXukJBHS5BOUt0sAmC88rHsw== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791388101; b=rsmdvKACu8cnC2wC8qSR5xkbZamFh1rP9sA33cHSriXSpYtHSllAcp8J10n+8S0+GYC/3C Yk/j4wGnMjqBiTf3sGatTFmu9f+nEP0uitrxu3nOEPhcIvkHRKSnJEyrtvfw1l7zQVPJND z3AppJ+YaNJNq8b7eOy3QNKAAXtDKbaatgd6DoczW98fxTOj9iiwC3a+1aKI55Bncl9ymc THM6MK6QlUU597ITgl77WLuxatIBztVCt+OuqUBuqPMWnvYKvbzEPtbtjSaF6+AYN/2HKi dmoApyfWSmX0gWQmJQ6NvxypX/fF5D1kWpS/I7j8rhtn8d2q3QFjtgxFyHX6Jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791388101; 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=CM1fRpiefKGBEoIjP4I3ljI8tlbIMmTkrBxytHitANA=; b=QZ66/mOKV1Br046qTogWDlIM9tvhKUKrU1oLGh+6N53jiJPkgXd6c+vRuTQdvCO7eaMOyb m+4OCrI7t5niX78glW140VQoEhtJoKcQEgknJimqjPQcujqGYsNlMQTcHXO4Ec1uAaVH44 ar0SXuqdIUwhFbnKAipyiOBfK729+nEOy/H/KwhC30mz7A0QuMJgaZ5F8dWerqesYP9Xn5 /+h4rr7PeLr7zLQTmtcy8alC0+bGy6qffKkPPIFToSc88R86mIyeKopREYbqNBCXM4kcj6 mC4p4jNi7uCnV6to6WUUm1SqORCn1IR6sipnEtNANOolND1XeEKVtnW3IGqYDA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ralga.knownspace (unknown [IPv6:2600:2b00:a720:d301:9f03:382a:d672:81f0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange secp256r1 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhibbits) by smtp.freebsd.org (Postfix) with ESMTPSA id 4j0Hb910KwzhcN; Wed, 07 Oct 2026 15:48:21 +0000 (UTC) (envelope-from jhibbits@FreeBSD.org) Date: Wed, 7 Oct 2026 11:48:19 -0400 From: Justin Hibbits To: "Abdelkader Boudih" Cc: freebsd-arch@freebsd.org Subject: Re: i386 kernel removal Message-ID: <20261007114819.59955079@ralga.knownspace> In-Reply-To: <8f49e71d-79eb-469b-9aee-832d82116733@app.fastmail.com> References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> <7700025c-5167-4a05-93c0-3fc1864ef648@app.fastmail.com> <8f49e71d-79eb-469b-9aee-832d82116733@app.fastmail.com> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; powerpc64le-unknown-linux-gnu) 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 07 Oct 2026 15:19:28 +0000 "Abdelkader Boudih" wrote: > > Some people do not want old stuff to go. Some (I think a much > > smaller amount) still uses it. Certain i686 hardware (Athlon XP, > > early Pentium 4) can still be used for some use cases, e.g. running > > a small server. > It doesn't matter. No maintainer, daily driver, niche community == > out. Bring the maintainer with real scenario, we revert the eviction > commit. Right now, nobody want to take responsibility. > > I have 2 diffs in pharb that nobody is looking at, because nobody has > time to review them, i have 13 others locally. I will not bother > others maintainer with 15 diff that will switch their mental context > to validate something vintage. > > Note: I didnt event spend much time on the 15 diffs, maybe 1-2h. > Compiler warned about the error, i fixed it, i recompiled, compiler > was happy. then i tested on the hardware. > > Linux purged ARM 32 bit drivers > https://itsfoss.com/news/linux-kernel-old-arm-code-removal/, because > they got hit by people running AI in a loop and no maintainer to > review it. > > > Exactly. There are not many volunteers to actually maintain and > > test the code on old hardware. > > That the point, code without ownership slow down everybody else, we > cannot upgrade because that piece of code still assume 32 bit only. > > > Although, normal DDR2 1 or 2 GiB sticks are rather cheap and can > > also be found on the scrapyard. > > True, but normal laptop have 1-2 slots max and Ubuntu latest require > 6gb min. So if you going to eco mode, you better top up the laptop to > 2x4gb... 8gb to at least open chrome and reply to this message with > 99% memory usage. > > > There is still some x86 hardware around that is in use. The others > > with amd64 capable processors can install amd64. > Still for x86, they can install FreeBSD 15.1+ until one of their > capacitors explode. > > > I have doubt. amd64 is common for 20 years with a few exceptions. > > The power usage often already makes buying a new, small system > > cheaper that keeping the old machine running. > > The number is exaggerated in the upper level, i'm not speaking about > 32 bit hardware worldwide, there are more than 10k. But there is 0% > that we have 10k+ 32-bit only FreeBSD user willing to upgrade to 16 > later and none of them joined this thread or filled a bug in the last > years. So my guess is people that want to have just in case. PS: We > removed support to ARM7 too. > > NOTE: i'm not speaking on behalf of all the team, this is just a > discussion and my personal opinion based on past experiences. I spend > years believing that backward compatibility was a virtue, until i > realized that it was slowing me down. > > --- > Abdelkader Since Abdelkader is speaking with such passion, I want to follow up on this in particular. We stopped supporting 32-bit powerpc as a project with FreeBSD 15, but I still personally maintain a tracking branch on my GitHub (chmeeedalf/freebsd), a `powerpcspe` branch, where I resurrected all the powerpcspe code that was removed after 15 was released, and it still boots and runs on my AmigaOne A1222 board. So I'm running latest (~1-2 months back) FreeBSD 16-CURRENT (pkgbase and all) just fine on hardware that was removed from the tree, so it's not impossible for a sufficiently motivated developer to do the same thing with i386. When the tree moves on sufficiently to irreparably break 32-bit, I plan to continue to maintain some level of parity in my fork as long as I'm motivated for my personal interests. Just because it's no longer supported, and even ripped apart, doesn't mean it's gone for good. Especially in this age of LLMs trained on every conceivable open source project, there is very little in the way of someone passionate enough and motivated enough to do the work on their own, and/or collaborate with other motivated developers. - Justin From nobody Wed Oct 7 17:53:55 2026 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 4j0LNK06M0z4n4S3 for ; Wed, 07 Oct 2026 17:54:09 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 4j0LNJ1TJNz4kgN; Wed, 07 Oct 2026 17:54:08 +0000 (UTC) (envelope-from brett@lariat.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of brett@lariat.net designates 66.62.230.51 as permitted sender) smtp.mailfrom=brett@lariat.net; dmarc=none Received: from Toshi.lariat.net (localhost.lariat.org [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id LAA07832; Wed, 7 Oct 2026 11:53:57 -0600 (MDT) Message-Id: <202610071753.LAA07832@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 07 Oct 2026 11:53:55 -0600 To: John Baldwin , freebsd-arch@FreeBSD.org From: Brett Glass Subject: Re: i386 kernel removal In-Reply-To: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spamd-Bar: / X-Spamd-Result: default: False [0.30 / 15.00]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:6461, ipnet:66.62.230.0/24, country:US]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@FreeBSD.org]; DMARC_NA(0.00)[lariat.net]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4j0LNJ1TJNz4kgN For the record, I'm opposed to removal of i386 support. 32-bit processors are still frequently used in embedded work, and this will cost FreeBSD much of its support from the embedded world. (It will personally cost me the ability to continue to use new versions of FreeBSD on the microservers and microrouters I create for my business.) It will mask bugs that become evident as a result of porting, and drive many folks to embedded Linux distributions. Now that AI assists are available to help with maintaining portability, I see no reason why the platform on which FreeBSD got its start, and hence to which it owes its very existence, should be abandoned. Just my 2 cents. --Brett Glass At 09:06 PM 10/5/2026, John Baldwin wrote: >After some threads on the committers mailing lists a couple of months ago, >srcmgr@ agreed to modify our original schedule for deprecating some >platforms back in 15.0 and to go ahead and remove i386 kernel support from >main. From nobody Wed Oct 7 18:08:03 2026 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 4j0Lhk65b6z4n5t4 for ; Wed, 07 Oct 2026 18:08:22 +0000 (UTC) (envelope-from freebsd-arch-freebsd-org789@ketas.si.pri.ee) Received: from mail.ketas.si.pri.ee (d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13e8:21e:bff:fea2:d004]) (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 4j0Lhj256Rz4mwm for ; Wed, 07 Oct 2026 18:08:20 +0000 (UTC) (envelope-from freebsd-arch-freebsd-org789@ketas.si.pri.ee) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ketas.si.pri.ee header.s=ketas-si-pri-ee-20240416002854-4096 header.b=HfXMBpxx; spf=pass (mx1.freebsd.org: domain of freebsd-arch-freebsd-org789@ketas.si.pri.ee designates 2001:7d0:8437:13e8:21e:bff:fea2:d004 as permitted sender) smtp.mailfrom=freebsd-arch-freebsd-org789@ketas.si.pri.ee; dmarc=pass (policy=reject) header.from=ketas.si.pri.ee X-Clacks-Overhead: GNU Terry Pratchett DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ketas.si.pri.ee; s=ketas-si-pri-ee-20240416002854-4096; t=1791396486; bh=MAhifHfV7Cf26+0goojCjayp9YOrXEWGKTfBadlJQkQ=; h=Date:From:To:Subject:In-Reply-To:References; b=HfXMBpxxaLXFNHOUw4JCCxpRjJbHFM68d7M7wOEsyzEtr5mIg/V+VU3HLqrvZGVGt WWQwf/I8zqz1Ybz05N26YGHHAqt9C1luqOJkLsons2o6UELu1+HYHhkvxmLeFoUWDq ET6P/gsvaKPiCYnZO2ZPX5gU7tFkL5szFFEXCMBMRtJyG0DGbW4U+BWV6xcnel/B6+ NxxX7hL8GdLlY0kxliYoet6haZuz6qDuoAF6631SVU5/grlEgk3Z1VUObUBfHx9Luq Xsus/4HT9ZeTEjDitKo2cVa6PUL0rw9m5Mhtj30YxsiMvjgpjuvt6vBoNGHN+/dCKT SBaSqQYCRMXD8B2Fwtr4cc/zf6Gnb6bEFJYQCl5wLRQAIOCg+RlIr1cTtKlyq0a4lv SMuFQAIK1WK+NHhvZ3ooLcMgkrrqX30d187hC+RAYpkpwESEPfDK5TOQFicGxT0uBg YOKGGV1QsWREMt9yN4e56l4awcKdhjS5XbRyj9W2fQh/auHBEzZrOjpk+ej/VpiGVt A1ZLuOZ7aNvfPyliOGfcthYk9es0bx2o0IZ+EPl1UEsYFzMInBCgbtO4zKNbdqpZ1K 21Tp1LHdsZ32KXs538CsOiO2GOGBdnHvF8Yurr+KvSyfy8SEYF+0WzEozgktXFVX3k p0LfvmWH8Gl6h1A3r8IMI30g= X-Passed-Through: http://ketas.si.pri.ee/ Received: from ehlo.thunderbird.net (0115-0000-0000-0000-13c8-8437-07d0-2001.dyn.estpak.ee [IPv6:2001:7d0:8437:13c8::115]) (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) (No client certificate requested) by mail.ketas.si.pri.ee (MTA) with ESMTPSA id BC69C5DE911 for ; Wed, 07 Oct 2026 21:08:05 +0300 (EEST) Date: Wed, 07 Oct 2026 21:08:03 +0300 From: Sulev-Madis Silber To: freebsd-arch@freebsd.org Subject: Re: i386 kernel removal User-Agent: K-9 Mail for Android In-Reply-To: <20261007114819.59955079@ralga.knownspace> References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> <7700025c-5167-4a05-93c0-3fc1864ef648@app.fastmail.com> <8f49e71d-79eb-469b-9aee-832d82116733@app.fastmail.com> <20261007114819.59955079@ralga.knownspace> Message-ID: 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.20 / 15.00]; HFILTER_HOSTNAME_5(3.00)[d004-fea2-0bff-021e-13e8-8437-07d0-2001.dyn.estpak.ee]; DMARC_POLICY_ALLOW(-0.50)[ketas.si.pri.ee,reject]; R_SPF_ALLOW(-0.20)[+ip6:2001:7d0:8437:1300::/56]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[ketas.si.pri.ee:s=ketas-si-pri-ee-20240416002854-4096]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:3249, ipnet:2001:7d0::/32, country:EE]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DKIM_TRACE(0.00)[ketas.si.pri.ee:+] X-Rspamd-Queue-Id: 4j0Lhj256Rz4mwm now the discussion got really going i see honest reaction, not trolling or anything armv7 is also going? wait, wep is also going (gone!)? what else is going off? what i'm imaging is that when 32bit disappears for good, then, and only th= en, people will appear they aren't me=2E i can take something like c2d 4gb 120g hdd out of trash = and use it=2E this machine has no value, can still have ok caps in psu and = mobo and pass my std 24h memtest86+ run who will complain, likely won't be able to replace some hw=2E i hope mainl= y not because political reasons or cost but physical reasons those now have machines still connected to internet that are now vulnerabl= e=2E i consider them connected even if they run a fw's=2E even if they airg= ap the planet is big, i bet=2E and i hope that fbsd has made it's way into th= ings other than servers, desktops and laptops when armv7 was going, someone made a small noise from a place that runs ar= mv7 bbb=2E that was a place that i hope that that poor nerd didn't yap too = much about=2E (if he was in non-democratic country, he could die)=2E maybe = they have budget to maintain a local fork=2E and never tell us they even ra= n / run it the world is also so weird nowadays that you might not even tell you run c= ritical stuff critical stuff is not granny webbrowsing machine i'd say lets wait what happens after i386 removal i'm also surprised that people in unis don't recognize ata or below 1gb ra= m=2E maybe it was wrong dept=2E i've met nerds that are my unborn child age= d and well aware of world outside of big js and machines running chrome=2E = things can run with 512m with 2/3 ram totally free=2E like free, not even (= fs-)cached in fbsd=2E in 2026=2E that might tempt people to remove that was= ted ram and possibly cry later on upgrading outside of fbsd, support is a strange world too android is now 18 years old=2E what do you think has happened with all tho= se old phones that were made and went out of os or app support in few years= ? large part of them has 64bit hw even=2E they keep working until they die= =2E somewhere, still connected to internet=2E if you ask, you might get rep= lies like wait software updates and security are thing? why? i don't care= =2E or it costs to get new one=2E perhaps with adjoining i don't even have = money for food! i don't know where fbsd on i386 runs but i guess not everybody tells even= =2E not everybody is subscribed to specific ml, even if public just like with governments, people trust that smart people make good decis= ions for them can anybody give a list of what else is planned to be removed from fbsd so= people could maybe prepare to put mental wooden stick between their teeth = as they scream now for support, i get it=2E we also need maintainers here i bet real feedback happens after fbsd without wep and 32bit (=2E=2E=2E an= d) is released remember that feedback to pkgbase came after release=2E people argued that= it was there for 10 years=2E but it didn't get released so it wasn't there= =2E after a actual release ton of feedback came this is similar feedback that neighbours will give when local government a= pproves a building next door=2E people will be accused of not keeping up wi= th local news and only reacting after a backhoe showed up i consider myself watching fbsd quite closely and even i miss some things there's ton of things you only find out if somebody uses them by removing = them if wep is removed and there's no way to get it back, then some people with= they fbsd laptops won't be able to directly connect to wep networks=2E if = they are able to convince owner to turn it to open, we have lost, not won= =2E if no, then no connection and full losing the remover itself might be suffering there, and (s)he's like wait this wa= s me, i'm the reason i'm offline=2E sitting in random cafe on the other sid= e of planet and cursing or maybe entire network is off due it running off oudated fbsd that somebo= dy pwned can't really nudge people off it=2E can't change laws so that hacking obso= lete systems will be legal=2E just like it's not legal to steal even if doo= r can be opened with a nail or there's no door at all same with ssh1, old key exchanges, hashes and ciphers in ssh2, below tls1= =2E3 https servers and so on apparently world is real difficult and can't be nudged into right place by= just telling i saw fbsd supported pc in trash it's like i saw clean drinking water tap on the street and slightly harden= ed bread for free=2E so nobody in this world dies from thirst or starvation there's 8=2E3 billion people in this world after all so yes, i know that for fbsd to live, it needs devs or to lose features=2E= i want it to live but those other things also come up here i'm quite little 32bit user myself=2E on armv7=2E tho i have 32bit i386 to= o=2E but i bet i can survive this so i'm not exactly talking simply out of my ass here on behalf of imaginar= y people i hope to exist funnily enough, some hw was as if built to last=2E they don't blow a cap i= n few years=2E i've seen elcaps physically bulging on lot of newer he first= , than older hw=2E yes i'm ee myself and caps have other failure modes than= this=2E but even i don't test everything, i just replace hw on failure besides is it even possible to fully test a computer? apart from wild gues= s buildworld=2E even if this is a server=2E it won't carry a scope to see i= f power lost it's design filtering, it has mere voltage monitor on board so yeah, so much for old hw i know that you can replace computer every year too if you please=2E real = need for best perf=2E those people are not affected by i386 being gone at a= ll somewhat recent discussion in estonia=2E politican tells how people have t= oo many old cars=2E people telling where's money to buy one? politican is n= ot getting it as he's likely able to use tax (their!) money to lease new ca= rs constantly=2E or even buy maybe unsure if this if fbsd topic anymore but this could explain why one can't = simply do stuff somewhat like people telling me it's very simple to interact with people i bet this mail got weird because this too btw that's the reason i don't work or haven't basically never in 43 years= =2E despite from my knowledge you'd expect that i do anyway=2E=2E=2E From nobody Wed Oct 7 18:46:00 2026 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 4j0MXc6xrrz4n8yr for ; Wed, 07 Oct 2026 18:46:24 +0000 (UTC) (envelope-from seuros@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4j0MXc6QYPz4sZ0; Wed, 07 Oct 2026 18:46:24 +0000 (UTC) (envelope-from seuros@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791398784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fVxdjka63sYJgSkHK+pVH8nrzvY/camBvowBRFZFkwQ=; b=t9a9nW8VhHenliFYhnIRjAMqr9vI1gPwA+XRjvNWlHx2t0YOjyvLGgE8ho0cX8OhgXj6K/ 4X2JvT+x18oCGIRV0kE7dAXfzlMNDESg5iUFr/rPOojqnAPS5E/6bEwiR+urGVmT0cYqxN KTFBxcdGsaWMGtzT0NiGp1gqaOEoZigdN4+1b0fv6FxolDsYM5PS7ob8jJ8Mwak0DgwRi9 k6O0XKAGwTH40acZewN7oN69GtZULciy2BCinpH8Jw+COy6DOzi8KHEkSk9s+6h73uo4jz kYUaOFdP8LxROlmV5tvIg+M/CSbJ2xZFweLh8SAQwviYBBbn4xrTexpO/V9IcA== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791398784; b=GDp9QxZ3nIp+asOqKc0vTf/LeDcvuWe2wAZKy+2aQCavhrsDToTZ22uAW6aqbsmUdx+LJs JmsgcHN5J3rQKjwyxot0HhbDGm6lomnp6wkx87iNU0GVfTOI2txl3Cc7YVg2H5isCI/yzu qMxTxeBB8EVMOU7o6FzfIDHd91U0eFKvEyPCaC18mv8P289fepH6Iybsav+Y+QgK0O3gHL Q1p/GI9PHTy0bnpd11mD7NcKuw0LBZ3KhZbwnXUJB8xx9PhQjD2uSQDql4H0UNaZil5HSb Hr87svQa1NAP192hLtLJ4/6kmgdQtjHxBKr0ULgMo+9wv+xu0PkITb5tlYrurA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791398784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fVxdjka63sYJgSkHK+pVH8nrzvY/camBvowBRFZFkwQ=; b=RxQ1poCBYzRwvsxrFBcFJ/pagIjnHZqtiKu6z/PNDoqur4xL7Iya3cfozZ3WHWbgbfXxVi qdOgriQ4+KCGdY+yRm9jjzMsEk6tmM0C/37BW2La05wJDW7FSotr5VnhBgS+rSgLTiUB6P eWDjWjTcv/h6BYJcdS0uK76pNAd3uIgbXeBhudo+6QU3Y7POaii0tA5Fy76qZ11NPfx6L6 aIiixO1HOrNSe59XixMe34OxsUwfkBaTu9vCvjvwW5wfsVB6W+uKPfsTVvbmbpU+xHJDF6 shaiv1oTTwjkG/Lb0+7RiX/WGgUVIcvSmO17HR7IGDRX1KUmkP/jq3cEcnkC7A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com [103.168.172.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 did not present a certificate) (Authenticated sender: seuros) by smtp.freebsd.org (Postfix) with ESMTPSA id 4j0MXc4rBGznBK; Wed, 07 Oct 2026 18:46:24 +0000 (UTC) (envelope-from seuros@freebsd.org) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfauth.phl.internal (Postfix) with ESMTP id 35756F40068; Wed, 7 Oct 2026 14:46:23 -0400 (EDT) Received: from phl-imap-04 ([10.202.2.82]) by phl-compute-06.internal (MEProxy); Wed, 07 Oct 2026 14:46:23 -0400 X-ME-Sender: X-ME-Proxy-Cause: dmFkZTG1QBHon7LpIRdHOEUUT+lZolCWeZU9Z/N22AEmwKbUUwHOJSHObpoHYpngjmWsQD eXMx+fdHX1o73lPNvqCY/DPAy0SHWRPvVCcKwxncWwc3Jc/yhCgXWmLVHete8NDm9NI1lO vcUwpeC49T5F2tDRbfAgedJnnrQJeQFif4fREhtX3mtoQxXUxAhKUrBt8GgsGtGKVI7txu 9QYi2bloGjCgoQjq2q68USYBHbhYrYVxMxot2yMdrCvGvwklIn0gBFx0JrHyr9sqm2mPoY mQj0yMH8tp86Dio48LKP50bF/iOrSLUddpNNJXmowJpkGm7KEj6cSwG/WgE8fc5TLqbZSC N+pF+vQJs5zsdMvsR4UeQ8iZPVE4oMlRczjT10ewaP/7TOf0ba6y5EqkBh928D4UG4C4k6 KyFl4PKXBRauwZvyM2pn1zgKnQW1VZlKcFtPAGZgo5g516S46E8jeMNz8SQgNszpfyytnh qQwj1MTeH8RB8vNJBFBsoiLEKxgcobWCgh10La5bERfuGtpAS7b0smFe7l9uEFZRvS0IY7 ReDmF79FiKJjnZe4HlftQKcrQAz6yqD4q8xhNvt5PacRVoSiq63Aiwd4omi4pOmNQp8Ba1 dKmPIXrbmuhtC7FMO5MmOZTQbix0ly/cNmWbH1w/rSCP4FP59kzQkLhknO7w X-ME-Proxy: Feedback-ID: i323e4aa8:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 1ACB1B6006E; Wed, 7 Oct 2026 14:46:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-ThreadId: AjEgz-Vs0qfs Date: Wed, 07 Oct 2026 18:46:00 +0000 From: "Abdelkader Boudih" To: "Brett Glass" , "John Baldwin" , freebsd-arch@freebsd.org Message-Id: <7cd95804-a93a-4bc6-8a23-a185cfeef7b3@app.fastmail.com> In-Reply-To: <202610071753.LAA07832@mail.lariat.net> References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <202610071753.LAA07832@mail.lariat.net> Subject: Re: i386 kernel removal Content-Type: multipart/alternative; boundary=ed7001b2653704bafceb438003ab1b3ea845983f --ed7001b2653704bafceb438003ab1b3ea845983f Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Which kind of routers are you building that need 32bit cpu ? I just searched AliExpress for new 32-bit x86 servers and couldnt find a= ny.=20 Alibaba has a few around $400 + H&S, with pretty bad specs and no RAM or= no HDD. At that price, you can buy a modern 6-port 2.5GbE + 2 SFP box f= or around $300. Also I dont really buy the argument that removing i386 will cost FreeBSD= the embedded world. If anything, reducing the amount of architecture-sp= ecific baggage we carry gives maintainers more time to work on hardware = people are actually deploying today.=20 We saw the opposite effect with the laptop project. Better support for m= odern laptops brought new users and contributors. Apple hardware brought= more. Supporting hardware people can actually buy and use gives FreeBSD= exposure too. But I think the bigger issue is this : **Now that AI assists are availab= le to help with maintaining portability (*your words)* AI can assist a maintainer but it cannot test in real hardware. Someone still has to own i386, test it on real hardware, review the gene= rated changes, investigate regressions, and take responsibility when som= ething breaks. If i386 is important enough to your business that its removal prevents y= ou from using future FreeBSD releases, why not maintain it ? That what i= asking for the start. Or fork FreeBSD one commit before i386 is removed, give the fork another= name, and use AI to backport fixes while keeping i386 alive. Justin sho= wed the fork they maintain. There is nothing wrong with that. I have forked FreeBSD three times for = experiments. Matt Dillon forked it two decades ago and created DragonFly= BSD. GhostBSD and other FreeBSD derivatives followed their own paths too= . The BSD license exists exactly so people can do this. And if you are building microrouters, NetBSD and OpenBSD are also option= s with permissive licensing and strong support for smaller systems. Im not trying to push you away from FreeBSD. What bothers me is that you= r message reads like an ultimatum to the people doing the maintenance, w= ithout offering to take responsibility for maintaining i386 yourself. When I badly wanted FireWire to stay, I didnt argue that somebody else s= hould keep maintaining it because I still used it. I learned the subsyst= em and worked on it. Then Adrian bought the cable and camera to test it. That is the question I need to be answered here: **Who is actually volu= nteering to maintain i386 ?** The roster of FreeBSD developers actively maintaining and testing 32-bit= x86 hardware is tiny. But "AI can help maintain it" isn=E2=80=99t a ma= intenance plan unless someone is standing behind the AI-generated code a= nd taking responsibility for it --- Abdelkader On Wed, 7 Oct 2026, at 17:53, Brett Glass wrote: > For the record, I'm opposed to removal of i386 support. 32-bit process= ors > are still frequently used in embedded work, and this will cost FreeBSD= much > of its support from the embedded world. (It will personally cost me the > ability to continue to use new versions of FreeBSD on the microservers > and microrouters I create for my business.) It will mask bugs that bec= ome > evident as a result of porting, and drive many folks to embedded Linux > distributions. >=20 > Now that AI assists are available to help with maintaining portability= , I > see no reason why the platform on which FreeBSD got its start, and hen= ce > to which it owes its very existence, should be abandoned. Just my 2 ce= nts. >=20 > --Brett Glass --ed7001b2653704bafceb438003ab1b3ea845983f Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Which kind of routers are you buil= ding that need 32bit cpu ?

I just searched AliExpress for new 32-bit x86 servers and couldn= t find any.
Alibaba has a few around $400 + H&S, with pretty bad specs and no R= AM or no HDD. At that price, you can buy a modern 6-port 2.5GbE + 2 SFP = box for around $300.

Also I dont really buy the argument that removing i386 will cost FreeB= SD the embedded world. If anything, reducing the amount of architecture-= specific baggage we carry gives maintainers more time to work on hardwar= e people are actually deploying today. 

We saw the opposite effect with the laptop pro= ject. Better support for modern laptops brought new users and contributo= rs. Apple hardware brought more. Supporting hardware people can actually= buy and use gives FreeBSD exposure too.

But I think the bigger issue is this : Now tha= t AI assists are available to help with maintaining portability (you= r words)

AI can= assist a maintainer but it cannot test in real hardware.

Someone still has to own i386, te= st it on real hardware, review the generated changes, investigate regres= sions, and take responsibility when something breaks.
If i386 is important enough to= your business that its removal prevents you from using future FreeBSD r= eleases, why not maintain it ? That what i asking for the start.
Or fork FreeBSD one= commit before i386 is removed, give the fork another name, and use AI t= o backport fixes while keeping i386 alive. Justin showed the fork they m= aintain.
There is n= othing wrong with that. I have forked FreeBSD three times for experiment= s. Matt Dillon forked it two decades ago and created DragonFlyBSD. Ghost= BSD and other FreeBSD derivatives followed their own paths too. The BSD = license exists exactly so people can do this.

And if you are building microrouters, NetBSD = and OpenBSD are also options with permissive licensing and strong suppor= t for smaller systems.

Im not trying to push you away from FreeBSD. What bothers me is that= your message reads like an ultimatum to the people doing the maintenanc= e, without offering to take responsibility for maintaining i386 yourself= .
When I bad= ly wanted FireWire to stay, I didnt argue that somebody else should keep= maintaining it because I still used it. I learned the subsystem and wor= ked on it. Then Adrian bought the cable and camera to test it.

That is the question I need to= be answered  here: Who is actually volunteering to maintain = i386 ?

The = roster of FreeBSD developers actively maintaining and testing 32-bit x86= hardware is tiny.  But "AI can help maintain it" isn=E2=80=99t a m= aintenance plan unless someone is standing behind the AI-generated code = and taking responsibility for it

---
Abdelkader



O= n Wed, 7 Oct 2026, at 17:53, Brett Glass wrote:
For the record, I'm opposed to removal = of i386 support. 32-bit processors
are still frequently used i= n embedded work, and this will cost FreeBSD much
of its suppor= t from the embedded world. (It will personally cost me the
abi= lity to continue to use new versions of  FreeBSD on the microserver= s
and microrouters I create for my business.) It will mask bug= s that become
evident as a result of porting, and drive many f= olks to embedded Linux
distributions.

Now that AI assists are available to help with maintaining portability,= I
see no reason why the platform on which FreeBSD got its sta= rt, and hence
to which it owes its very existence, should be a= bandoned. Just my 2 cents.

--Brett Glass
--ed7001b2653704bafceb438003ab1b3ea845983f-- From nobody Wed Oct 7 19:27:51 2026 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 4j0NSq6mRCz4nD5W for ; Wed, 07 Oct 2026 19:28:11 +0000 (UTC) (envelope-from seuros@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 "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4j0NSq69Ljz4wP0 for ; Wed, 07 Oct 2026 19:28:11 +0000 (UTC) (envelope-from seuros@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791401291; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Jr8VsjNwE3wqrkqfzthhCvFleBtVXnCk2Wp3iae3R5Y=; b=wMTUXgxdwH/XGxCWwji+v7C4FoUNza42oFvzMjQ6Mp6YiveA+8nwWbVah+UnCuL+rtHlPg n8XoGxPbRPyb+j+Pp5hT+PEKnVaZPD49uOhtVYya+W+4sPLKjUpzJEZu0ZhYkVBi+74zCb Y9/Yol/HWIkmuSHUG/Dg7kWII+muiKrtBN6trJEUwoZVw5d3TC7TIjrNhqCSJMO8xpvEt3 ntiIt+jRxDI6ElTCZ2OGa0BbLckZMQmDP2ZqhBBuTuKg2dr3WR5FtUsb3cnzhw90rb68Ny pWPX40IrZvJLi/6bf7xFqEcjyV5tZWqkuFYmDHKa0E6EO479xwjqnrmnurGq7Q== ARC-Seal: i=1; a=rsa-sha256; d=freebsd.org; s=dkim; cv=none; t=1791401291; b=PPMtCAZR1kTUmlP9huS84v9RGbLDYtIO978Jsu6yCn/GLESyObnTdyITscq1I6fn9qCtIh RNLIxx9o4LC7gYo/shVHIoLK3fRsqcXqunQckUo5k9wedUytoirTdbEUnl/OsjIvTbu/lL W0WsCpxS34Y3jo5HIy1eUAYNGwUydxUp4I4h5SVqdapGS/Aq+vTFtTqO4eXn8V9CD8qO4y 2ioFbT2NlMIstaBnSFsuzMtpJr5rhMvwdO+4NxNL05ycfd7h+ekFEk+tWtAfpy5gSQYc2Q F5lpzS5WF/7r7igQWJW8v9wDdjP0m0sytp3ggFo/doX+xEHIXz2P1o25hFKUrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1791401291; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Jr8VsjNwE3wqrkqfzthhCvFleBtVXnCk2Wp3iae3R5Y=; b=V0upawV/CGUpOfbJnMaEK0lDM9cSAxeS+AK/yOeqhyYdQF1O6JsP4G3wF3sMAu2DYQ6Tmt exVSTF/BNJbAWs1XgPWO4koExkqoaXbpIgd9tvJ07ZpQi0msDuOpXO3UvfCrX14mEid1X3 SbRHTLDT4kJH9nQPI9amcA/m4Qhi6VHUgCc6+Qqw6rd9CDF9AawqUbXDXG16AxLSTaG5ZP QTn2F4zENnZna1nnq1xKxigRBfp9GEeVoT+Zw2VX8gN5EB7HdLfJSG2mAOKuMFkV219XKk ik8NcBn4oBMThf9VssUwDLQ5Z8U7ea74fEA3kLxyQUr0bfYwkm/2OcRpZjrpNA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com [103.168.172.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 did not present a certificate) (Authenticated sender: seuros) by smtp.freebsd.org (Postfix) with ESMTPSA id 4j0NSq56JNznYF for ; Wed, 07 Oct 2026 19:28:11 +0000 (UTC) (envelope-from seuros@FreeBSD.org) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfauth.phl.internal (Postfix) with ESMTP id 7C4BBF40068 for ; Wed, 7 Oct 2026 15:28:11 -0400 (EDT) Received: from phl-imap-04 ([10.202.2.82]) by phl-compute-06.internal (MEProxy); Wed, 07 Oct 2026 15:28:11 -0400 X-ME-Sender: X-ME-Proxy-Cause: dmFkZTEFW8nqrboRhpI1JcHOt62X4N33X9syJuw5AngvDh8w7PKhw1kMd/f9GNzC/nI+7G KM3RKsFK4ky96XtF3c3C9GxLbgcgOJsrDHzFxoPv7U7s21etUiZJgWaxMvVlPVCWN7HaFp gBrBvq2ZeN4phsCLGLhgvR2f6nTMV1R3PN1dDmC9dTypKpS60pTPVnB69231sJf0aoK0zY M/jgHl/QBWfUepf5Vf5lJqBbyL2SxlIZYhp/9Scpk4ZBi6D3apTXDJQgPE61A0BaqOyufh jhpUaUYX7PLq209oCfLXBLIneZ9ONj1yfWIiR8CX7eZFMa7EoxScSIb/P3BA28LVOsyoas dAutfOVCx15d2BYhVRUxCI9fkGa5BWdBbQucn5vNGssgMhecftz6mlte7dCRR+kJ+EH27Z g8MqcPBqkk7GzEJhif2LKPADMsd1H3JNn+FbTrBWn65roWLc5WeJ3ra1R49NUtphlx77Dg i3qYxvhV10kS3+uHDEhYJPZWcblbqMrbA8soL19pxTnGvaUwXbnPZD2NThdgiX6TZUXtWo UCTx1kipex1zKKO2puRh3re2BF4Ba+kDmrcFeZrttFLkwhzGfPB96OtpvZzeIlPgp9vI4o JLZo+X8ZQsI7x/50N2zQxW+aTmx/AZqLVhNjSeImFkOhCbu8940IIaqVNoXQ X-ME-Proxy: Feedback-ID: i323e4aa8:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 64B73B6006F; Wed, 7 Oct 2026 15:28:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-ThreadId: AjEgz-Vs0qfs Date: Wed, 07 Oct 2026 19:27:51 +0000 From: "Abdelkader Boudih" To: freebsd-arch@FreeBSD.org Message-Id: In-Reply-To: References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <20261006110755.0ff20e9e@nuclight.lan> <1D847C61-E58F-4C15-ADF7-113F6F41638A@freebsd.org> <864iez82sg.fsf@drag0n-laptop.lair.internal> <7700025c-5167-4a05-93c0-3fc1864ef648@app.fastmail.com> <8f49e71d-79eb-469b-9aee-832d82116733@app.fastmail.com> <20261007114819.59955079@ralga.knownspace> Subject: Re: i386 kernel removal Content-Type: multipart/alternative; boundary=3cea437651fe6e2adecc68cccf66d762d503f400 --3cea437651fe6e2adecc68cccf66d762d503f400 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Sulev, My bad, what got removed was armv6 (Raspberry Pi Zero 1). armv7 is still= in tree for now. I saw Adrian cleaning up WEP, but I=E2=80=99m not sure if it was moved s= omewhere or totally wiped. Anyway, WEP is insecure. You are better off h= aving an OPEN network while you are at it. > the planet is big, i bet. and i hope that fbsd has made it=E2=80=99s w= ay into things other than servers, desktops and laptops That's the goal, but currently we still have pretty bad UX. > im also surprised that people in unis don=E2=80=99t recognize ata or b= elow 1gb ram. maybe it was wrong dept. i=E2=80=99ve met nerds that are m= y unborn child aged and well aware of world outside of big js and machin= es running chrome. things can run with 512m with 2/3 ram totally free. l= ike free, not even (fs-)cached in fbsd. in 2026. that might tempt people= to remove that wasted ram and possibly cry later on upgrading Those were not graduates. First year students, and their brains automati= cally autocorrect MB to GB. You can go on eBay and find plenty of sellers who mistake a 64 MB SD car= d for 64 GB. Not even a scam, they remove the unit when I message them. = :D > android is now 18 years old. what do you think has happened with all t= hose old phones that were made and went out of os or app support in few = years? large part of them has 64bit hw even. they keep working until the= y die. somewhere, still connected to internet. if you ask, you might get= replies like wait software updates and security are thing? why? i don=E2= =80=99t care. or it costs to get new one. perhaps with adjoining i don=E2= =80=99t even have money for food! >=20 Android is even weirder. Some vendors, like Samsung, fuse the version in= to the silicon, so you cant upgrade it. Nura is trying to support those devices. https://nura.eco > can anybody give a list of what else is planned to be removed from fbs= d so people could maybe prepare to put mental wooden stick between their= teeth as they scream I think most of them have their man pages updated with a removal notice. > if wep is removed and there=E2=80=99s no way to get it back, then some= people with they fbsd laptops won=E2=80=99t be able to directly connect= to wep networks. if they are able to convince owner to turn it to open,= we have lost, not won. if no, then no connection and full losing WEP has been insecure for years with no fix. Every other OS screams at y= ou when you connect to WEP. Modern macOS treats WEP as insecure PS: I will address the rest of your email later. I=E2=80=99m just sendin= g this now to correct the armv7 info. --- Abdelkader --3cea437651fe6e2adecc68cccf66d762d503f400 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Sulev,

My bad, what got removed was a= rmv6 (Raspberry Pi Zero 1). armv7 is still in tree for now.

I saw Adrian cleaning up WEP, b= ut I=E2=80=99m not sure if it was moved somewhere or totally wiped. Anyw= ay, WEP is insecure. You are better off having an OPEN network while you= are at it.
=
the planet is big, i bet. and i hope that fbsd has ma= de it=E2=80=99s way into things other than servers, desktops and laptops=
That's the goal, but currently we still have pretty bad UX.
<= div class=3D"align-start" style=3D"text-align:start;">
im also surprised that people in unis don=E2=80=99t recognize ata or be= low 1gb ram. maybe it was wrong dept. i=E2=80=99ve met nerds that are my= unborn child aged and well aware of world outside of big js and machine= s running chrome. things can run with 512m with 2/3 ram totally free. li= ke free, not even (fs-)cached in fbsd. in 2026. that might tempt people = to remove that wasted ram and possibly cry later on upgrading

Those were not g= raduates. First year students, and their brains automatically autocorrec= t MB to GB.
=
You can= go on eBay and find plenty of sellers who mistake a 64 MB SD card for 6= 4 GB. Not even a scam, they remove the unit when I message them. :D

android is now 18 years old. what do you think has happened with all = those old phones that were made and went out of os or app support in few= years? large part of them has 64bit hw even. they keep working until th= ey die. somewhere, still connected to internet. if you ask, you might ge= t replies like wait software updates and security are thing? why? i don=E2= =80=99t care. or it costs to get new one. perhaps with adjoining i don=E2= =80=99t even have money for food!

Android is even weirder. Some vendors, like Sa= msung, fuse the version into the silicon, so you cant upgrade it.
<= div class=3D"align-start" style=3D"text-align:start;">
Nura is trying to support= those devices. https://nura.eco<= br>

can anybody give a list of what else is planned to be removed= from fbsd so people could maybe prepare to put mental wooden stick betw= een their teeth as they scream

I think most of them have their man pages updat= ed with a removal notice.

if wep is removed and there=E2=80=99s n= o way to get it back, then some people with they fbsd laptops won=E2=80=99= t be able to directly connect to wep networks. if they are able to convi= nce owner to turn it to open, we have lost, not won. if no, then no conn= ection and full losing
WEP has been insecure for years with no fix.= Every other OS screams at you when you connect to WEP. Modern macO= S treats WEP as insecure

PS: I will address the rest of your email later. I=E2=80=99m j= ust sending this now to correct the armv7 info.

---
Abdelkader
--3cea437651fe6e2adecc68cccf66d762d503f400-- From nobody Wed Oct 7 19:33:44 2026 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 4j0NbV2YpTz4nDcR for ; Wed, 07 Oct 2026 19:33:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4j0NbT4TBlz4wv5 for ; Wed, 07 Oct 2026 19:33:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; arc=pass ("google.com:s=arc-20260327:i=1"); spf=pass (mx1.freebsd.org: domain of adrian.chadd@gmail.com designates 209.85.222.181 as permitted sender) smtp.mailfrom=adrian.chadd@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none) Received: by mail-qk1-f181.google.com with SMTP id af79cd13be357-93e56c287b3so358214285a.0 for ; Wed, 07 Oct 2026 12:33:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1791401637; cv=none; d=google.com; s=arc-20260327; b=LvtBqIQGHgAJDhg+7GFoxYQfzu/VKL6ZHrnBEsIlBPD8KXvYa5XWvjwCtns0HiJgZT IHCOZLZsRfqQikiO1emXCqPWYoA9jDd8gckxDVAPNRDMsmEtrDRJU0iNdLHcm0EGJ3J9 MQTiQGP4TFj9tdnHVaqxYz57hjavLBZk+C8B99TF/Z46LgavlujV7dNC938C5Iv3p1vT ZTpUcGK9AWQlmioOCeix1IwCTz2qBGltKo6/5SOSACwENs+3qGMyEiPEbC2sjicjs9i6 +d3nMt+BKKtnHKgMl1XC+nlsPm80aHTOVRhsJSh3YFlB3Arq2aBuEMXlmzlKftNPeuLM kIKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version; bh=O0dJn1XqFkfBzHFRpQuXdcTZK1c6Bfu1qLuYQEZvtA8=; fh=xqpMFKEMpBHs3L0AaS3lpceIYs0whn//5vGzYjyUyoQ=; b=PYlj3jVzUqhvWyqjNnMPfBB93LnJL4+VyzPQEoYILvEOJjY8IryllXNPifUw9tb6os xQtKdshFAVUEy7KdSiR0Br99+tF6ToqXibG5gcumf3Y1Jo6RRVZAL+T6UAaKWiTRUsk2 /7iVTHEDFa7mP0CGc0IeGVy4x6AeNzPDV9LYajyj21z+ijZT64Xp+V3+Q0nZ0tzbUFu/ FiGfIC5KINyH0jJet+8xf+LxgEK8F0dR73sGlZEuULIg3tzKuBChXnDMXz7n9KBYp+XU E2w9cPeQkDWk11zpqwAVuUJ9K3fdm00kl99Y15XxDAmvwXvCLjxUO2yMkfx//kxMdAjr P2Pg==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791401637; x=1792006437; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=O0dJn1XqFkfBzHFRpQuXdcTZK1c6Bfu1qLuYQEZvtA8=; b=MiZVcUhpnsleejANLc8QkcCtD2V4UwMWuxHSTzrMOG4ae8UWO0cpyDJRkNz15Rj+OF zch60TnFNkONZ9AOUNDo/m0eaR0en3iUguROyMHfnwUxsr7Zgrdk6iTOnLSiBmBhMOW1 BqOiHgZAYJtX1tEpD9iiZojvrA23GmXh5pcpbFMuQemBPG75xdXHTOTygEq46iFHTVZN f3snlcPjsbpCovS0S79ks/r1m+XAQXuxMo30SICLNeL6KKBh7e+8OTcMmkA0aQX4WRJt T49ZwWYRP91biECSGJ6SRgpKpU92WA59MeSHCuqRyduzAD7b5FuSKRgYPEL+xAiJw26F lZcw== X-Forwarded-Encrypted: i=1; AKwUvBz5a0ONMU+tgu1s5xibBo1qGOZD5IA5WtTB8axr1v+1J4t7uBPZuF0FheZl29kV9LPPM38Qz/92wGGUTrs=@freebsd.org X-Gm-Message-State: AFuF++m5GTbOYWXG+1Aejlczn/eexlvNYCuRcKFKES0dF3Fc4524o/SO qA+OR4xHo8onTyqstK2v4UIqGy1RRsjPEBK85dHadQbSnf8JvGLvLqeBEgdJYeLaIDbMqqw6ha5 KW5zzuK+gUQ9JdBriMNPLkSZ69mXHCPbexFRO X-Gm-Gg: AYBFou3i/eHISrwJu5l+Q0F5BgRLghLOiEPvF9/CjqICtSeBVtvgKDjxPYJ2R7CUkIS jSOid67ms5Su2LBNJBgxW0kjI3uWboygcTY6pS3OY4fhTrGT0JoIe36SGmOF4ihinKoQOyuM1d9 etLjEe+yDrChBKs8H2Tzyowm86NUY2kMUyai2+zVnnpzcM/S3zWQnlg1vvMCR+mKhvU0qvqAD3V Il2HkfoUQ/F8XJ1OyBFqGCaug12UDSe/fUOcNj4k8zK4ezjYNa13UNYnEdrRnmaOT0P3XaqgKQ1 EmI1yYi5sjb7D9sJHmleKNm2aqnPNdd29xCyVLzRSJNgKQgGs77D004HTRHmGjPjWkYNuPYRm1R xsHMyTa8st5nGDoPMwq6KN2yadPg+OAknrNjMC8dxqOZGIT0smt8cTSBhgjV//rBOd9gnxjJ/jw 9n+c5/6m20X/QOmtB0oa0+S41x0RZDWkY9yV9roGAd21+dpUGu9pyhE+PU3GdZj8QFgAPHDQtTE OwjInQijO+FIS4= X-Received: by 2002:a05:620a:1d07:b0:93e:9aaa:45c with SMTP id af79cd13be357-93e9b2ea963mr661943385a.6.1791401636424; Wed, 07 Oct 2026 12:33:56 -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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 References: <4bd34688-a09d-4816-b1f7-c7f7d80c113c@FreeBSD.org> <202610071753.LAA07832@mail.lariat.net> <7cd95804-a93a-4bc6-8a23-a185cfeef7b3@app.fastmail.com> In-Reply-To: <7cd95804-a93a-4bc6-8a23-a185cfeef7b3@app.fastmail.com> From: Adrian Chadd Date: Wed, 7 Oct 2026 12:33:44 -0700 X-Gm-Features: AclHuK_iwM8Y-SBAvdJsl00sFO3Q0XrAJHDCeJfvCyntdu-RhACMMhFLcLUPq4k Message-ID: Subject: Re: i386 kernel removal To: Abdelkader Boudih Cc: Brett Glass , John Baldwin , freebsd-arch@freebsd.org Content-Type: multipart/alternative; boundary="000000000000307258065d4532b4" X-Spamd-Bar: / X-Spamd-Result: default: False [-0.90 / 15.00]; ARC_ALLOW(-1.00)[google.com:s=arc-20260327:i=1]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.181:from]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; ALIAS_RESOLVED(0.00)[]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.181:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4j0NbT4TBlz4wv5 --000000000000307258065d4532b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable hi! On Wed, 7 Oct 2026 at 11:46, Abdelkader Boudih wrote: > Which kind of routers are you building that need 32bit cpu ? > > There's a lot of really old, environmentally hardened stuff out there which is likely still 32 bit. However, since it is old stuff, it's also hopefully being priced and sold at a rate which matches how much it costs to keep it going. > That is the question I need to be answered here: *Who is actually > volunteering to maintain i386 ?* > > The roster of FreeBSD developers actively maintaining and testing 32-bit > x86 hardware is tiny. But "AI can help maintain it" isn=E2=80=99t a main= tenance > plan unless someone is standing behind the AI-generated code and taking > responsibility for it > > So this is always the thing. I'm sad to see 32 bit support go because I think it keeps a bunch of design decisions honest (people can and do get, I want to nicely say "very lazy" when infinite sparse VM space is available) but we also have to understand that keeping it around when it's adding an increasing cost to things is .. well, it's an increasing cost. > On Wed, 7 Oct 2026, at 17:53, Brett Glass wrote: > > For the record, I'm opposed to removal of i386 support. 32-bit processors > are still frequently used in embedded work, and this will cost FreeBSD mu= ch > of its support from the embedded world. (It will personally cost me the > ability to continue to use new versions of FreeBSD on the microservers > and microrouters I create for my business.) It will mask bugs that become > evident as a result of porting, and drive many folks to embedded Linux > distributions. > > Brett - you, like any other vendor, are very encouraged and welcome to engage with the project and foundation in a proactive way. I and others would like to keep pushing the boundaries of what we can do, but it's not free. If you're a vendor, and you have a requirement for 32 bit intel support, then please reach out. > Now that AI assists are available to help with maintaining portability, I > see no reason why the platform on which FreeBSD got its start, and hence > to which it owes its very existence, should be abandoned. Just my 2 cents= . > > But it's not zero cost. Part of that equation has to be contributing developer time or money. AI may make knocking something together easier, but it doesn't immediately solve the architecture problems, nor the collaboration problems, nor does i= t make life easier for other people. As far as I'm aware, all the statistics and feedback that srcmgr and the foundation have point to i386 base not being used anymore. (I believe it's from user surveys, downloaded releases, and package fetching/updating.) If there's interest in maintaining it, you don't have to convince me - you need to convince srcmgr, and back it up with developers or money to pay developers to keep it alive. Otherwise - I highly encourage i386 users to move to NetBSD. Which I have for a couple of i386 atom laptops, and I'm slowly figuring out what bugs are there which need fixing. But again, if you're needing i386 support for products and you shift to NetBSD, I highly encourage you to also participate in that community and provide money / developer resources. -adrian --000000000000307258065d4532b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi!

On Wed, 7 Oct 20= 26 at 11:46, Abdelkader Boudih <se= uros@freebsd.org> wrote:
Which kind of r= outers are you building that need 32bit cpu ?


There's a lot = of really old, environmentally hardened stuff out there which is likely sti= ll
32 bit.

However, since it is old stuf= f, it's also hopefully being priced and sold at a rate which
= matches how much it costs to keep it going.
=C2=A0
That is the question I need to be = answered =C2=A0here: Who is actually volunteering to maintain i386 ?<= /i>

The roster of FreeBSD developers actively maintaining and testi= ng 32-bit x86 hardware is tiny.=C2=A0 But "AI can help maintain it&quo= t; isn=E2=80=99t a maintenance plan unless someone is standing behind the A= I-generated code and taking responsibility for it


So this is alw= ays the thing. I'm sad to see 32 bit support go because I think it keep= s
a bunch of design decisions honest (people can and do get, I wa= nt to nicely say
"very lazy" when infinite sparse VM sp= ace is available) but we also have to
understand that keeping it = around when it's adding an increasing cost to things
is .. we= ll, it's an increasing cost.
=C2=A0
On Wed, 7 Oct 2026, at 17:53, Brett Glass wrote:
For the record, I'm oppo= sed to removal of i386 support. 32-bit processors
are still frequ= ently used in embedded work, and this will cost FreeBSD much
of i= ts support from the embedded world. (It will personally cost me the
ability to continue to use new versions of=C2=A0 FreeBSD on the microser= vers
and microrouters I create for my business.) It will mask bug= s that become
evident as a result of porting, and drive many folk= s to embedded Linux
distributions.

Brett - you, like any other vendor, are very enc= ouraged and welcome to engage with the
project and foundation in = a proactive way. I and others would like to keep pushing
the boun= daries of what we can do, but it's not free. If you're a vendor, an= d you have
a requirement for 32 bit intel support, then please re= ach out.
Now tha= t AI assists are available to help with maintaining portability, I
see no reason why the platform on which FreeBSD got its start, and hence<= /div>
to which it owes its very existence, should be abandoned. Just my= 2 cents.


But it's not zero cost. Part of that equation has to be contributing d= eveloper time or
money. AI may make knocking something together e= asier, but it doesn't immediately
solve the architecture prob= lems, nor the collaboration problems, nor does it
make life easie= r for other people.

As far as I'm aware,= all the statistics and feedback that srcmgr and the foundation
h= ave point to i386 base not being used anymore. (I believe it's from use= r surveys,
downloaded releases, and package fetching/updating.)

If there's interest in maintaining it, you don&= #39;t have to convince me - you need to
convince srcmgr, and back= it up with developers or money to pay developers
to keep it aliv= e.

Otherwise - I highly encourage i386 users to mo= ve to NetBSD. Which I have for
a couple of i386 atom laptops, and= I'm slowly figuring out what bugs are there
which need fixin= g. But again, if you're needing i386 support for products
and= you shift to NetBSD, I highly encourage you to also participate in that
community and provide money / developer resources.



-adrian

--000000000000307258065d4532b4--