Re: [PATCH] printk: support structured and multi-facility log messages

From: Kay Sievers
Date: Thu Apr 05 2012 - 03:46:26 EST


On Thu, Apr 5, 2012 at 02:40, Joe Perches <joe@xxxxxxxxxxx> wrote:
> On Wed, 2012-04-04 at 17:33 -0700, Greg Kroah-Hartmann wrote:
>> On Wed, Apr 04, 2012 at 04:51:20PM -0700, Joe Perches wrote:
>> > On Wed, 2012-04-04 at 21:59 +0200, Kay Sievers wrote:
>> > > From: Kay Sievers <kay@xxxxxxxx>
>> > > Subject: printk: support structured and multi-facility log messages
>> > []
>> > > This patch extends printk() to be able to attach arbitrary key/value
>> > > pairs to logged messages,
>> > How does it do that?
>> The implementation doesn't show that?
>
> Not so far as I can tell.
>
> How are arbitrary key/value pairs attached
> in a printk?

There are 120 lines in the changelog, and a 100 lines large comment
block in the source code, and another 50 lines spread over the code,
and the hexdump examples in it, and all that? Even without looking at
a single line of code, it should be explained from different
viewpoints more than once.

>> > > - Records consume almost the same amount, sometimes less memory than
>> > > Â the traditional byte stream buffer (if printk_time is enabled). The record
>> > > Â header is 16 bytes long, plus some padding bytes at the end if needed.
>> > > Â The byte-stream buffer needed 3 chars for the syslog prefix, 15 char for
>> > > Â the timestamp and a newline.
>> >
>> > I suggest using lzo on the string portion.
>>
>> As the used overall size is pretty much the same, that doesn't really
>> seem necessary to me.
>
> As dmesg output would still exist, compression could reduce
> the size of the duplicated logged output buffers significantly.

There are no other or duplicated buffers than the primary log buffer,
which is exactly the same buffer as today's printk() uses. When this
buffer is exported, the data is converted to a stream on-the-fly, and
it's a feature, that such stream is human readable and not compressed
output. I don't think there is much justification for a compression
overhead and the problems it would introduce.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/