On Mon, 17 Feb 2025 18:08:18 +0100 Kristof Provost <k...@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 <k...@freebsd.org> > >> AuthorDate: 2025-02-07 10:29:26 +0000 > >> Commit: Kristof Provost <k...@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 <guent...@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
