From: Mark Salyzyn <salyzyn@android.com>
To: Petr Mladek <pmladek@suse.com>, Prarit Bhargava <prarit@redhat.com>
Cc: linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
John Stultz <john.stultz@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Stephen Boyd <sboyd@codeaurora.org>,
Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Christoffer Dall <cdall@linaro.org>,
Deepa Dinamani <deepa.kernel@gmail.com>,
Ingo Molnar <mingo@kernel.org>,
Joel Fernandes <joelaf@google.com>,
Kees Cook <keescook@chromium.org>,
Peter Zijlstra <peterz@infradead.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
"Luis R. Rodriguez" <mcgrof@kernel.org>,
Nicholas Piggin <npiggin@gmail.com>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Olof Johansson <olof@lixom.net>,
Josh Poimboeuf <jpoimboe@redhat.com>,
linux-doc@vger.kernel.org
Subject: Re: [PATCH 3/3 v11] printk: Add monotonic, boottime, and realtime timestamps
Date: Fri, 15 Sep 2017 07:29:43 -0700 [thread overview]
Message-ID: <4cf75f3b-7d46-9e6c-3929-881f013f1c77@android.com> (raw)
In-Reply-To: <20170915132808.GL2908@pathway.suse.cz>
On 09/15/2017 06:28 AM, Petr Mladek wrote:
> I am still slightly nervous that external tools would need updating.
> Also they might have troubles to interpret the time stamps especially
> when the source is changed at runtime via
> /sys/module/printk/parameters/time.
My comment below is a rehash/summary:
In the discussion, it appears that DAC protection is enough to prevent
flippant changes. The use cases I can imagine for runtime alteration
fall in two groups, late boot changes after all disks are mounted and
the application layers have started; or as an aid to debugging where the
deliberate nature can be accounted for. Change it, erase the logs is the
KISS solution, so the tools do not have to 'sniff' the stream for
dynamic changes, likely getting the 'leader' wrong, checking
/sys/module/printk/parameters/time for the current/last timebase.
To mitigate the 'leader' issue, or post-mortem/off-machine
interpretation, really for the debugging corner case IMHO, I had
proposed that local, and perhaps monotonic, time print as-is as they are
almost(?) imperceptibly different, but that realtime add a U suffix (to
denote time is UTC), and that boottime add a B suffix (well, because) so
that tools can discern. Monotonic could have a M suffix if it is really
a stickler. This proposal would require more disruptive tool
modifications and should be scoped as a separate effort. I do expect a
debate regarding upper and lower case ...
I have a patch waiting in the wings here where disruptive time changes
(suspend/resume/hibernate/restore; maybe date(1), ntpd(8) or embedded
systems LTE hardware time updates) will report dual timestamps so that
resynchronization and tracking can happen in post-mortem on the stream,
I expect to use the above proposal for the 'second' occasional timestamp.
-- Mark
next prev parent reply other threads:[~2017-09-15 14:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-05 12:06 [PATCH 0/3 v11] printk: Add new timestamps Prarit Bhargava
2017-09-05 12:06 ` [PATCH 1/3 v11] time: Make fast functions return 0 before timekeeping is initialized Prarit Bhargava
2017-09-05 12:15 ` Thomas Gleixner
2017-09-15 13:42 ` Prarit Bhargava
2017-09-05 12:06 ` [PATCH 2/3 v11] timekeeping: Provide NMI safe access to clock realtime Prarit Bhargava
2017-09-05 12:06 ` [PATCH 3/3 v11] printk: Add monotonic, boottime, and realtime timestamps Prarit Bhargava
2017-09-13 18:30 ` Mark Salyzyn
2017-09-15 13:28 ` Petr Mladek
2017-09-15 14:29 ` Mark Salyzyn [this message]
2017-09-17 10:46 ` Sergey Senozhatsky
2017-09-19 11:52 ` Prarit Bhargava
2017-09-15 14:40 ` Prarit Bhargava
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=4cf75f3b-7d46-9e6c-3929-881f013f1c77@android.com \
--to=salyzyn@android.com \
--cc=Jason@zx2c4.com \
--cc=akpm@linux-foundation.org \
--cc=cdall@linaro.org \
--cc=corbet@lwn.net \
--cc=deepa.kernel@gmail.com \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=joelaf@google.com \
--cc=john.stultz@linaro.org \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=mingo@kernel.org \
--cc=npiggin@gmail.com \
--cc=olof@lixom.net \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=prarit@redhat.com \
--cc=rostedt@goodmis.org \
--cc=sboyd@codeaurora.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®