Re: git: 2c1963d46335 - main - procfs rlimit: handle pipebuf [and related] :pipebuf . . . Invalid argument

On Sun, Oct 06, 2024 at 07:56:01AM -0600, Warner Losh wrote:
> On Sun, Oct 6, 2024 at 3:09 AM Konstantin Belousov <kostikbel@gmail.com>
> wrote:
> 
> > On Sun, Oct 06, 2024 at 10:57:23AM +0200, Dag-Erling Smørgrav wrote:
> > > Konstantin Belousov <kostikbel@gmail.com> writes:
> > > > We do not provide forward compatibility between kernel and userspace.
> > > > User binaries must be newer than kernel.
> > >
> > > Uh, no.  The opposite, in fact.
> >
> > Right, it is opposite.  It was a typo.
> >
> > Anyway, __FreeBSD_version is not about compatibility between specific
> > snapshot of kernel and user sources.  It de-facto provides two technical
> > measures:
> > 1. kernel refuses to load modules built against headers set with higher
> >    __FreeBSD_version than kernel
> > 2. Some values of __FreeBSD_version are used by userspace to
> >    detect if specific change is present in kernel.  See sys/param.h
> >    P_OSREL_ list.
> >
> 
> 3. It's used extensively in 3rd party software to select different
> interfaces
> (including ports). That's why we document why we do each bump.
Which is exactly what's wrong with __FreeBSD_version.

It seems that the use in third-party patches for Linux-ported software
is the way of least resistance to proper feature detection.  Also it
is usually wrong because it checks the compilation environment, as opposed
to the runtime.

> 
> While 'forward compatibility' is sometimes needed / provided when it
> adversely affects upgrade from source and fall back to prior kernel while
> it's worked out. But (a) ZFS BEs eliminate many problems and (b) we've
> only done it when it was impossible to run buildkernel / git (or svn or cvs
> in the past) to fix the problem. While the messages are annoying, they
> don't prevent that limited exception we've occasionally done in the past.
> In general, we've avoided changes so incompatible that they've needed
> a new P_OSREL_ entry to cope...

P_OSREL_ is 50/50 between incompatibilities (like P_OSREL_SIGSEGV) and
_runtime_ indication of the feature presence.

Still it cannot solve some very basic problems.  For instance, we do mark
binaries against csu' version they were linked against, but we do not
mark dso's.  I did not ended with a scheme to enable LA57 on amd64 without
causing big bangs because large AS breaks unpatched jemalloc, and there
is no good way for kernel to know if libc is patched.