From nobody Mon Nov 18 16:49:15 2024 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XsYWD3YVqz5dKj8 for ; Mon, 18 Nov 2024 16:49:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XsYWC6m5Hz41Sy for ; Mon, 18 Nov 2024 16:49:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-7e9e38dd5f1so3601492a12.0 for ; Mon, 18 Nov 2024 08:49:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1731948566; x=1732553366; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PbBocjXC8QH/v4XO/Wca6fkVjYHmFFmJn2IuWSwfiZg=; b=SiBjx4bgEt1b2brdgulB24xDZV66u1b4oojZbCnfFxy7MLNxQBSZ7p6K52SSUUSw1G FUXE5xszs625TlFOf9/6W8E9Pv8QZy5vFTj0jaZpLGMztmzxAiSxWHHTWVCRJjkeugbr 5HjHFJTAiXkC3gKiqb9gRuUaPDb613PMfLfJdOHPPkkXwmMYuOiBAvR9sCquvQuqKIIl nPoIxyRBc4mPdlfmZXF/fX2dxB9ENmzHPnqVnlTJ2Q0N4rUXChYyVMyiak7F6jy2NttN 7VJJD4VjevXMgghqdrdcdxVMw272tRMF/DJbenUD+/Ct49JMZPjRyRrgFb9FjAUMguJw h7Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731948566; x=1732553366; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PbBocjXC8QH/v4XO/Wca6fkVjYHmFFmJn2IuWSwfiZg=; b=B5KLydstzQyxsu3i8BHPq0DpsRFl6MZeLmUsJz37myIye1th+/xNMNwWTnXGAOFPoZ ZrnRPIJpGtZ8NyeWRMJbDKqaNlBAy+T3TTwfa2PstQWwnQdo2ldutN12btVlzNrbpn/M QkSg7Bo675pLToa8RALM1XR7XXhiFm7Yy+ChRYJZNnSk78BHNXshiw6Qn7bUVA0M9uz1 m9j+IpZKqq2cZiis1xcNmkj43qQIAyaqeXjeq/QvKckm9I5abGPe53JRygLowR7hTx0M Chbdy/D16icf390msG5oB15FM237+Mmc3nPYtuHG8NCNWixhA0vvHk7nlm51UKi9HGkl HBTg== X-Forwarded-Encrypted: i=1; AJvYcCWTLJuEMUKes8OAW2J9ApPLw9cJETdn9RE8KvxVBUWXeA1cZ6bJT484j/YOQUNb2IZSGwsaR03k5SR6rgePqpdrbhvX9Q==@freebsd.org X-Gm-Message-State: AOJu0YzSW4qnHkqufxRlmjAAagC2J+0zhNx8sKHhPDE8zyldFAEHuvmd 2qQeyOIFrIUJk3Yrz0LhEdZf3q8WN6S0RlmFvCGHqXjs89K+5JwqyJM/MW43uugguQ0qvO9MFeD Y097wy6GFyqgmYYb2Rqmq73O/6hdkBPbt+FwjtA== X-Google-Smtp-Source: AGHT+IFjkEfQcR2bbXbN9G8iaofEMpoOnv4fFxddqM4uqllRioMUlYAT2AC16AajYwQjzqLw4MPiv8cZYvRpER84Em4= X-Received: by 2002:a05:6a21:9988:b0:1dc:1147:9ff4 with SMTP id adf61e73a8af0-1dc90aea245mr18159436637.1.1731948566313; Mon, 18 Nov 2024 08:49:26 -0800 (PST) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 References: <202411161523.4AGFNBcu010436@gitrepo.freebsd.org> In-Reply-To: From: Warner Losh Date: Mon, 18 Nov 2024 09:49:15 -0700 Message-ID: Subject: Re: git: 4ef07eb0802a - main - getentropy: Add Git hashes corresponding to SVN references To: Brooks Davis Cc: Ed Maste , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="0000000000001096b0062732b387" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4XsYWC6m5Hz41Sy X-Spamd-Bar: ---- --0000000000001096b0062732b387 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2024 at 9:24=E2=80=AFAM Brooks Davis w= rote: > 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=3D4ef07eb0802a6353faf79d58719d800= 8decabae0 > > > > commit 4ef07eb0802a6353faf79d58719d8008decabae0 > > Author: Ed Maste > > AuthorDate: 2024-11-16 15:18:16 +0000 > > Commit: Ed Maste > > 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 hashe= s > 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 'forwar= d 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 --0000000000001096b0062732b387 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 18, 2024 at 9:24=E2=80=AF= AM Brooks Davis <brooks@freebsd.or= g> 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=3D4ef07eb0802a6353faf79d58719d8008decabae0<= /a>
>
> commit 4ef07eb0802a6353faf79d58719d8008decabae0
> Author:=C2=A0 =C2=A0 =C2=A0Ed Maste <emaste@FreeBSD.org>
> AuthorDate: 2024-11-16 15:18:16 +0000
> Commit:=C2=A0 =C2=A0 =C2=A0Ed Maste <emaste@FreeBSD.org>
> CommitDate: 2024-11-16 15:22:46 +0000
>
>=C2=A0 =C2=A0 =C2=A0getentropy: Add Git hashes corresponding to SVN ref= erences
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0getentropy has a comment about a special case to su= pport kernels between
>=C2=A0 =C2=A0 =C2=A0SVN revisions r331280 and r337999.=C2=A0 Add the co= rresponding Git hashes so
>=C2=A0 =C2=A0 =C2=A0there's a usable reference after Subversion inf= rastructure 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 runni= ng newly compiled
binaries with kernels that are in a 4 month win= dow in 2018. This is 'forward
compat' code. Generally, we= don't provide forward compatibility code,
except when it aff= ects 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<= /div>
can just delete this code. As brooks points out, there's doze= ns 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 diff= iculty in rollback. But BE's likely will make the 'no forward compa= t'
more often, rather than less, since the kernel and user sp= ace can trivially
be rolled back. The 'fuzzy' rules devel= oped 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 th= e current tribal knowledge we need.

Warner
--0000000000001096b0062732b387--