Re: [patch 1/3] kmsg: Kernel message catalog macros.

[Jan Kara]

On Sun 10-08-08 02:03:41, Martin Schwidefsky wrote:
...
> Then lets look at how this will look like. First a standard printk
> message and its conversion to kmsg:
> 	printk(KERN_WARNING
>                "cpcmd: could not allocate response buffer\n");
> vs.
> 	kmsg_warn(1, "The cpcmd kernel function failed "
>                      "to allocate a response buffer\n");
> 
> The message comes out as
> 	cpcmd: cound not allocate response buffer
> vs.
> 	cpcmd.1: The cpcmd kernel function failed to allocate a response buffer
> 
> As an example for a dev_printk I use a message from the zfcp driver:
> 	dev_warn(&req->adapter->ccw_device->dev,
>                  "The local link is down: no light detected.\n");
> vs.
>         kmsg_dev_warn(27, &req->adapter->ccw_device->dev,
>                  "The local link is down: no light detected.\n");
> 
> The dev_printk versus the original kmsg macro comes out as
> 	zfcp: 0.0.1234: The local link is down: no light detected.
> vs.
> 	zfcp.27: 0.0.1234: The local link is down: no light detected.
> 
> If I would just use dev_printk in kmsg_dev_warn as proposed by Greg:
> 	zfcp: 0.0.1234: zfcp.27: The  local link is down: no light detected.
> 
> If the message component is skipped from the message tag:
> 	zfcp: 0.0.1234: 27: The  local link is down: no light detected.
> 
> Is it just me who thinks that the later two message variants are crap? 
  If I may vote in this poll ;) I agree with you that the first two device
messages look better (more comprehensible) than the last two...

									Honza
-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/