[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 4, 2012 at 23:05, Greg Kroah-Hartmann <> 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-04-04 23:17    [W:0.022 / U:39.452 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site