On Mon, 25 Aug 2025 18:39:08 +0700 cy...@mm.st wrote: > Warner Losh wrote: > > > > > > On Mon, Aug 25, 2025 at 3:13 AM Alexander Leidinger > > <alexan...@leidinger.net <mailto:alexan...@leidinger.net>> 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.
Creating kernel config from scratch is discouraged now. Why not including such as GENERIC, GENERIC-NODEBUG, MINIMAL and MINIMAL-NODEBUG (there are more candidates exist) and add or remove options / devices by options / nooptions and device / nodevice? For example, GENERIC-NODEBUG on main simply includes GENERIC, disables unneeded options via including std.nodebug and name itself as GENERIC-NODEBUG. https://cgit.freebsd.org/src/tree/sys/amd64/conf/GENERIC-NODEBUG https://cgit.freebsd.org/src/tree/sys/conf/std.nodebug Now you can create, for example, a config file that includes GENERIC, name it by ident line and "nooptions COMPAT_FREEBSD14" line to drop FreeBSD 14 compatibility support. ===== Example ===== include GENERIC ident NO14SUPPORT nooptions COMPAT_FREEBSD14 ===== End example ===== Not 100% sure, but IIRC, ancient kernel configs which needed separate config process on building kernel didn't have include functionality, thus, needed to create full config. But it's not needed now. -- Tomoaki AOKI <junch...@dec.sakura.ne.jp>
