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]

Date:	Sat, 7 Apr 2012 03:14:57 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Joe Perches <joe@...ches.com>
Cc:	Kay Sievers <kay@...y.org>, linux-kernel@...r.kernel.org,
	Greg Kroah-Hartmann <greg@...ah.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [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
--
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/