From: Philippe Gerum <rpm@xenomai.org>
To: Florian Bezdeka <florian.bezdeka@siemens.com>
Cc: chensong@tj.kylinos.cn, Jan Kiszka <jan.kiszka@siemens.com>,
xenomai@xenomai.org
Subject: Re: [PATCH 4/8] lib: y2038: convert to internal timespec type
Date: Wed, 31 Mar 2021 10:13:14 +0200 [thread overview]
Message-ID: <87zgyjrbad.fsf@xenomai.org> (raw)
In-Reply-To: <556e88f0-6b20-ab48-1d22-d0dcf8a2d8f0@siemens.com>
Florian Bezdeka <florian.bezdeka@siemens.com> writes:
> Hi Philippe,
>
> which "internal timespec type" are you talking about? You're using
> struct timespec here, which is not y2038 safe on 32 bit platforms.
>
The whole point of these series is solely to enable the code base for
building on the recent kernel series, not to address the y2038
issue. Song and yourself are addressing the later in a series of patches
indirectly based on my tree via wip/dovetail.
So I'm introducing the bits aimed at building on v5.x+ kernels which
includes converting to the new time specification types used upstream,
nothing more. Your fixes on the ia32/compat breakage introduced in the
first attempt are part of this new series (i.e. timeout handling in
compat mode for mq, mutex).
IOW, with that series in, we have a fully functional Xenomai 3.x code
base for the most recent kernel releases running on top of the I-pipe,
still not y2038-safe though. According to several discussions which took
place during the Xenomai community meetings, my understanding is that
your y2038 work lives on top of that code base. As we progress with
merging the rest of my tree in, we will gain the ability to run on top
of Dovetail as well for x86, arm and arm64, so that we can move from
running I-pipe/v5.4 to Dovetail/v5.10 and beyond (Dovetail is already on
track for v5.12).
> I wonder about the effect of splitting the assignments into separate
> tv_sec and tv_nsec assignements. I know this pattern from getting aware
> of different paddings between kernel and user space in case we handle a
> compat application, but this is all library stuff and compat
> applications should use the compat syscalls which hopefully care about
> different paddings...
>
It is not related to padding, this is only a matter of having differents
C types on both sides of the assignment: struct timespec vs struct
__user_old_timespec. As mentioned in the log, this series aims at
clearly delimiting the user / kernel boundary wrt time specification,
so we have different types on both sides. This was intended as prep work
before the y2038 issue is addressed on your end, in order to clarify the
interface. If you don't need it eventually, just drop it as part of your
series making Xenomai y2038-safe.
--
Philippe.
next prev parent reply other threads:[~2021-03-31 8:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-27 9:54 [PATCH 0/8] y2038 groundwork Philippe Gerum
2021-03-27 9:54 ` [PATCH 1/8] cobalt/kernel: y2038: convert struct timespec to timespec64 Philippe Gerum
2021-03-27 9:54 ` [PATCH 2/8] cobalt/mutex: Bring back ia32 support for mutex_timedwait Philippe Gerum
2021-04-07 16:35 ` Jan Kiszka
2021-04-07 16:57 ` Philippe Gerum
2021-03-27 9:54 ` [PATCH 3/8] cobalt/mqueue: Bring back ia32 support for mq_timed{send, receive} Philippe Gerum
2021-03-27 9:54 ` [PATCH 4/8] lib: y2038: convert to internal timespec type Philippe Gerum
2021-03-30 21:20 ` Florian Bezdeka
2021-03-31 8:13 ` Philippe Gerum [this message]
2021-03-31 9:03 ` Philippe Gerum
2021-03-31 15:58 ` Florian Bezdeka
2021-03-27 9:54 ` [PATCH 5/8] cobalt/kernel: y2038: convert struct itimerspec to itimerspec64 Philippe Gerum
2021-03-27 9:54 ` [PATCH 6/8] cobalt/kernel: y2038: convert struct timex to __kernel_timex Philippe Gerum
2021-03-27 9:54 ` [PATCH 7/8] cobalt/kernel: y2038: switch to new legacy type names Philippe Gerum
2021-03-27 9:54 ` [PATCH 8/8] cobalt/sem: y2038: Fixing the sem_timedwait syscall for 32 bit systems Philippe Gerum
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=87zgyjrbad.fsf@xenomai.org \
--to=rpm@xenomai.org \
--cc=chensong@tj.kylinos.cn \
--cc=florian.bezdeka@siemens.com \
--cc=jan.kiszka@siemens.com \
--cc=xenomai@xenomai.org \
/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.