Re: git: 4ef07eb0802a - main - getentropy: Add Git hashes corresponding to SVN references
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