Cc: Greg KH <gregkh@...>, Joe Perches <joe@...>, <linux-kernel@...>, <linux-s390@...>, <lf_kernel_messages@...>, Andrew Morton <akpm@...>, Michael Holzheu <holzheu@...>, Gerrit Huizenga <gh@...>, Randy Dunlap <randy.dunlap@...>, Jan Kara <jack@...>, Pavel Machek <pavel@...>, Sam Ravnborg <sam@...>, Jochen <jochen.voss@...>, Kunai Takashi <kunai@...>, Tim Bird <tim.bird@...>
On Fri, 2008-08-15 at 10:03 -0700, Tim Hockin wrote:
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.
--
