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

On Mon, 17 Feb 2025 18:08:18 +0100
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.
> 
> 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).
> 
> 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?
> 
> Best regards,
> Kristof

Being the powerpc maintainer, I don't have any issue with this (after
all, I'm the one who changed powerpc to 64-bit time_t back in 201x), but
it should probably be publicly mentioned that anything that uses these
APIs need rebuilt. If it's purely kernel, no user export, then I don't
see a problem at all.

It's not MFC-able, though.

- Justin