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]

Message-ID: <CAPXgP13+UjRsG_LBMd_KbqS=1p_7XA0TaPeXnWQUSdq1tYvW_Q@mail.gmail.com>
Date:	Thu, 5 Apr 2012 10:35:42 +0200
From:	Kay Sievers <kay@...y.org>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Joe Perches <joe@...ches.com>,
	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 10:08, Sam Ravnborg <sam@...nborg.org> wrote:
>> >
>> > 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.
>
> color me blind - but I could not find any example of how I specify
> key/value pairs when I use printk().
>
> I could find lots of internal information - that parts looks to
> be extensively documented - good.
>
> But how I as a user specify this I failed to find.
> Today I do:
>
>    printk(KERN_ERR "foobar is bad");
>
> But how is that extended to include the key/value pairs?

The use of structured data is mainly focused on subsystem specific
users. Like the block layer or the network stack could invent a bunch
of well-defined set of properties, and wrap the emission of these up
in some common subsystem logging functions for their drivers to use.
They would reflect common log events, meaningful in the context of a
specific subsystem.

Think of it more like the model how we handle properties in uevents,
it's a similar approach.

This is not so much intended to convert the (almost random) language
in slightly better (random) key/value pairs. Userpace, which is the
only reason to add that stuff in the first place, will need to know
how to make sense out of the passed values, so in the future, we will
need some kind of coordination per subsystem here.

For the current simple example in the patch, look where DEVICE= and
SUBSYSTEM= are passed through dev_printk() -> vprintk_emit() ->
log_store(), and then read through /dev/kmsg.

The output looks like something like this:
  http://people.freedesktop.org/~kay/dev-kmsg.txt

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/