From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756734AbYHOLVh (ORCPT ); Fri, 15 Aug 2008 07:21:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753374AbYHOLVR (ORCPT ); Fri, 15 Aug 2008 07:21:17 -0400 Received: from mx1.suse.de ([195.135.220.2]:53776 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752930AbYHOLVP (ORCPT ); Fri, 15 Aug 2008 07:21:15 -0400 Date: Fri, 15 Aug 2008 13:21:17 +0200 From: Jan Blunck To: Tim Hockin Cc: Greg KH , 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: <20080815112117.GP10078@bolzano.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: Organization: SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 (AG Nuernberg) User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 14, 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. 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. If I interpret Martins patches correctly he wants to be able to put add extended information to specific messages the kernel is printing. This is a good way to explain the rational of certain situations to people unwilling to read the sources ;) I don't think that he wants to unify all the printk's in the system. I don't think that reporting all errors "in the same way as an ATA error" makes any sense. That would just lead to very stupid and unnatural messages for all errors that are not like "ATA errors". Annotation of existing errors is a much more flexible and feasible solution to that problem.