Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer

From: Kay Sievers <kay@vrfy.org>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Yinghai Lu <yinghai@kernel.org>, Joe Perches <joe@perches.com>,
	Ingo Molnar <mingo@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer
Date: Sun, 13 May 2012 23:48:18 +0200	[thread overview]
Message-ID: <CAPXgP139D4u2qrUEVTRbbddC_RbX5mR9QdmB5N+vqPMLekrknw@mail.gmail.com> (raw)
In-Reply-To: <CA+1xoqf5YbkOJgQJWOgck0NpqGzGtxtHHJASZKHvwVuBzkKK6A@mail.gmail.com>

On Sat, May 12, 2012 at 9:43 AM, Sasha Levin <levinsasha928@gmail.com> wrote:
> On Fri, May 11, 2012 at 5:47 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> Btw, I'd also *love* to see some model (eventually - not necessarily
>> now) where we could have the option of the time printouts being a bit
>> different (rather than just on/off). It would be very nice if we had
>> "relative" time printouts for events close together, so the rule could
>> be something like:
>>
>>  - if time is same as last line, pad with empty
>>
>>  - if time is more than a minute from last one, show an absolute value
>> of dd hh:mm:ss
>>
>>  - otherwise, show a relative value of +ss.mmmmmm
>>
>> So the on/off choice could be on/off/relative.
>>
>> Hmm?
>
> So I got something like this:
>
> # sleep 61 ; echo foo > /dev/kmsg ; sleep 61 ; echo bar > /dev/kmsg ;
> sleep 5 ; echo zoot > /dev/kmsg ; sleep 10 ; echo foo > /dev/kmsg ;
> echo bar > /dev/kmsg ; sleep 61 ; echo zoot > /dev/kmsg ; echo foo >
> /dev/kmsg
>
> [  673.222632] foo
> [  734.315249] bar
> [   +5.077527] zoot
> [  +10.235225] foo
> [   +0.002971] bar
> [  810.883085] zoot
> [   +0.003081] foo
>
> If that looks right,
> I can send a patch once this printf overhaul is
> stable

I just sent out the fix to restore the original multi-line behaviour,
I have nothing else queued in that area at the moment.

> unless Kay already plans on doing it as part of his work.

I'm busy making the prink() output look the same as it was before but
without the wrong continuation merges. New features need to wait a
little bit, so go ahead. :)

But I want to express, that I'm very interested in finding out if we
could switch to a 'better' clock source as we have today, which can
safely be translated to wall clock time not leaving the suspend time
out, and not jumping forth and back in time between logs from
different CPUs. I think that would be very useful for your patch too.

Kay