Re: [PATCH] printk: support structured and multi-facility log messages

[Greg Kroah-Hartmann <greg@kroah.com>]

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