Warner Losh wrote:
>
>
> On Mon, Aug 25, 2025 at 3:13 AM Alexander Leidinger
> <[email protected] <mailto:[email protected]>> wrote:
>
> Am 2025-08-25 10:44, schrieb Marcin Cieslak:
> > On Thu, 21 Aug 2025, Alexander Leidinger wrote:
> >
> >>>> COMPAT_FREEBSD14? (Recently [gs]etgroups were changed, with
> >>>> compatibility syscalls moved to COMPAT_FREEBSD14).
> >>
> >> UPDATING only mentions VMM stuff for COMPAT_FREEBSD14. I give this a
> >> try tomorrow. But would this also affect the zfs dataset stuff?
> >
> > This thread could have been a simple UPDATING update. I think
> this is
> > the fourth
> > time or so I have run into problems, because the changes were not
> > explained.
> >
> > UPDATING entry on VMM got only there after I've spent 2 days+
> > troubleshooting
> > my wifibox failures.
> >
> > When I read your message I was immediately thinking you might need
> > "COMPAT_FREEBSD14",
> > but, again, I couldn't find any obvious entry neither in the docs nor
> > in
> > the git log I was looking at.
> >
> > @glebus - maybe during the stabilization effort the changes done
> to the
> > tree
> > could be reviewed and documented?
> >
> > - where the FreeBSD_version got bumped and why
>
> This is normally documented in
> https://docs.freebsd.org/en/books/porters-handbook/versions/
> <https://docs.freebsd.org/en/books/porters-handbook/versions/>
> (intended
> to be updated at the time when the FreeBSD_versions is increased),
> but I
> can agree that the info there is a bit terse sometimes.
>
> > - ABI changes
> > - ....
> >
> > For example it could be useful to be able to find the information
> "what
> > does COMPAT_FREEBSD14 do exactly" in the UPDATING/release notes file.
> > Otherwise I can't be sure if I need that option or "is my system
> fresh
> > enough"
> > to remove it from the kernel.
>
>
> It provides the system call interface as of FreeBSD 14. As new system
> calls are added that replace old ones, they are moved to being
> conditional on COMPAT_FREEBSD14. You should never remove the
> COMPAT_FREEBSDX when you are on current X+1. It's a recipe for pain.
> FreeBSD 14 binaries still might not always work (there are companion
> issues with shared library bumps for our non-symbol-versioned libraries
> too: there you have to wait for new compat14 package and/or play libmap
> games since the major bump usually is compatible enough to run most old
> programs but not always and not perfectly... libmap is at best a stop-gap).
>
>
> What do you think about this?
> diff --git UPDATING UPDATING
> index ddb2e7603b2a..e197940c6431 100644
> --- UPDATING
> +++ UPDATING
> @@ -73,6 +73,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 15.x IS SLOW:
> If you only have FreeBSD-sendmail installed for applications
> that
> require libmilter, you can now remove it.
>
> +20250815:
> + The [gs}etgroups(2)syscalls have changed. To maintain backwards
> + compatibility with existing programs, you need COMPAT_FREEBSD14
> in
> + your kernel config until all applications which use this are
> + rebuild/reinstalled.
> +
> 20250815:
> jemalloc 5.3.0 has been committed to the tree.
>
>
> I'd make it stronger. We should proactively create a COMPAT_FREEBSD15
> just after the branch and add it to GENERIC. You 100% of the time want
> this if you aren't updating every last binary on your system each and
> every time you update. We should add that to our checklist to do eary,
> rather than late, as needed. It shouldn't be buried in an obscure entry,
> but advice we always give for everybody, all the time. GENERIC has it in
> there, which is why most people won't see this issue.
I wonder why it's not done the other way around, having the options to
*exclude* the compat bits so there are no surprises for users with
custom kernel configs.
