On Sat, 2008-01-19 at 07:58 +0900, Tejun Heo wrote: > Matt Mackall wrote: > > On Wed, 2008-01-16 at 10:00 +0900, Tejun Heo wrote: > >> And mprintk the following. > >> > >> code: > >> DEFINE_MPRINTK(mp, 2 * 80); > >> > >> mprintk_set_header(&mp, KERN_INFO "ata%u.%2u: ", 1, 0); > >> mprintk_push(&mp, "ATA %d", 7); > >> mprintk_push(&mp, ", %u sectors\n", 1024); > >> mprintk(&mp, "everything seems dandy\n"); > > > > I prefer Matthew Wilcox's stringbuf approach which does proper memory > > management and isn't specific to printk: > > > > http://www.ussg.iu.edu/hypermail/linux/kernel/0710.3/0517.html > > Yeap, that's generic and nice but I think both 'generic' and 'proper > memory management' are weakness if what you're trying to do is to > support collecting messages in pieces and putting it out via printk. > Please consider the following scenario. > > You're in an interrupt handler and detected a severe error condition > which should be notified to the user but the information is rather > complex and best built in pieces, so you create a stringbuf and does > sb_printf() to it w/ GFP_ATOMIC but alas memory allocation failed and > you end up printing "out of memory" unless you detect the failure and go > back and printk messages piece-by-piece manually. I would rather > assemble the message manually from the get-go into an on-stack buffer. I suppose. I still find this approach less than ideal, especially putting something potentially large on the stack. The dangers are perhaps worse than a malloc, really. I also don't like your interface much. Consider this alternative: struct mprintk *mp = mprintk_begin(KERN_INFO "ata%u.%2u: ", 1, 0); mprintk(mp, "ATA %d", 7); mprintk(mp, ", %u sectors\n", 1024); mprintk(mp, "everything seems dandy\n"); mprintk_end(mp); That keeps all the "normal" printks short and makes the flush more explict. Now we make mprintk_begin attempt to do a kmalloc of a moderate size (512 bytes?) and failing that, return null. Then mprintk can fall through to printk in the NULL case. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
