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

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).

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).

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>