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

Rodney W. Grimes <freebsd-rwg_at_gndrsh.dnsmgr.net> wrote on
Date: Sun, 22 Jun 2025 01:39:03 UTC :

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

(My focus below is more narrow than spanning the above.)

> As one person here has pointed out the savings in VM sizes alone
> is valuable.

(My focus below is more narrow than spanning the above.)

> Also some one explain where the build of 32bit binaries would come from
> if the 32bit build of FreeBSD goes away?

No i386 32-bit kernel is needed to have and use a i386 world via
chroot or via a jail. For now, ignore lib32: it is not needed
for that chroot or jail use of an i386 world.

So there not just one type of "32bit build of FreeBSD". I try
to be explicit in more detail about that below.

) FreeBSD cross builds i386 worlds just fine via the toolchain
  (unless such is deliberately disabled). The builder does not
  need to be i386 --or even amd64. Being little-endian can be
  handy for file system compatibility issues and such.)

) The FreeBSD i386 system builders are an example of cross
  building i386 on amd64. (amd64 builds all the official
  system builds, as far I know, not just Intel/AMD ones.)

) Such a build can be installed into a directory tree usable on
  amd64 hardware that also supports i386. The 64-bit kernel
  supports this without involving the i386 32-bit kernel.

) The FreeBSD port-package build servers for i386 are an example
  of using poudriere jails that are i386 worlds, no 32-bit
  kernel involved. (I did the analogous activity for armv7 on
  aarch64 long before there was a lib32 context implemented for
  aarch64, for example.)

) This is clearly not the same as supporting hardware that is
  limited to 32-bit via having a 32-bit kernel involved. But
  it is one form of having a "32bit build of FreeBSD" in use.

There is a big distinction here between keeping just the 32-bit
world for chroot/jail use from being broken when used with the
64-bit kernel vs. keeping the 32-bit kernel operational as well.

(I've ignored any loader issues in my explicit wording.)

> That has me rather confused,
> other than possibly to run legacy things, but that interface

I think it takes making the identification of the interface(s)
of interest explicit here vs. those that are not a worry.

> is likely
> to get broken quickly once the 32 bit builds are gone.

What specific builds materials are you expecting to be at
issue for being broken?

> 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?

This wording is unclear about the chroot/jail type of context
vs. having no 64-bit world present at all despite having a
64-bit kernel. That would be yet another type of "32bit build
of FreeBSD". (I've never investigated the validity of such a
combination. So I make no claims about its status.)

So you may need to be more explicit about the type(s) of
"32bit build of FreeBSD" contexts you are referencing.


(Note: lib32 in 64-bit worlds is intended to be kept working,
as I remember concluding from earlier wording about the
proposed handling of things.)


===
Mark Millard
marklmi at yahoo.com