On 8/25/25 05:48, 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. Warner
+1; I don't think it makes sense to have to document every single transitional period for things like the recent getgroups/setgroups and vmm changes. The simple fact of living on -CURRENT is that you either need to more strictly control your image update process and package builders, or you need COMPAT_FREEBSD(X - 1) until it approaches the first release on the new branch. If it was a long-term dependency on a COMPAT option for a feature that we're keeping then that clearly should be documented (though should likely be reconsidered), but for transient conditions that only last until your galaxy has been rebuilt- those kinds of activities are going to keep happening, and it's 100% better to condition users to expect that for living on a development branch rather than trying to enumerate all of the scenarios where they might need it every time. Thanks, Kyle Evans
