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

On 20.02.26 12:12, 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.
> 

...and staying compatible with glibc ABIs.

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

Of course. Best would be then to not even start exposing the old calls
anymore, rather then bending existing ones to time64.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center