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-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
