All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Florian Bezdeka <florian.bezdeka@siemens.com>,
	 Xenomai <xenomai@lists.linux.dev>
Subject: Re: [PATCH 00/20] y2038: libcobalt: Allow both, native + time64_t interfaces at the same time
Date: Fri, 20 Feb 2026 12:12:04 +0100	[thread overview]
Message-ID: <87cy1zhdob.fsf@xenomai.org> (raw)
In-Reply-To: <faebe432-dddb-453a-91d1-77ee48a784ca@siemens.com> (Jan Kiszka's message of "Fri, 20 Feb 2026 10:36:52 +0100")

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 20.02.26 10:28, Philippe Gerum wrote:
>> Florian Bezdeka <florian.bezdeka@siemens.com> 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/cd03fe98-7237-426d-91c7-c6eae63a617e@siemens.com/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.

  reply	other threads:[~2026-02-20 11:12 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-20  9:08 [PATCH 00/20] y2038: libcobalt: Allow both, native + time64_t interfaces at the same time Florian Bezdeka
2026-02-20  9:08 ` [PATCH 01/20] lib/cobalt: Introduce cond.h Florian Bezdeka
2026-02-20 14:33   ` Jan Kiszka
2026-02-20  9:08 ` [PATCH 02/20] lib/cobalt: Introduce mutex.h Florian Bezdeka
2026-02-20  9:08 ` [PATCH 03/20] lib/cobalt: Introduce mq.h Florian Bezdeka
2026-02-20  9:08 ` [PATCH 04/20] lib/cobalt: Introduce rtdm.h Florian Bezdeka
2026-02-20  9:08 ` [PATCH 05/20] lib/cobalt: Introduce wrappers_time64.c Florian Bezdeka
2026-02-20 14:36   ` Jan Kiszka
2026-02-20 14:46     ` Florian Bezdeka
2026-02-20 14:47       ` Jan Kiszka
2026-02-27 11:56     ` Florian Bezdeka
2026-02-20  9:08 ` [PATCH 06/20] lib/cobalt: clock: Move all time64 related services to wrappers_time64.c Florian Bezdeka
2026-02-20  9:08 ` [PATCH 07/20] lib/cobalt: cond: " Florian Bezdeka
2026-02-20  9:08 ` [PATCH 08/20] lib/cobalt: mq: " Florian Bezdeka
2026-02-20  9:08 ` [PATCH 09/20] lib/cobalt: mutex: " Florian Bezdeka
2026-02-20  9:08 ` [PATCH 10/20] lib/cobalt: mutex: Provide time64 variant of pthread_timedmutex_lock_interruptible_np Florian Bezdeka
2026-02-20  9:08 ` [PATCH 11/20] lib/cobalt: rtdm: Move all time64 related services to wrappers_time64.c Florian Bezdeka
2026-02-20  9:08 ` [PATCH 12/20] lib/cobalt: select: Move select services into wrappers_time64.c Florian Bezdeka
2026-02-20 14:38   ` Jan Kiszka
2026-02-20 14:57     ` Florian Bezdeka
2026-02-20  9:08 ` [PATCH 13/20] lib/cobalt: semaphore: Move time64 related services to wrappers_time64.c Florian Bezdeka
2026-02-20  9:08 ` [PATCH 14/20] lib/cobalt: signal: " Florian Bezdeka
2026-02-20  9:08 ` [PATCH 15/20] lib/cobalt: timer: Move all " Florian Bezdeka
2026-02-20  9:08 ` [PATCH 16/20] lib/cobalt: timerfd: Move " Florian Bezdeka
2026-02-20  9:09 ` [PATCH 17/20] lib/cobalt: Move XN_USE_TIME64_SYSCALL " Florian Bezdeka
2026-02-20  9:09 ` [PATCH 18/20] lib/cobalt: Finally build the native time_t interfaces on top Florian Bezdeka
2026-02-20  9:09 ` [PATCH 19/20] lib/cobalt: thread: Cleanup and reorder includes Florian Bezdeka
2026-02-20  9:09 ` [PATCH 20/20] scripts/xeno-config: Allow disabling the y2038 / time64_t support Florian Bezdeka
2026-02-20 14:50   ` Jan Kiszka
2026-02-20 15:05     ` Florian Bezdeka
2026-02-20  9:28 ` [PATCH 00/20] y2038: libcobalt: Allow both, native + time64_t interfaces at the same time Philippe Gerum
2026-02-20  9:36   ` Jan Kiszka
2026-02-20 11:12     ` Philippe Gerum [this message]
2026-02-20 11:19       ` Florian Bezdeka
2026-02-20 15:06         ` Philippe Gerum
2026-02-20 11:20       ` Philippe Gerum
2026-02-20 11:49       ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cy1zhdob.fsf@xenomai.org \
    --to=rpm@xenomai.org \
    --cc=florian.bezdeka@siemens.com \
    --cc=jan.kiszka@siemens.com \
    --cc=xenomai@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.