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

On Sat, Jun 21, 2025 at 06:39:03PM -0700, Rodney W. Grimes wrote:
> > On Sat, 21 Jun 2025 08:36:28 +0900
> > Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
> > 
> > > On Sat, 21 Jun 2025 01:15:58 +0300
> > > Vadim Goncharov <vadimnuclight@gmail.com> 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 ?  
> > > 
> > > My understanding is, unfortunately, yes.
> > > IIUC, VM images are "pre-installed" environment with virtual disk
> > > format that the VM recognizes and pre-installed, if any, drivers to
> > > support emulated virtual hardwares.
> > > 
> > > You can still use 32bit binaries on 64bit builds of VMs, but
> > > it would require lib32 to be installed.
> > > 
> > > Correct me if I'm misunderstanding.
> >  
> > If "yes" then why "unfortunately" ? Continuing to support 32 bits where it
> > makes sense is very fortunate thing, both for cheaper prices and energy saving
> > thus our planet!
> 
> IMHO, it is a mistake for FreeBSD to remove the 32 bit bare metal build
> before Intel/AMD removes this support from the bare metal.  As long as
> shipping CPU chips from both AMD and Intel support 32 bit bare metal
> boots, and VM's it makes since for this feature to be availiable.
> 
> As one person here has pointed out the savings in VM sizes alone
> is valuable.
> 
> Also some one explain where the build of 32bit binaries would come from
> if the 32bit build of FreeBSD goes away?  That has me rather confused,
> other than possibly to run legacy things, but that interface is likely
> to get broken quickly once the 32 bit builds are gone.
> 
> Or is it expected that we can continue to build a 32 bit user land
> from /usr/src and run that on the 64 bit kernel and that this shall
> be a fully supported configuration?

The i386 world on amd64 kernel is the supported configuration, and I
will put the efforts to keep this going.  Simultaneously, there is not
much value in the full world for i386, lib32 + cc -m32 is the most
interesting thing for me and perhaps, practically, for all other people
who really use 32bit (as opposed to use it for flaming on ml).

Right now I do maintain amd64 kernel ABIs for both 32bit ELFs and a.out.
I would object strongly against removing that, but so far nobody seriosly
proposed that.

Also I thought about working on extending time_t into 64bit for i386.
I think it might be done more clever than just introducing i386 2.0
(which is indeed not too useful), but there I met some resistance.

i386 is needed to run old binaries or code that has the assumption
about ILP32, and for some time it was also benefitial for apps which
have very high pointer traffic and fit into 4G.  The later becomes
less useful with newer CPUs, which cleaned out some outstanding problems
in microarchiterctures.  For instance, REX prefix caused +1 cycle in
decoding not too long ago, etc.  Now it is all fixed.

So the main purpose of i386 left is to run binaries, and there lib32
is enough or should be fixed to be enough.  I could want portmgr@ still
providing the binary packages for i386, even if once in quarter, but I
also might want a pony.

The Intel initiative to remove ability to boot i386 on bare metal,
X86s, seems to stall.  I am not even sure if they finally removed
CMS on latest generations of machines.  But there are machines already
that lack working 8254 timer.