lkml.org 
[lkml]   [2008]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 1/3] kmsg: Kernel message catalog macros.
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@suse.cz>
SUSE Labs, CR


\
 
 \ /
  Last update: 2008-08-11 12:57    [W:0.097 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site