RELNOTES: Note the deprecation of 32-bit platforms for 15.0.

[jhb]

Summary

This draws a line in the sand of removing support for 32-bit worlds
and kernels aside from COMPAT_FREEBSD32 and lib32 support. The
project may choose to alter this approach when 15.0 is released by
extending some level of 32-bit support in 15.0 or later.

[emaste]

RELNOTES

14

I would drop the "now", and there isn't a specific commit to point to.

14

Oh I guess the kernel warning is OK as a reference

16

32-bit binaries or executables or applications presumably?

[jhb]

This might need some hand-wavy dates in the final release notes blurb as @phk noted in the thread on arch@.

This also doesn't currently say anything about ports. I'm not sure if we will want something explicit about the fact that if 32-bit platforms are removed in 15.0 that means no pre-built packages, and that ports will remove support for those platforms once stable/14 goes EOL or if the fact that all falls out implicitly is sufficient?

RELNOTES

14

Yeah, my plan is to replace the xxxxx with the git hash of the kernel warning commit.

16

Oh geez, yes.

[emaste]

ports will remove support for those platforms once stable/14 goes EOL or if the fact that all falls out implicitly is sufficient

Much better to be explicit here

[fuz]

32-bit kernels and worlds are now deprecated and may be

Can I understand this as 32 bit jails on 64 bit hosts no longer being a supported use case?

[imp]

In D41164#937343, @fuz wrote:

32-bit kernels and worlds are now deprecated and may be

Can I understand this as 32 bit jails on 64 bit hosts no longer being a supported use case?

That will be supported. If the text suggests otherwise we should fix the language

[imp]

RELNOTES

16

I'd say binaries or jails

[fuz]

That will be supported. If the text suggests otherwise we should fix the language

Yes, I believe the current text suggests that.

RELNOTES

14

If 32 bit jails on 64 bit hosts will remain a supported use case, then 32-bit worlds are not deprecated as a 32 bit world is needed to run a 32 bit jail on a 64 bit host. Perhaps the more contrived but conceivable use case of using a 32 bit world with a 64 bit kernel on low RAM system may also be considered.

[emaste]

If 32 bit jails on 64 bit hosts will remain a supported use case, then 32-bit worlds are not deprecated

That doesn't necessarily follow -- we could support 32-bit binaries/jails on 64-bit hosts for backwards compatibility - for instance, running a FreeBSD 14.0 32-bit world on a FreeBSD 15.0 64-bit kernel, but not building FreeBSD 15.0 32-bit worlds.

[fuz]

In D41164#937367, @emaste wrote:

If 32 bit jails on 64 bit hosts will remain a supported use case, then 32-bit worlds are not deprecated

That doesn't necessarily follow -- we could support 32-bit binaries/jails on 64-bit hosts for backwards compatibility - for instance, running a FreeBSD 14.0 32-bit world on a FreeBSD 15.0 64-bit kernel, but not building FreeBSD 15.0 32-bit worlds.

I apologise for my question being vague. I specifically wanted to know if coming forwards, building 32 bit worlds for use in jails (or as a pseudo 32-bit install) will stay supported. Seems like the consensus is "no it won't".

[phk]

RELNOTES

14

Strawman questions:

How can you compile & run a 32bit app, if there are no 32 bit libraries ?

If there are 32 bit libraries, how do they get built, if "worlds are deprecated" ?

[brooks]

RELNOTES

14

Strawman questions:

How can you compile & run a 32bit app, if there are no 32 bit libraries ?

If there are 32 bit libraries, how do they get built, if "worlds are deprecated" ?

There are 32-bit libraries built and in /usr/lib32 (see D40945 and the rest of the stack for arm support which is the last gap there). You can compile with the -m32 compiler flag and can even build 32-bit programs as part of a FreeBSD-derived source tree (see libexec/rtld-elf32/Makefile for an example).

[jhb]

RELNOTES

14

@fuz perhaps this will help: the idea if we do full deprecation is that you can't build a 15.0 i386 jail (for example), but you will be free to use a 14.x i386 jail on a 15.0 host, and you can even still build ports for 14.x i386 packages so long as 14.x remains supported.

@phk: Deprecating worlds means that we may no longer support building 32-bit usr.bin/foo binaries, etc. In practical terms what I would expect if we do deprecate worlds in 15.0 is that we would drop 32-bit worlds from make universe and CI. They might still build if you do it by hand as the infrastructure to support lib32 requires basic build infrastructure for i386 to still remain, though I would expect 32-bit only warnings, etc. (e.g. always using uintmax_t casts) to no longer be fixed over time in parts of world outside of what lib32 builds. One could perhaps make the argument that you need an existing i386 world around as a sysroot to use for building and that we only guarantee support for running a binary compiled against a sysroot from an existing release. I think though that Juniper at least might really want a way to build a 15.x binary using cc -m32.

[jhb]

Add more detail

[phk]

So which is it ?

A) We support 32 bit jails and do not deprecate 32 bit worlds ?

B) We deprecate 32 bit world AND 32 bit jails ?

Also:

If we support 32 bit jails: How long do we commit to supporting the 32bit 14.X kernel ABI ?

[jhb]

In D41164#937728, @phk wrote:

So which is it ?

A) We support 32 bit jails and do not deprecate 32 bit worlds ?

B) We deprecate 32 bit world AND 32 bit jails ?

Hmm, perhaps it would help to clarify, we would support _running_ a 32-bit jail. We wouldn't support _building_ a tarball of 15.x binaries that could be used to deploy a jail. I guess I generally think of jails only as the former (you can extract an i386 tarball into a chroot and run it), not the latter. I think this means B) above, but I'm not sure if we are interpreting words the same. I thought this paragraph was clear about executing (rather than building) 32-bit binaries and that it says explicitly your need an older userland base system to keep using an i386 jail:

	Support for executing 32-bit binaries on 64-bit platforms via
	COMPAT_FREEBSD32 will remain supported for the foreseeable
	future.  This includes support for 32-bit jails.  However,
	since future releases will not provide worlds or release
	images, 32-bit jails would need to be built from an earlier
	release (e.g. 14.0).

Also:

If we support 32 bit jails: How long do we commit to supporting the 32bit 14.X kernel ABI ?

We have yet to remove the 3.x kernel ABI support from the source (it is possible to still run an old 1.x a.out binary under COMPAT_FREEBSD32 today if you have it lying around and I think @kib has even done it somewhat recently), and GENERIC on x86 still has COMPAT_FREEBSD4. But again, this is about how long we support running an existing 32-bit binary, not about how long we support building an entire 32-bit userland base system. That's not a very satisfying answer though. We could perhaps put a stake in the ground about how old of compat we are willing to ship in GENERIC at least. (For example, should we drop some COMPAT_FREEBSD<n> from GENERIC in 14.0? If so, then that policy will carry over to 32-bit support since the timeline at which COMPAT_FREEBSD14 gets taken out of GENERIC is effectively the timeline for COMPAT_FREEBSD32.) I guess for now though we have no timeline or expectation for removing COMPAT_FREEBSD32 or older COMPAT_FREEBSD<n>.

[imp]

So one could use poudriere to build a 14 i386 jail, but not a 15?

And at what point do we tear it down. Just after 14cor just before 15? For armv7 I thought the latter...

[phk]

So if I understand your position, what we are trying to say is:

From FreeBSD 15 there will no longer be any 32 bit versions of FreeBSD.

However, a FreeBSD-15 64bit system will still be able to run older 32bit and 64bit FreeBSD releases inside a jail.

I strongly suggest replacing "older" with "less than 10 years old", for some value of 10, as a matter of principle.

[kib]

RELNOTES

29

What does this sentence mean? That 32bit jails just work?

[jhb]

In D41164#937876, @phk wrote:

So if I understand your position, what we are trying to say is:

From FreeBSD 15 there will no longer be any 32 bit versions of FreeBSD.

However, a FreeBSD-15 64bit system will still be able to run older 32bit and 64bit FreeBSD releases inside a jail.

I strongly suggest replacing "older" with "less than 10 years old", for some value of 10, as a matter of principle.

Yes.

[jhb]

RELNOTES

29

The intent is to say that if you have base.txz from, say, 13.2-RELEASE i386 untarred to /usr/freebsd-i386-13.2 or the like, that you can use cc -target i386-unknown-freebsd13.2 --sysroot /usr/freebsd/i386-13.2 to build i386 binaries, and those i386 binaries will run via COMPAT_FREEBSD32 under a FreeBSD 15.x amd64 kernel.

[phk]

@jhb

IMO the current text does a really bad job at communicating that.

Can I suggest we add a "Tl;dr" summary along the two lines I wrote at the top ?

[kib]

RELNOTES

29

The --sysroot part is quite unobvious, I would admit. At least for people not daily configuring different toolchains for cross-build. Perhaps this recipe should be put somewhere, and then referenced from the text?

Might be build.7, whatever other outdated info is contained in the manpage.

[jhb]

RELNOTES

29

Humm, I assume if someone knows about --sysroot you would know that is how you use it. That's the main way I use --sysroot is to do things like cross-build an armv7 GDB on an amd64 host by pointing --sysroot at an arm install root. That is, I would maybe expect folks to not be aware of --sysroot, but I would be surprised if someone aware of --sysroot didn't want to point it at directory holding the result of make installworld or the like. For the case of someone not being aware of --sysroot that is more just a general explanation of that flag and what it means. I don't know that the release notes is the right place to try to educate people about how to cross-build software.

[kib]

RELNOTES

29

This is why I mentioned build.7. For me, the use of --sysroot this way is indeed something to learn.

[jhb]

Trim the text

[jhb]

I've removed all mentions of jails since that is seemingly too confusing.

[phk]

RELNOTES

21

"The next 10 years" makes it harder than it needs to be for people who find this doc seven years from now.

Specifying this in terms of time rather than branches adds a lot of corner cases, for instance, does this mean "supported for the entire lifetime of a stable branch created 9.99 years from now ?"

Keeping in mind that we want to get rid of 32 bit time_t well ahead of 2038, I propose:

»Support for executing 32-bit binaries on 64-bit platforms via COMPAT_FREEBSD32 will
still be supported in FreeBSD-15 and FreeBSD-16.«

26

Same as above, I propose:

»... will be supported in FreeBSD-15, which includes ...«

[emaste]

RELNOTES

21

maybe add "at least FreeBSD 15 and FreeBSD 16" to make it clear there's no implied plan to remove it in FreeBSD 17.

[phk]

RELNOTES

21

We should have an explicit plan to not have any supported 32 bit at least a couple of years before the 2038 32-bit time_t roll-over.

[emaste]

RELNOTES

21

Deprecating 32-bit platforms (as a whole) is separte from 32-bit time_t roll-over; our only platform with 32-bit time_t is i386.

[jhb]

Replace year ranges with stable branch names.

[jhb]

RELNOTES

21

Sigh, I used 10 years because that's what @phk originally suggested on arch@. I can change it to stable/15 and stable/16.

[emaste]

My main suggestion is that we include some note that this is subject to change (either intended to remain in the release notes, or just an internal note that we will remove before publishing the release notes). I'd like to avoid news sites from picking up these notes and publishing them as fact if we are not yet fully committed to that decision.

[jhb]

In D41164#944066, @emaste wrote:

My main suggestion is that we include some note that this is subject to change (either intended to remain in the release notes, or just an internal note that we will remove before publishing the release notes). I'd like to avoid news sites from picking up these notes and publishing them as fact if we are not yet fully committed to that decision.

The commit log says that. Perhaps I can add a paragraph to the end that copies some of what is in the commit log. The commit log for the warning message also has a similar caveat.

[jhb]

Add a caveat para

[brooks]

RELNOTES

36

Should we add something like: "However, all 32-bit platforms are Tier-2 or Tier-3 and support for individual ports should be expected to degrade as upstreams deprecate 32-bit platforms."