Re: git: 4ef07eb0802a - main - getentropy: Add Git hashes corresponding to SVN references

From: Warner Losh <imp_at_bsdimp.com>
Date: Mon, 18 Nov 2024 16:49:15 UTC
On Mon, Nov 18, 2024 at 9:24 AM Brooks Davis <brooks@freebsd.org> wrote:

> On Sat, Nov 16, 2024 at 03:23:11PM +0000, Ed Maste wrote:
> > The branch main has been updated by emaste:
> >
> > URL:
> https://cgit.FreeBSD.org/src/commit/?id=4ef07eb0802a6353faf79d58719d8008decabae0
> >
> > commit 4ef07eb0802a6353faf79d58719d8008decabae0
> > Author:     Ed Maste <emaste@FreeBSD.org>
> > AuthorDate: 2024-11-16 15:18:16 +0000
> > Commit:     Ed Maste <emaste@FreeBSD.org>
> > CommitDate: 2024-11-16 15:22:46 +0000
> >
> >     getentropy: Add Git hashes corresponding to SVN references
> >
> >     getentropy has a comment about a special case to support kernels
> between
> >     SVN revisions r331280 and r337999.  Add the corresponding Git hashes
> so
> >     there's a usable reference after Subversion infrastructure
> disappears.
>
> This code should likely be removed soon as the fix commit is in 12.0.0.
> It's not completely clear cut as it is post ino64 and thus not
> completely in the "can't possibably work" category.
>

So we can just delete it. This code is for running newly compiled
binaries with kernels that are in a 4 month window in 2018. This is 'forward
compat' code. Generally, we don't provide forward compatibility code,
except when it affects the upgrade for a "short" window or other very well
defined exceptions. One could quibble over the exact bounds of this
purposely fuzzy rule, but this is so far outside those bounds that we
can just delete this code. As brooks points out, there's dozens of new
system calls since then that are also used, in addition to the ino64
changes,
that have no 'forward compat code'. In the past, we've said we officially
we don't support forward compat at all, though had the softer line due
to the difficulty in rollback. But BE's likely will make the 'no forward
compat'
more often, rather than less, since the kernel and user space can trivially
be rolled back. The 'fuzzy' rules developed in a UFS-only world which
required greater care and efforts to not brick systems.

It might be a good thing for srcmgr to document the policy to provide
better guidance than the current tribal knowledge we need.

Warner