Re: git: 7e7f88001d7d - main - pf: use time_t for storing time_t values
- In reply to: Warner Losh : "Re: git: 7e7f88001d7d - main - pf: use time_t for storing time_t values"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 18 Feb 2025 13:54:43 UTC
On 17 Feb 2025, at 22:03, Warner Losh wrote: > On Mon, Feb 17, 2025, 10:08 AM Kristof Provost <kp@freebsd.org> wrote: > >> 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=7e7f88001d7dfec83cd7568369be6a587d4a51ff >> >> 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 == long. >> ok henning@ deraadt@ >> Obtained from: OpenBSD, guenther <guenther@openbsd.org>, 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’t intended to be an ABI change, hence the commit message. It >> appears that’s only correct for x86 though. >> > > Yes. It may have been true in openbsd land, but not FreeBSD. > >> So we’re only talking about armv7 and ppc32, if I’m not forgetting >> anything. The former is on the removal list already, and the latter .. >> well, I don’t know how many users there are. Both are likely to be 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’m 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’m not inclined to do anything more involved though. >> >> 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. > How does https://reviews.freebsd.org/D49046 look? This will not be MFC’d. There’s an entire series of OpenBSD patches that this is part of that will not be MFCd. Best regards, Kristof