From nobody Mon Feb 17 21:03:52 2025 X-Original-To: dev-commits-src-all@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 4YxZs25M8Jz5nQc5 for ; Mon, 17 Feb 2025 21:04:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 4YxZs16F2vz3Fwc for ; Mon, 17 Feb 2025 21:04:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-2fbffe0254fso8824943a91.3 for ; Mon, 17 Feb 2025 13:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1739826244; x=1740431044; 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=kimMyCBko/ey+FTT4BZu01X/K9zj9xv1MayU8IRS16g=; b=K/bP8EBpIguVxoFdTg8PFXelzjThDIUeHIVgj6lm0stiBcdhPO2nezkrpILpiG6DjR mrSFC62Q4gKz51pSLp/MlivSj2vLAs8uh85neegJOpnA1E9q00t+daUyAA1OVd4WteMS 3CcSjRzdyupG3l7XUNY2pzxHqxF2WX1AnAQK8K4GPr6qiXI2l7ysrMLxzDSZ+U6cE6Ih R6T0wvvHkHOk2yDGabFdJCshZJwU8bsWcVS/gXGUY99qRnbmeKkWIfXia3f7P4FaWIX3 1liBg3VOhhv56XOU1P/lRwsfyTS02HaEuvtv3jTzpPeiR2OrjcJqVDDGHqyUR0wMJY46 qOPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739826244; x=1740431044; 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=kimMyCBko/ey+FTT4BZu01X/K9zj9xv1MayU8IRS16g=; b=FgxlCI7TNdpbHUg5N/ha000V8M7LcHGTjhfzE9C+uXHeyHtMwngdIhGRk+Og+rpGlD hvHtzhD4E3kOwQUz8uDtZolycTxaaTLE5IeZ3wKtsXGJj3AFYsJVQeQrpNuhfcbO6O9U 8H/Yz3F3kIwDriAYQCkQROOU/HJuKGuVEqKCC+NSforLVWhnT1yrWjky2HEtPu6Qxwof 8ytcAC/PIZasN3emxQtk27iwVYYeiM2n0Ni9TitWjsa0V96JbDFFGnpHc27GuLkAKJRm 6Rba0M/F3osGMNsZ1Yw4DwtgPjJuRga+u3NS01IcMmtK4HiGPUHu/4QHP66RkH+UmAQx r+pA== X-Forwarded-Encrypted: i=1; AJvYcCXQz1ZjdVeyZ3LH+kvbFjQKA2J+/Yz/FU6l3AJ9mCvVYlc2cSIF/Rkl+BvdgZ/oVC4v9bWg6cdgrhxh7hzie8zbT06l@freebsd.org X-Gm-Message-State: AOJu0YxpstwMjhupgHFFv7YzmYZlve/kTIJl+zGZR8UAoM8VHrkLkqrq eltD/kPTLhxxgJCJDegLci5VFThAYyprrP241FOlrbxcdNGGjaWQApLS1vXzvSqr+LriI/lpNjY QWZyRnTI5qxYgwIslRONL+MZwXtv0JVBxN8nSRg== X-Gm-Gg: ASbGnctTs9zk2SKtcXxRbWcdDyp7v8S8seoI4L4BetOQuuVAUK2oDN5teqQMgrFmzlb 86RefkJj1jZaK1Q4OgNWmE7HpfDRC+z5H9Bctyk9iFtnzSoK5qCs1Z8BxIv7Xq6sUSAaCOXTfEQ hDPoUpEPAaeQTJeCcE69+hf1gY/nQ= X-Google-Smtp-Source: AGHT+IFFummUt8lH/PmTilO2TA89cHIv5UordWdk70PoGWtvTf39r5tVVNV10Iqy3JrgXs8HHQ8+jFp9gsEcgqRoAdE= X-Received: by 2002:a17:90b:510c:b0:2ee:53b3:3f1c with SMTP id 98e67ed59e1d1-2fc40d14c1emr16685474a91.5.1739826243781; Mon, 17 Feb 2025 13:04:03 -0800 (PST) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 References: <202502141750.51EHoOFm061342@gitrepo.freebsd.org> <5c019c51-949b-4255-bc44-926ac973a1af@FreeBSD.org> <1B3E8B07-037B-4DA9-A8D7-81F866078A39@FreeBSD.org> In-Reply-To: <1B3E8B07-037B-4DA9-A8D7-81F866078A39@FreeBSD.org> From: Warner Losh Date: Mon, 17 Feb 2025 14:03:52 -0700 X-Gm-Features: AWEUYZmFBIIxCAb02CHVwzViYiRoESZhQ9ves6lBHvrpeN2fRHRA2fkE385I3pw Message-ID: Subject: Re: git: 7e7f88001d7d - main - pf: use time_t for storing time_t values To: Kristof Provost Cc: John Baldwin , src-committers , "" , "" Content-Type: multipart/alternative; boundary="0000000000003b5f32062e5cdd81" 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: 4YxZs16F2vz3Fwc X-Spamd-Bar: ---- --0000000000003b5f32062e5cdd81 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 17, 2025, 10:08=E2=80=AFAM Kristof Provost wro= te: > On 17 Feb 2025, at 16:24, John Baldwin wrote: > > On 2/14/25 12:50, Kristof Provost wrote: > > The branch main has been updated by kp: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=3D7e7f88001d7dfec83cd7568369be6a5= 87d4a51ff > > commit 7e7f88001d7dfec83cd7568369be6a587d4a51ff > Author: Kristof Provost kp@FreeBSD.org > AuthorDate: 2025-02-07 10:29:26 +0000 > Commit: Kristof Provost kp@FreeBSD.org > CommitDate: 2025-02-14 17:47:52 +0000 > > pf: use time_t for storing time_t values > No change to the underlying type, so no ABI change. > We define __time_t as uint64_t if __LP64__, otherwise uint32_t, > and only define __LP64__ if long is 64 bits. > In other words: __time_t =3D=3D long. > ok henning@ deraadt@ > Obtained from: OpenBSD, guenther , 6c1b69a0ff > Sponsored by: Rubicon Communications, LLC ("Netgate") > Differential Revision: https://reviews.freebsd.org/D48963 > > This is an ABI change on non-i386 32-bit platforms in FreeBSD since they > all use a 64-bit type for time_t that is not the same size as long. Not > sure if the ABI change matters on FreeBSD though? > > It wasn=E2=80=99t intended to be an ABI change, hence the commit message.= It > appears that=E2=80=99s only correct for x86 though. > Yes. It may have been true in openbsd land, but not FreeBSD. > So we=E2=80=99re only talking about armv7 and ppc32, if I=E2=80=99m not f= orgetting > anything. The former is on the removal list already, and the latter .. > well, I don=E2=80=99t know how many users there are. Both are likely to b= e embedded > platforms where the ABI change is going to be even less relevant (because > it really only matters if the kernel and userspace are not updated > together, and these are going to be embedded devices that are far more > likely to have everything updated simultaneously). > Armv7 will be around in 15. Ppc32 is likely going away. > So I=E2=80=99m unsure about what to do. I can revert this and we can just= carry > this (trivial) diff to OpenBSD forever, or we can ignore the ABI breakage > given the above. I=E2=80=99m not inclined to do anything more involved th= ough. > > Do you have any thoughts? > I think the diffs to OpenBSD are most undesirable of the alternatives. Major os breakage is fine. Tier2 platforms get a weaker version of compatibility. Armv7 is on the cusp of the abi needing to work. Sonce this is a private abi, and only a few programs are affected and they already need an update for 15 due to other changes (right?) And since providing backwards compatible ABI shims looks to be kinda nontrivial, I agree with the others: document in release notes and don't MFC and we're likrly good. If it is really important to someone AND everything works except for thos one detail between 14 and 15, then the project=E2=80=99s custom would be to integrate that patch, but not require the originator to do it. Tl;dr: mfc no. Relnotes yes. Warner Warner Best regards, > Kristof > --0000000000003b5f32062e5cdd81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 17, 2025, 10:08=E2=80=AFAM Kristof Provost= <kp@freebsd.org> wrote:
<= /u>

On 17 Feb 2025, at 16:24, John Baldwin wrote:

On 2/14/25 12:50, Kristof Provost wrote:

The branch main has been updated by kp:

URL: https://cgit.FreeBSD.org/src/commit/?id=3D7e7f88001d7dfec83cd= 7568369be6a587d4a51ff

commit 7e7f88001d7dfec83cd7568369be6a587d4a51ff
Author: Kristof Provost kp@FreeBSD.org
AuthorDate: 2025-02-07 10:29:26 +0000
Commit: Kristof Provost kp@FreeBSD.org
CommitDate: 2025-02-14 17:47:52 +0000

 pf: use time_t for storin=
g time_t values
     No change to the underlying type, so no ABI change.
     We define __time_t as uint64_t if __LP64__, otherwise uint32_t,
 and only define __LP64__ if long is 64 bits.
 In other words: __time_t =3D=3D long.
     ok henning@ deraadt@
     Obtained from:  OpenBSD, guenther <guenther@openbsd.or=
g>, 6c1b69a0ff
 Sponsored by:   Rubicon Communications, LLC ("Netgate")
 Differential Revision:  https://reviews.freebsd.org/D4=
8963

This is an ABI change on non-i386 32-bit platforms in FreeB= SD since they
all use a 64-bit type for time_t that is not the same size as long. Not sure if the ABI change matters on FreeBSD though?

It wasn=E2=80=99t intended to be an ABI change, hence the c= ommit message. It appears that=E2=80=99s only correct for x86 though.


Yes. It may have been true in openbsd land, but not FreeBSD.=C2= =A0

So we=E2=80=99re only talking about armv7 and ppc32, if I= =E2=80=99m not forgetting anything. The former is on the removal list alrea= dy, and the latter .. well, I don=E2=80=99t know how many users there are. = Both are likely to be embedded platforms where the ABI change is going to b= e even less relevant (because it really only matters if the kernel and user= space are not updated together, and these are going to be embedded devices = that are far more likely to have everything updated simultaneously).


Armv7 will be around in 15. Ppc32 is likely going away.

So I=E2=80=99m unsure about what to do. I can revert this a= nd we can just carry this (trivial) diff to OpenBSD forever, or we can igno= re the ABI breakage given the above. I=E2=80=99m not inclined to do anythin= g more involved though.

Do you have any thoughts?

I think the diffs to OpenBSD are most undesi= rable of the alternatives.

Major os breakage is fine. Tier2 platforms get a weaker version of compa= tibility.

Armv7 is on th= e cusp of the abi needing to work. Sonce this is a private abi, and only a = few programs are affected and they already need an update for 15 due to oth= er changes (right?) And since providing backwards compatible ABI shims look= s to be kinda nontrivial, I agree with the others: document in release note= s and don't MFC and we're likrly good.

<= /div>
If it is really important to someone AND everything = works except for thos one detail between 14 and 15, then the project=E2=80= =99s custom would be to integrate that patch, but not require the originato= r to do it.

Tl;dr: mfc n= o. Relnotes yes.

Warner= =C2=A0

Warner

Best regards,
Kristof

--0000000000003b5f32062e5cdd81--