From: Thomas Gleixner <tglx@linutronix.de>
To: Lukasz Majewski <lukma@denx.de>, Andrei Vagin <avagin@gmail.com>,
Dmitry Safonov <dima@arista.com>
Cc: GNU C Library <libc-alpha@sourceware.org>,
Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org
Subject: Re: [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces
Date: Fri, 30 Oct 2020 14:08:48 +0100 [thread overview]
Message-ID: <871rhfoo7z.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20201030110229.43f0773b@jawa>
Lukasz,
On Fri, Oct 30 2020 at 11:02, Lukasz Majewski wrote:
> I do have a question regarding the Linux time namespaces in respect of
> adding support for virtualizing the CLOCK_REALTIME.
>
> According to patch description [1] and time_namespaces documentation
> [2] the CLOCK_REALTIME is not supported (for now?) to avoid complexity
> and overhead in the kernel.
>
> Is there any plan to add support for it in a near future?
Not really. Just having an offset on clock realtime would be incorrect
in a number of ways. Doing it correct is a massive trainwreck.
For a debug aid, which is what you are looking for, the correctness
would not really matter, but providing that is a really slippery
slope.
If at all we could hide it under a debug option which depends on
CONFIG_BROKEN and emitting a big fat warning in dmesg with a clear
statement that it _is_ broken, stays so forever and any attempt to "fix"
it results in a permanent ban from all kernel lists.
Preferrably we don't go there.
Thanks,
tglx
next prev parent reply other threads:[~2020-10-30 13:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-30 10:02 [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces Lukasz Majewski
2020-10-30 13:08 ` Thomas Gleixner [this message]
2020-10-30 15:43 ` Lukasz Majewski
2020-10-30 13:58 ` Cyril Hrubis
2020-10-30 14:02 ` Zack Weinberg
2020-10-30 15:10 ` Thomas Gleixner
2020-10-30 16:58 ` Carlos O'Donell
2020-10-30 20:06 ` Thomas Gleixner
2020-10-30 22:19 ` Carlos O'Donell
2020-10-31 1:38 ` Thomas Gleixner
2020-11-03 12:43 ` Cyril Hrubis
2020-11-05 17:25 ` Carlos O'Donell
2020-11-07 0:47 ` Thomas Gleixner
2020-11-19 18:37 ` Carlos O'Donell
2020-11-20 0:14 ` Thomas Gleixner
2020-11-25 17:06 ` Petr Špaček
2020-11-25 20:37 ` Carlos O'Donell
2020-11-26 0:17 ` Thomas Gleixner
2020-11-26 3:05 ` Carlos O'Donell
2020-11-26 8:21 ` Andreas Schwab
2020-11-14 10:25 ` Pavel Machek
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=871rhfoo7z.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=arnd@arndb.de \
--cc=avagin@gmail.com \
--cc=dima@arista.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukma@denx.de \
/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.