Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753278AbYHPSG6 (ORCPT ); Sat, 16 Aug 2008 14:06:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751729AbYHPSGu (ORCPT ); Sat, 16 Aug 2008 14:06:50 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]:38785 "EHLO mtagate3.de.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751708AbYHPSGt (ORCPT ); Sat, 16 Aug 2008 14:06:49 -0400 Subject: Re: [patch 1/3] kmsg: Kernel message catalog macros. From: Martin Schwidefsky Reply-To: schwidefsky@de.ibm.com To: Tim Hockin Cc: Greg KH , Joe Perches , 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?Q?Vo=DF?= , Kunai Takashi , Tim Bird In-Reply-To: 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> <20080815160355.GD23720@suse.de> Content-Type: text/plain Organization: IBM Corporation Date: Sat, 16 Aug 2008 20:06:30 +0200 Message-Id: <1218909990.6037.28.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2616 Lines: 57 On Fri, 2008-08-15 at 10:03 -0700, Tim Hockin wrote: > On Fri, Aug 15, 2008 at 9:03 AM, Greg KH wrote: > >> 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. > > Sorry, I never meant to imply that dev_printk() was to be ignored, my > examples was meant to be trivial to demonstrate :) dev_printk() is > good. We should keep it :) The invention of dev_printk was a good thing. It adds structure to the messages if it is about a device. Before we had a simple printk that did or did not include information about the device driver and the device name. dev_printk makes sure that this information is always added. BUT, what dev_printk does not do is to make sure that the message can be uniquely identified so that the description of the message can be found in the message catalog. Our approach is to combine the driver name and a simple index into a message tag. The original dev_printk remains almost unchanged. A typical hunk in the code looks like this: @@ -24,8 +27,8 @@ static int zfcp_ccw_probe(struct ccw_dev down(&zfcp_data.config_sema); if (zfcp_adapter_enqueue(ccw_device)) { - dev_err(&ccw_device->dev, - "Setup of data structures failed.\n"); + kmsg_dev_err(73, &ccw_device->dev, + "Setup of data structures failed.\n"); retval = -EINVAL; } up(&zfcp_data.config_sema); The kmsg_dev_printk still has almost the same structure, only the message id is added. There is one real difference though: the driver name is specified with KMSG_COMPONENT and not via dev_driver_string(dev). We do that so that the kmsg-doc script can actually find the driver name. The dev_driver_string(dev) is dynamic and a static tool has a hard time to find the actual driver string. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/