From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759238AbYHOQG5 (ORCPT ); Fri, 15 Aug 2008 12:06:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753574AbYHOQGt (ORCPT ); Fri, 15 Aug 2008 12:06:49 -0400 Received: from ns1.suse.de ([195.135.220.2]:59122 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752143AbYHOQGs (ORCPT ); Fri, 15 Aug 2008 12:06:48 -0400 Date: Fri, 15 Aug 2008 09:03:55 -0700 From: Greg KH To: Tim Hockin Cc: Joe Perches , schwidefsky@de.ibm.com, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, lf_kernel_messages@lists.linux-foundation.org, Andrew Morton , Michael Holzheu , Gerrit Huizenga , Randy Dunlap , Jan Kara , Pavel Machek , Sam Ravnborg , Jochen =?iso-8859-1?B?Vm/f?= , Kunai Takashi , Tim Bird Subject: Re: [patch 1/3] kmsg: Kernel message catalog macros. Message-ID: <20080815160355.GD23720@suse.de> References: <20080730165656.118280544@de.ibm.com> <20080730171156.824640459@de.ibm.com> <1218733457.2651.11.camel@localhost> <1218769739.24527.76.camel@localhost> <20080815034419.GB803@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 14, 2008 at 10:33:10PM -0700, Tim Hockin wrote: > On Thu, Aug 14, 2008 at 8:44 PM, Greg KH wrote: > > > > What is wrong with what we have already agreed to standardise on here > > people? dev_printk() for devices! It uniquely shows the device, what > > driver is bound to it (if any), the bus id, and everything else. > > Part of the problem, imho, is the "if any" part. But I am more than happy to > build on existing solutions. All the world is not a dev, though. No, but way over half the kernel is. > I'd like to be able to report something like an OOM kill in (roughly) > the same way as an ATA error, and I want (though could be talked out > of) a way to tell these "events" (for lack of a better word) apart > from plain-old-printk()s. That's great, then create something that can handle both! Don't throw away some wonderful information that way over half the kernel has access to just because the minority doesn't. That would mean that we would loose information in those drivers overall. thanks, greg k-h