lkml.org 
[lkml]   [2012]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] printk: support structured and multi-facility log messages
    On Thu, Apr 5, 2012 at 02:40, Joe Perches <joe@perches.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@vrfy.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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2012-04-05 09:49    [W:3.986 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site