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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 Apr 2012 09:46:09 +0200
From:	Kay Sievers <kay@...y.org>
To:	Joe Perches <joe@...ches.com>
Cc:	Greg Kroah-Hartmann <greg@...ah.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] printk: support structured and multi-facility log messages

On Thu, Apr 5, 2012 at 02:40, Joe Perches <joe@...ches.com> 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@...y.org>
>> > > 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/