From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754154AbaEVJHE (ORCPT ); Thu, 22 May 2014 05:07:04 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:59072 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751538AbaEVJG7 (ORCPT ); Thu, 22 May 2014 05:06:59 -0400 Date: Thu, 22 May 2014 02:06:51 -0700 From: Christoph Hellwig To: Hannes Reinecke Cc: "Elliott, Robert (Server Storage)" , James Bottomley , Yoshihiro YUNOMAE , Prarit Bhargava , "linux-scsi@vger.kernel.org" , Kay Sievers , "linux-kernel@vger.kernel.org" , Hidehiro Kawai , "yrl.pp-manager.tt@hitachi.com" , Masami Hiramatsu Subject: Re: [PATCH RESEND] scsi: Output error messages using structured printk in single line Message-ID: <20140522090651.GA14854@infradead.org> References: <20140227041738.31316.14684.stgit@yunodevel> <1400638922.2481.18.camel@dabdike> <94D0CD8314A33A4D9D801C0FE68B402956F1CF5A@G4W3202.americas.hpqcorp.net> <537C4822.6000204@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <537C4822.6000204@suse.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.