[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0b7ab8a2-9ec9-8d0b-3e45-20610f3ab598@android.com>
Date: Thu, 20 Jul 2017 10:57:31 -0700
From: Mark Salyzyn <salyzyn@...roid.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Joe Perches <joe@...ches.com>,
Rasmus Villemoes <rasmus.villemoes@...vas.dk>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Alessandro Zummo <a.zummo@...ertech.it>,
Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
linux-rtc@...r.kernel.org
Subject: Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv]
On 07/20/2017 03:33 AM, Andy Shevchenko wrote:
> On Tue, 2017-07-18 at 12:57 -0700, Mark Salyzyn wrote:
>> On 07/18/2017 10:50 AM, Joe Perches wrote:
>>> On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote:
>>>> Recently I have noticed too many users of struct rtc_time that
>>>> printing
>>>> its content field by field.
>>>>
>>>> In this series I introduce %pt[dt][rv] specifier to make life a
>>>> bit
>>>> easier.
>>> Hey Andy.
>>>
>>> I just saw a patch with a printk for rtc time from Mark Salyzyn.
>>> https://lkml.org/lkml/2017/7/18/885
>>>
>>> Any idea if you want to push this extension?
>>>
>>> I like the concept and still think it could be extended a bit more.
>>>
>>> from: https://lkml.org/lkml/2017/6/8/1134
>>>
>>> My preference would be for %pt[type]<output style>
>>> where <type> is mandatory and could be:
>>>
>>> r for struct rtc_time
>>> 6 for time64_t
>>> k for ktime_t
>>> T for struct timespec64
>>> etc
>>>
>>> and <output style> has an unspecified default of
>>> YYYY-MM-DD:hh:mm:ss
>>>
>>> Perhaps use the "date" formats without the leading
>>> % uses for <output style> for additional styles.
>>>
>> YYYY-MM-DD hh:mm:ss.nnnnnnnnn ?
> As a separate modifier, yes.
>
> See my answer to subthread in patch 4.
>
It would probably need to take struct timespec64 as an argument. Pass by
structure might be difficult to swallow, so pass by pointer?
As for my need for this in my suspend/resume/hibernate/restore patch
set, we have already been told three times to _not_ report wall clock
time. I could imagine being a consumer of it in the future if we have
difficulty migrating the analysis tools ... so tepid support from me.
-- Mark
Powered by blists - more mailing lists