Tejun Heo wrote: > Hello, > > Andrew Morton wrote: >> On Thu, 14 Feb 2008 09:40:51 +0900 >> Tejun Heo <htejun@xxxxxxxxx> wrote: >> >>> Can you please take a look at ata_eh_link_report() in >>> drivers/ata/libata-eh.c? >> I did. Punishment? > > Heh.. :-) > >>> Currently, it has some problems. >> Yes, and the patches do clean that up. > > Yeap, it does. > >> ho hum. What tends to happen with this sort of thing is that fi we merge >> it, it ends up getting used more often than one expected... > > Hmmm... Okay. mprintk being printk, I'm not too sure how it can go over > usual expectations but well, yeah, that actually is my expectation. > >> If you stand back and squint at it, there are quite a few places where we >> do this sort of thing: allocate a buffer, squirt characters into it, >> reallocating and/or flushing as we proceed. All sysfs and procfs read-side >> code, for a start... > > printk is a special case, I think. It's the primary logging/debugging > method which can't fail and as it's mostly interpreted by human beings > (and developers in problematic cases), it has different maneuvering room > on errors - ie. it's far better to print messages w/o header or proper > log level than failing to print, which is quite different requirements > from other components. Andrew, any more comments or suggestions on how to proceed on this? One way or the other, I think this is a problem worth solving. Thanks. -- tejun - 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
