Re: git: 7e7f88001d7d - main - pf: use time_t for storing time_t values

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