Date: Sat, 21 Jun 2025 20:49:20 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-rwg@gndrsh.dnsmgr.net, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: Deprecation of i386 and 32-bit powerpc for 15.0 Message-ID: <8AA8B662-1A97-4651-80A5-456B30A557D8@yahoo.com>
index | next in thread | raw e-mail
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.comhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8AA8B662-1A97-4651-80A5-456B30A557D8>