Re: Deprecation of i386 and 32-bit powerpc for 15.0

On Sat, Jun 21, 2025 at 10:09 AM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Sat, Jun 21, 2025 at 7:54 AM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
> >
> > On Sat, 21 Jun 2025 16:48:10 +0300
> > Vadim Goncharov <vadimnuclight@gmail.com> wrote:
> >
> > > On Sat, 21 Jun 2025 02:58:59 +0000
> > > Colin Percival <cperciva@tarsnap.com> wrote:
> > >
> > > > On 6/20/25 15:15, Vadim Goncharov wrote:
> > > > > On Sat, 21 Jun 2025 04:09:29 +0900
> > > > > Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
> > > > >
> > > > >>>>> - ~6 months after branching (BSDCan 2026 devsummit):
> > > > >>>>>
> > > > >>>>>     - evaluate how stable/14 has been fairing (are MFCs breaking
> > > > >>>>>       deprecated platforms) (note that stable/13 will be EOL at this
> > > > >>>>>       point)
> > > > >>>>>
> > > > >>>>>       - if all is smooth, start removing code from main for i386 and
> > > > >>>>>         powerpc kernels as well as any powerpc userspace code not
> > > > >>>>>         required for lib32
> > > > >>>>
> > > > >>>> When can we expect lib32 removal?
> > > > >>> Hopefully never.
> > > > >>
> > > > >> Maybe this could puzzle more persons.
> > > > >>
> > > > >> IIUC, lib32 is for running 32bit apps on 64bit platform, which is NOT
> > > > >> planned for removal.
> > > > >>
> > > > >> What is going to be deprecated is 32bit bare-metal hardwares supports
> > > > >> for i386 and 32bit PowerPC, which never runs on 64bit modes.
> > > > >
> > > > > Does that mean that support for 32-bit builds for virtual machines (that's
> > > > > important because they use less memory -> buy cheaper, especially when
> > > > > lots of them) will be continued after 2030 ?
> > > >
> > > > If by "virtual machine" you mean bhyve/qemu/KVM/virtualbox/etc then no, that
> > > > will not be possible in 15.x and later because a full virtual machine needs
> > > > to run a FreeBSD kernel, and there will be no FreeBSD/i386 kernel for 15.x
> > > > and later.
> > > >
> > > > If by "virtual machine" you mean containers, that will still be possible.
> > >
> > > Of course I mean real virtual machine e.g. running in a cloud. The same code
> > > compiled for 32 bits consumes less memory than for 64 bits (int and ptr size).
> > > So for 100 VMs in a cloud 1 GB RAM each vs 100 VMs in a cloud 2 GB RAM you
> > > have a significant cost difference (lib32 is only partial solution here, as
> > > you also have system daemons and kernel).

The counter to this is it doesn't matter if basic functionality like
time can't work beyond 2038. Our i386 port has ABI issues that makes
it impossible to have a 64-bit time_t. The number of system calls that
need to change is crazy. Having a 64-bit time_t is possible with a
whole new ABI, but there's half a dozen places in i386 specific code
that know time_t is 4 bytes and externalize it as such that would need
to be fixed. It's a lot of work for almost no benefit...

> > So you really need to look for anyone (maybe multiple) who promises
> > to maintain i386 part of src tree continuously AND really want to be (a)
> > committer(s) of FreeBSD src repo, which (AFAIK) FreeBSD project cannot
> > find (thus, deprecated).
> Just a data point here. I downloaded/installed a snapshot on my ancient
> i386 laptop and it went without a hitch (I didn't try to set up X or a desktop).
> Why?
> Because I knew to avoid ZFS.
>d> There was a recent discussion about broken MBR ZFS installs for 14.n
> and I'm not sure how that got resolved.

Yes. You basically never want to do that for new installs (unless
you're forced into by a BIOS that won't boot GPT). Bootable ZFS over
MBR is a crazy, rube-goldberg situation at the moment that's fragile
at best, and cranky at worst (you basically can never zpool upgrade
since you also have to update the boot blocks which is thinly
documented (even by the standards of the boot loader) and requires an
error-prone dd command.

> My point is..fixing that wasn't in anyone's wheelhouse, so who's going to
> fix other things?

Yea. That's a big problem. We've known about them for years, and many
just aren't there in 64-bit land (especially EFI 64-bit land).

Warner

> I suspect that most of what is in ports still builds because Debian still
> does 32bit distros. When they stop doing that, I suspect 32bit builds
> of port stuff will bitrot rapidly?
>
> Although I still have the old hardware, I don't have a problem with
> John's schedule (although I think it might be nice to still build snapshots
> until the FreeBSD15 release is done). That would give anyone who wants
> it an unsupported install, given this is only a few months away?
>
> rick
>
> >
> > If no volunteers pops in, you need to hire developers who really can
> > maintain whole bunch of i386 part of src tree. But it would be far more
> > expensive than upgrading all your VMs to amd64, as the developers
> > would need to be full time work (my quite wild prediction, though).
> > The developer needs to watch ALL commits to src tree, check if it
> > affects i386, and if affects, fix i386 part and request for review
> > as differential revisions here
> >
> >   https://reviews.freebsd.org/
> >
> > at least until the developers get commit bit for src tree.
> >
> >   https://docs.freebsd.org/en/articles/committers-guide/
> >
> > Note that I'm not a committer.
> > So if I want something I modified to be committed, I need to request
> > review, and once accepted by reviewers (not needed to be committers),
> > ask any of committers to commit it.
> >
> > I'm assuming none of the committers can promise continuous work for
> > i386 so also assuming the developer(s) you find (regardless volunteers
> > or hired by yourself) is/are not (a) committer(s).
> >
> > > --
> > > WBR, @nuclight
> >
> >
> > --
> > Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>
> >
>