lkml.org 
[lkml]   [2012]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] printk: support structured and multi-facility log messages
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.

--
Jiri Kosina
SUSE Labs


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