linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Hannes Reinecke <hare@suse.de>
Cc: "Elliott, Robert (Server Storage)" <Elliott@hp.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>,
	Prarit Bhargava <prarit@redhat.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Kay Sievers <kay@vrfy.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>,
	"yrl.pp-manager.tt@hitachi.com" <yrl.pp-manager.tt@hitachi.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Subject: Re: [PATCH RESEND] scsi: Output error messages using structured printk in single line
Date: Thu, 22 May 2014 02:06:51 -0700	[thread overview]
Message-ID: <20140522090651.GA14854@infradead.org> (raw)
In-Reply-To: <537C4822.6000204@suse.de>

On Wed, May 21, 2014 at 08:30:58AM +0200, Hannes Reinecke wrote:
> While this works reasonably well for most things, printing out
> decoded sense with just one line (and not end up in massive switch()
> statements) is near impossible.
> 
> Plus you'll end up having to use a static buffer at one point, which
> again increases the stack size.
> 
> The alternative approach as discussed at LSF is to move scsi_logging
> over to tracing. There is already some coding for scsi tracing, but
> in most cases it just duplicates existing logging statements.
> So if we were to replace the entire scsi_logging infrastructure
> with scsi tracing most of the issues (like chopped-up CDBs) would
> be gone.
> Plus we would have a far better control about _what_ is being printed.
> 
> And yes, I do have some patches for that :-)

I think any detailed logging of sense codes, cdbs and co should move
to tracing.  In fact generally any non-defauly logging probably is
better off in the tracing subsystems, but there might be a few
exceptions.


  reply	other threads:[~2014-05-22  9:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27  4:17 [PATCH RESEND] scsi: Output error messages using structured printk in single line Yoshihiro YUNOMAE
2014-02-27  4:19 ` Yoshihiro YUNOMAE
2014-05-21  2:22 ` James Bottomley
2014-05-21  3:18   ` Elliott, Robert (Server Storage)
2014-05-21  6:30     ` Hannes Reinecke
2014-05-22  9:06       ` Christoph Hellwig [this message]
2014-05-26  8:09       ` Yoshihiro YUNOMAE

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20140522090651.GA14854@infradead.org \
    --to=hch@infradead.org \
    --cc=Elliott@hp.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=hare@suse.de \
    --cc=hidehiro.kawai.ez@hitachi.com \
    --cc=kay@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=prarit@redhat.com \
    --cc=yoshihiro.yunomae.ez@hitachi.com \
    --cc=yrl.pp-manager.tt@hitachi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).