[lkml]   [2012]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] printk: support structured and multi-facility log messages
On Wed, Apr 04, 2012 at 09:59:14PM +0200, Kay Sievers wrote:
> - Full-featured syslog facility value support. Different facilities
> can tag their messages. All userspace-injected messages enforce a
> facility value > 0 now, to be able to reliably distinguish them from
> the kernel-generated messages. Independent subsystems like a
> baseband processor running its own firmware, or a kernel-related
> userspace process can use their own unique facility values. Multiple
> independent log streams can co-exist that way in the same
> buffer. All share the same global sequence number counter to ensure
> proper ordering (and interleaving) and to allow the consumers of the
> log to reliably correlate the events from different facilities.
> - 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
> b12:8 - block dev_t
> c127:3 - char dev_t
> n8 - netdev ifindex
> +sound:card0 - subsystem:devname

I like this a lot, thanks for doing this.

Is there somewhere in Documentation/ABI that we can document this
interface so that people know what it is, what is defined, and how to
use it?

> - Support for multiple concurrent readers of /dev/kmsg, with read(),
> seek(), poll() support. Output of message sequence numbers, to allow
> userspace log consumers to reliably reconnect and reconstruct their
> state at any given time. After open("/dev/kmsg"), read() always
> returns *all* buffered records. If only future messages should be
> read, SEEK_END can be used. In case records get overwritten while
> /dev/kmsg is held open, or records get faster overwritten than they
> are read, the next read() will return -EPIPE and the current reading
> position gets updated to the next available record. The passed
> sequence numbers allow the log consumer to calculate the amount of
> lost messages.

I just noticed that 'tail -f' doesn't seem to work on /dev/kmsg, should
it? Or does it need to do something else to get "just the new ones"?


greg k-h

 \ /
  Last update: 2012-04-04 23:09    [W:0.151 / U:13.276 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site