[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120405003142.GA27595@kroah.com>
Date: Wed, 4 Apr 2012 17:31:42 -0700
From: Greg Kroah-Hartmann <greg@...ah.com>
To: Kay Sievers <kay@...y.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [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@...ah.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists