key/value-pairs for improved printk()

key/value-pairs for improved printk()

[Dan Luedtke]

Hello everyone,

I'd like to start a discussion about possible key/value pairs for
printk() used by filesystem drivers.

I am refering to the following message, please skim through it, if you
haven't already:
> from:       Kay Sievers kay@vrfy.org via vger.kernel.org 
> to:         linux-kernel@vger.kernel.org
> date:       Wed, Apr 4, 2012 at 9:59 PM
> subject:    [PATCH] printk: support structured and multi-facility log
>             messages
> Message-ID: <1333569554.864.3.camel@mop>

Kay suggests improving printk() by adding key/value-formatted informaton
to log events.

Kay wrote:
> This patch extends printk() to be able to attach arbitrary key/value
> pairs to logged messages, to carry machine-readable data which
> describes the context of the log message at time of its
> creation.

I know this is a very early stage, but the earlier we start discussing
this issue, the less uncrontrolled growth there will be when this is
going to be used widely some day.


To throw something in the ring, I suggest we append all printk() after
mounting (e.g. fill_super when autodetecting a fs) with key/value pairs
like
  filesystem=mycoolfs
  device=sda1
  success=true

I hope this gets the discussion started!

Greetings,
danrl

-- 
Dan Luedtke
http://www.danrl.de

Re: key/value-pairs for improved printk()

[Al Viro]

On Fri, Apr 06, 2012 at 10:23:08PM +0200, Dan Luedtke wrote:

> To throw something in the ring, I suggest we append all printk() after
> mounting (e.g. fill_super when autodetecting a fs) with key/value pairs
> like
>   filesystem=mycoolfs
>   device=sda1
>   success=true
> 
> I hope this gets the discussion started!

You've missed the all-important
    bikeshed_colour=

-- 
Those who can - do, those who cannot - sit on the committees discussing how
the increasingly pointless things should be done

Re: key/value-pairs for improved printk()

[Kay Sievers]

On Sat, Apr 7, 2012 at 01:58, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Fri, Apr 06, 2012 at 10:23:08PM +0200, Dan Luedtke wrote:
>
>> To throw something in the ring, I suggest we append all printk() after
>> mounting (e.g. fill_super when autodetecting a fs) with key/value pairs
>> like
>>   filesystem=mycoolfs

Filesystem types can be reliably derived from the major:minor of the
superblock, even for non-device-backed mounts. I don't think that is
needed. A "DEVICE=b0:27" would be enough for most, if not all, use
cases.

>>   device=sda1

The time of assuming single-device mounts and filesystems should be
over. I don't think any new stuff should appear that way in any
export, especially not with the textual device name, when we have
reliably working dev_t numbers already.

>>   success=true

Not sure if that's really useful, we either mounted it or we didn't.
And how would a failure look like success=failed-with-error-7.

>> I hope this gets the discussion started!
>
> You've missed the all-important
>    bikeshed_colour=

That sounds useful, and it's nicely machine-readable. It think it
should be all uppercase, and to avoid localization problems we should
assign every color a UUID so that it looks like:
"BIKESHED_COLOR=fae73a2d-0a20-4b70-bd5a-7e9af2894508 :)".

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html