[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxa8gtN54KD48mf7_mNnMdiduhJ5GTKmJmf_VgLkSZ2fQ@mail.gmail.com>
Date: Tue, 14 Nov 2017 14:37:39 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mark Salyzyn <salyzyn@...roid.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Petr Mladek <pmladek@...e.com>,
LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Prarit Bhargava <prarit@...hat.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [GIT pull] printk updates for 4.15
On Tue, Nov 14, 2017 at 2:10 PM, Mark Salyzyn <salyzyn@...roid.com> wrote:
> On 11/14/2017 01:29 PM, Linus Torvalds wrote:
>>
>> And then maybe you can send a single patch that changes *ONLY*
>> print_time(), with an explanation of how Android uses
>> CONFIG_PRINTK_TIME and would like that to be realtime instead of the
>> monotonic clock that we traditionally use.
>
> print_time() uses msg->ts_nsec; and AFAIK that needs to be in reference to
> the timebase.
I'd suggest simply adding another time to the internal 'struct
printk_log' (and probably just set it in "log_store()").
Doesn't that seem much simpler and more targeted?
And exactly because it's targeted and only changes that one thing, now
people that don't run Android, and have systemd that actually looks at
that timestamp, can _also_ enable that wall clock output if they want
to, without it impacting timestamps at all.
In fact, I would expect that at that point you actually would want to
have multiple different formats that don't necessarily have anything
to do with the clock source, but simply with the formatting.
Do you want wallclock to be shown in UTC? Do you want to show it in
the system timezeone? Do you want to always show the full resolution,
or do you want to show something that takes the previous log entry
into account, so it only shows the date if it has actually changed,
and maybe shows the time as just a delta if it is small?
Because now it's clearly about the freeflowing _text_, not about the
timestamp that is processed by tools.
The text field done by print_time() really is _that_ different from
the timestamp field that is exposed to tools.
Yes, somebody might still be parsing it, and maybe then you need to
set that text field to a legacy format anyway, but at least it's a
whole lot easier to explain what's going on.
Linus
Powered by blists - more mailing lists