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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 4 Apr 2012 23:14:25 +0200
From:	Kay Sievers <kay@...y.org>
To:	Greg Kroah-Hartmann <greg@...ah.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] printk: support structured and multi-facility log messages

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

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

Kay
--
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/