lkml.org 
[lkml]   [2012]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] printk: support structured and multi-facility log messages
From
Date
On Sat, 2012-04-07 at 03:14 +0200, Jiri Kosina wrote:
> On Fri, 6 Apr 2012, Joe Perches wrote:
>
> > > > - Output of dev_printk() is reliably machine-readable now. In addition
> > > > to the printed plain text message, it creates a log dictionary with the
> > > > following properties:
> > > > SUBSYSTEM= - the driver-core subsytem name
> > > > DEVICE=
> > > > b12:8 - block dev_t
> > > > c127:3 - char dev_t
> > > > n8 - netdev ifindex
> > > > +sound:card0 - subsystem:devname
> > >
> > > One of the questions that hasn't been raised yet, and which I personally
> > > consider crucial -- are we making printk() interface part of userspace ABI
> > > now by this?
> >
> > I hope not.
>
> And how exactly do we prevent that? It's a systematic and well-defined
> interface between kernel and userspace, and as such it's hard to not
> consider it to be ABI.
>
> > > Today, we are free to change any printk()s and not feel guilty about it at
> > > all. With this, we are making the whole thing much more systematic and
> > > friendly for automatic userspace consumption.
> >
> > It _may_ be that new KEYWORD=VALUE combinations may become systematic
> > and an ABI, but the content of the message is still arbitrary and should
> > be designated as changeable without notice.
>
> I bet there would be "you broke my userspace app because it was depending
> on the printk() you just removed" bugreport coming from someone very soon.
>
> We can then either start explaining why this structured and well-defined
> printk() is not ABI, or just don't allow for that to happen in the first
> place by keeping printk() what it has always been -- unstructured linear
> flow of log entries destined only to be read by humans.

I think the commit log is poor.

printk() is effectively unmodified.

Generic helpers like dev_printk() can have an extra bit
prepended in the form of device/class/name.

All dev_printk device/class/name does is show what device
emitted a message. It doesn't limit the message content.
The content of the message after that device/class/name
is still arbitrary.

No other use has been proposed, that's why I think it's
not all that valuable (yet?).

I do think that printk_emit, which I think is a bad name,
( maybe printk_tva() or printk_desc() ) has some value.

The record oriented change also has value as it can more
easily be optionally extended to compress/decompress the
text message to save memory space per record. Of course
that'd only be valuable when CONFIG_LOG_BUF_SHIFT is
large enough to gain something by using compression.




\
 
 \ /
  Last update: 2012-04-07 03:55    [W:0.046 / U:7.964 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site