Re: UPDATING stuff

Warner Losh wrote:
> 
> 
> On Mon, Aug 25, 2025 at 3:13 AM Alexander Leidinger
> <Alexander@leidinger.net <mailto:Alexander@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.