Re: [PATCH] printk, allow different timestamps for printk.time [v2]

[Prarit Bhargava]

On 02/08/2016 10:51 AM, Petr Mladek wrote:
> On Thu 2016-02-04 12:03:27, Prarit Bhargava wrote:
>>
>>
>> On 02/04/2016 11:48 AM, Petr Mladek wrote:
>>> On Thu 2016-01-28 07:43:49, Prarit Bhargava wrote:
>>>> +static u64 printk_get_ts(void)
>>>> +{
>>>> +	u64 mono, offset_real;
>>>> +
>>>> +	if (printk_time == 0)
>>>> +		return 0;
>>>> +
>>>> +	if (printk_time == 1)
>>>> +		return local_clock();
>>>> +
>>>> +	mono = ktime_get_log_ts(&offset_real);
>>>> +
>>>> +	if (printk_time == 2)
>>>> +		return mono;
>>>> +
>>>> +	return mono + offset_real;
>>>
>>> At least dmesg is not capable to read the absolute size of the
>>> real time. It expects offset against the start of the timekeeping
>>> stuff or so. I get this:
>>>
>>> $> dmesg | tail -n 5
>>> [    7.128924] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>> [    0.000000] printk: timestamp set to 0.
>>
>> ^^^ Hmm ... I'll have to think about that.
>>
>>> [  179.983704] printk: timestamp set to 1.
>>> [  181.895655] printk: timestamp set to 2.
>>> [1454602412.026424] printk: timestamp set to 3.
>>>
>>> $dmesg -T -S | tail -n 5
>>> [Thu Feb  4 17:10:34 2016] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>> [Thu Feb  4 17:10:27 2016] printk: timestamp set to 0.
>>> [Thu Feb  4 17:13:26 2016] printk: timestamp set to 1.
>>> [Thu Feb  4 17:13:28 2016] printk: timestamp set to 2.
>>> [Fri Mar 10 09:23:59 2062] printk: timestamp set to 3.
>>
>> Yes, this is a known issue that someone else previously brought to my attention
>> on LKML.
> 
> It was me ;-)
> 
>> I will have to modify dmesg once this code is stabilized.
> 
> But how will dmesg detect when the time is a real time or an offset?
> There is still a bit available in struct printk_log in the flags
> variable but...
> 
> Also note that there are more tools that might need to get updated.
> For example, "crash" and maybe "gdb" are able to print the messages
> from the crashdump.
> 
> I still think that it might be easier to convert the real time to
> the offset before storing it.

Hmm ... good point.  I guess I was still thinking about my original patch that
had introduced /sys/modules/printk/parameters/clock which userspace could read.

tglx, any objection to the suggested changes here?  I would have to modify all
the configs, etc. so that CONFIG_PRINTK_TIME was an int instead of a bool.

P.