Messages in this thread | | | Date | Mon, 11 Aug 2008 12:54:53 +0200 | From | Jan Kara <> | Subject | Re: [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
| |