lkml.org 
[lkml]   [2012]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] printk: support structured and multi-facility log messages
On Wed, Apr 4, 2012 at 23:05, Greg Kroah-Hartmann <greg@kroah.com> wrote:
> On Wed, Apr 04, 2012 at 09:59:14PM +0200, Kay Sievers 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
>
> 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?

It's the notation udev uses to identify its devices internally. I just
added the above description to the source code so far. If we agree on
that, or some other scheme, we should definitely copy that into the
ABI docs. Along with a description of the semantics of the chardev
regarding open() poll() and seek().

>> - 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"?

Yeah, 'tail' might not work, it expects a regular file. This is a
chardev and it has not the regular file semantics which 'tail'
expects; 'cat' should work fine. 'Real' tools will just use poll() to
know when to get new messages out of the file descriptor.

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

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