Messages in this thread |  | | | Date | Wed, 4 Apr 2012 17:31:42 -0700 | | From | Greg Kroah-Hartmann <> | | 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@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/
|  |