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]
Message-ID: <20120319183126.GA6031@thunk.org>
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-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ