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

Florian Bezdeka <[email protected]> writes:

> 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.
>

Yes, moving to time64-only would be straightforward for x4, and would
not even break the ABI. libevl is currently converting time32 requests
to time64 by using bounce buffers for (i)time(r)specs internally, we
only need to drop the latter - which we need to in order to meet a
particular POSIX requirement about deferred timeout handling.

-- 
Philippe.