LKML Archive on
help / color / mirror / Atom feed
From: Tejun Heo <>
To: Andrew Morton <>
Subject: Re: [PATCHSET] printk: implement printk_header() and merging printk, take #3
Date: Thu, 14 Feb 2008 09:40:51 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Andrew Morton 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");
>>  output:
>>   <6>ata1.00: ATA 7, 1024 sectors
>>   <6>ata1.00  everything seems dandy
> And that looks like an awful lot of fuss.  Is it really worth doing?

In the above example, s/mprintk(/mprintk_flush(/ and

Can you please take a look at ata_eh_link_report() in
drivers/ata/libata-eh.c?  Currently, it has some problems.

* All that it wants to do is printing some messages but it's awfully
complex with temp bufs and super-long printk calls containing optional %s's.

* status / error decode print outs are printed separately from cmd/res
making it difficult to tell how they are grouped.  Putting them together
would require allocating another temp buf(s) and adding extra %s's to
cmd/res printout.

* For timeouts, result TF isn't available and thus res printout is
misleading.  res shouldn't be printed after timeouts.  This would
require allocating yest another temp buf and separating out res printing
into separate snprintf.

I was trying to do this and got fed up with all the tricks in the
function.  The only sane way out is to build messages piece-by-piece
into a buffer and print it at once.  The eh message is gigantic and I
needed to allocate the buffer elsewhere than stack.
ata_eh_link_report() fortunately has fixed place for that -
ap->sector_buf - but let's assume there was no such buffer for the
discussion.  I'm still not too sure whether it's wise to use sector_buf
for message building anyway.

The only way is to malloc the buffer.  Once the buffer is available,
building message using snprintf is a bit cumbersome but is okay.  The
problem is that malloc can fail.  To handle that case, we basically need
to do

  if (buf)
     printed += snprintf(buf + printed, len - printed, ...);

which is very cumbersome, so we need a wrapper around the above.  As the
wrapper needs to control when the message goes out, a flush function is
necessary too.  Combine those with overflow handling - mprintk.

Similar problem exists for ata_dev_configure() in
drivers/ata/libata-core.c although it's a bit better there.  Please take
a look at the fifth patch.  It doesn't remove a lot of lines but it
streamlines both functions significantly.  For ata_dev_configure(),
message reporting becomes what the function does secondarily while
configuring the device, not something it's structured around.



  reply	other threads:[~2008-02-14  0:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-13  9:09 Tejun Heo
2008-02-13  9:09 ` [PATCH 1/5] printk: keep log level on multiline messages Tejun Heo
2008-02-13  9:09 ` [PATCH 2/5] printk: implement [v]printk_header() Tejun Heo
2008-02-13  9:09 ` [PATCH 3/5] printk: implement merging printk Tejun Heo
2008-02-13  9:09 ` [PATCH 4/5] printk: add Documentation/printk.txt Tejun Heo
2008-02-13  9:09 ` [PATCH 5/5] libata: make libata use printk_header() and mprintk Tejun Heo
2008-02-13 23:57 ` [PATCHSET] printk: implement printk_header() and merging printk, take #3 Andrew Morton
2008-02-14  0:40   ` Tejun Heo [this message]
2008-02-14  1:09     ` Andrew Morton
2008-02-14  1:26       ` Tejun Heo
2008-02-15  1:49         ` Tejun Heo
2008-02-15  2:27           ` Andrew Morton
2008-02-15  2:36             ` Tejun Heo
2008-02-15  2:50               ` Andrew Morton
2008-02-15  3:16                 ` Tejun Heo
2008-02-16 14:13                   ` Mark Lord
2008-02-14 16:29     ` Mark Lord

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCHSET] printk: implement printk_header() and merging printk, take #3' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).