Re: [PATCH 00/20] y2038: libcobalt: Allow both, native + time64_t interfaces at the same time

On Fri, 2026-02-20 at 12:12 +0100, Philippe Gerum wrote:
> Jan Kiszka <[email protected]> writes:
> 
> > On 20.02.26 10:28, Philippe Gerum wrote:
> > > Florian Bezdeka <[email protected]> writes:
> > > 
> > > > Hi all,
> > > > 
> > > > The current time64_t / y2038 support switched libcobalt to time64_t
> > > > only, removing the interfaces for the native time_t type.
> > > > 
> > > > With that series applied both worlds can live together in one libcobalt
> > > > build which should hopefully increase the backward compatibility a bit.
> > > > 
> > > 
> > > Is this series re-enabling time32 in a way?
> > > 
> > 
> > It's allowing to keep the time32 ABIs around without having to use
> > --disable-y2038 for configure. It also resolves that we were changing
> > existing time32-only functions to time64 where glibc actually added a
> > separate one (see also
> > https://lore.kernel.org/xenomai/[email protected]/T/#u
> > - which probably needs a rework to align with this series).
> > 
> 
> Ok, so this is merely to keep the legacy applications building over the
> latest x3 releases as transparently as possible.
> 
> x4 is unlikely to support time32 for much longer though. With the
> upcoming support for a POSIX API, we can't make a pledge for a stable
> ABI yet - timeouts on syscalls have to be handled differently on the
> whole user->kernel path in the evl core services, in order to enable
> some of them for POSIX too. I plan to use this change window for phasing
> out time32 entirely in the same move, which would simplify the POSIX
> implementation significantly compared to x3, not to speak of the fact
> that using time32 for new applications in this day and age would be
> obviously wrong anyway.
> 

I see no problem here. If possible - and that seems to be the case - x4
should not deal with time32 anymore.

A possible update path from x3 to x4 would be:
  - x3 no time64
  - x3 enable time64
  - move to x4

That should be doable.