Re: [PATCHSET] printk: implement printk_header() and merging printk, take #3

[Tejun Heo <htejun@gmail.com>]

Tejun Heo wrote:
> Hello,
> 
> Andrew Morton wrote:
>> On Thu, 14 Feb 2008 09:40:51 +0900
>> Tejun Heo <htejun@gmail.com> 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