On 07/25/2017 09:00 AM, Peter Zijlstra wrote:
> On Tue, Jul 25, 2017 at 08:17:27AM -0400, Prarit Bhargava wrote:
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index 5b1662ec546f..6cd38a25f8ea 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -1,8 +1,8 @@
>>  menu "printk and dmesg options"
>>  
>>  config PRINTK_TIME
>> -    int "Show timing information on printks (0-1)"
>> -    range 0 1
>> +    int "Show timing information on printks (0-3)"
>> +    range 0 3
>>      default "0"
>>      depends on PRINTK
>>      help
>> @@ -13,7 +13,8 @@ config PRINTK_TIME
>>        The timestamp is always recorded internally, and exported
>>        to /dev/kmsg. This flag just specifies if the timestamp should
>>        be included, not that the timestamp is recorded. 0 disables the
>> -      timestamp and 1 uses the local clock.
>> +      timestamp and 1 uses the local clock, 2 uses the monotonic clock, and
>> +      3 uses real clock.
>>  
>>        The behavior is also controlled by the kernel command line
>>        parameter printk.time=1. See 
>> Documentation/admin-guide/kernel-parameters.rst
> 
> 
> choice
>       prompt "printk default clock"
>       default PRIMTK_TIME_DISABLE
>       help
>        goes here
> 
>       config PRINTK_TIME_DISABLE
>       bool "Disabled"
>       help
>        goes here
> 
>       config PRINTK_TIME_LOCAL
>       bool "local clock"
>       help
>        goes here
> 
>       config PRINTK_TIME_MONO
>       bool "CLOCK_MONOTONIC"
>       help
>        goes here
> 
>       config PRINTK_TIME_REAL
>       bool "CLOCK_REALTIME"
>       help
>        goes here
> 
> endchoice
> 
> config PRINTK_TIME
>       int
>       default 0 if PRINTK_TIME_DISABLE
>       default 1 if PRINTK_TIME_LOCAL
>       default 2 if PRINTK_TIME_MONO
>       default 3 if PRINTK_TIME_REAL
> 
> 

Thanks for the above change.  I can see that makes the code simpler.

> Although I must strongly discourage using REALTIME, DST will make
> untangling your logs an absolute nightmare. I would simply not provide
> it.

I understand your concern, however, I've been in situations where REALTIME
stamping has pointed me in the direction of where a bug was.  Even with the
complicated logs I think it is worthwhile.

P.

Reply via email to