lkml.org 
[lkml]   [2012]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] printk: support structured and multi-facility log messages
    On Wed, Apr 04, 2012 at 11:14:25PM +0200, Kay Sievers wrote:
    > 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().

    Ok, that sounds good. I like the description, and implementation, so I
    have no objections to this patch, I'd be glad to queue it up through my
    tree to get testing in linux-next now if you want.

    > >> - 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.

    Ah, you are right, I forgot about the "real file" stuff with tail, the
    device node never gets updated with a timestamp.

    thanks,

    greg k-h
    --
    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-05 02:35    [W:0.026 / U:90.392 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site