linux-kernel - Re: [PATCH 2/9] ext4: Use pr_fmt and pr

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:	Mon, 19 Mar 2012 14:31:26 -0400
From:	Ted Ts'o <tytso@....edu>
To:	David Miller <davem@...emloft.net>
Cc:	anca.emanuel@...il.com, joe@...ches.com, adilger.kernel@...ger.ca,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/9] ext4: Use pr_fmt and pr_<level>

On Mon, Mar 19, 2012 at 02:14:02PM -0400, David Miller wrote:
> 
> Not the same, since moving to pr_*() allows us to standardize on
> kernel log output formatting, amongst other things, so it has a real
> practical impact unlike the spelling fix.

I've *already* gone far beyond the pr_fmt standardization, with the
ext4_msg() and ext4_error() system --- not only does it standardize
the prefix, it also standardizes information about the file system,
block numbers, inode numbers, so that it's easier for dmesg scrapers
to collate that information and use it for cluster-wide monitoring ---
which is happening *today* using printk() on far more machines than
probably anywhere else in the world.

One of the other reasons why I don't like the pr_* system because it
doesn't go far enough for the pain that's involved with making such a
change pervasively across the entire kernel.  What I'd really like to
see is a system that allows for semi-structured logging --- where
structured data such as the block device involved, whether it's at a
device driver driver, block layer, cfq or proportional I/O layer, or
file system layer, was consistently named, and squirted out a high
efficiency interface such as netlink or an ftrace ring buffer.

*That* would allow userspace to correlate errors from multiple kernel
subsystems for a particular device, and use a much more efficient and
less error-prone system than screen scraping dmesg output.  But the
proposed pr_* system is totally inadequate for this purpose, and if
all you're going to be able to do is make it slightly easier
standardize the prefix, it's just not interesting as far as I'm
concerned.

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