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

    > - 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.024 / U:0.592 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site