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.