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

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.

-- 
Philippe.