public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Wagner <dwagner@suse.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Arun Easi <aeasi@marvell.com>,
	Nilesh Javali <njavali@marvell.com>,
	martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
	GR-QLogic-Storage-Upstream@marvell.com, bhazarika@marvell.com,
	agurumurthy@marvell.com
Subject: Re: [PATCH 2/6] qla2xxx: Add a generic tracing framework
Date: Tue, 19 Jul 2022 10:25:14 +0200	[thread overview]
Message-ID: <20220719082514.egsqevbaxl7a4prx@carbon.lan> (raw)
In-Reply-To: <20220718152243.21ad13e7@gandalf.local.home>

Hi Arun,

On Mon, Jul 18, 2022 at 03:22:43PM -0400, Steven Rostedt wrote:
> On Mon, 18 Jul 2022 12:02:26 -0700
> Arun Easi <aeasi@marvell.com> wrote:
> 
> > Many times when a problem was reported on the driver, we had to request 
> > for a repro with extended error logging (via driver module parameter) 
> > turned on. With this internal tracing in place, log messages that appear 
> > only with extended error logging are captured by default in the internal 
> > trace buffer.
> > 
> > AFAIK, kernel tracing requires a user initiated action to be turned on, 
> > like enabling individual tracepoints. Though a script (either startup or 
> > udev) can do this job, enabling tracepoints by default for a single 
> > driver, I think, may not be a preferred choice -- particularly when the 
> > trace buffer is shared across the kernel. That also brings the extra 
> > overhead of finding how this could be done across various distros.
> > 
> > For cases where the memory/driver size matters, there is an option to 
> > compile out this feature, plus choosing a lower default trace buffer size.

I am really asking the question why do we need to add special debugging
code to every single driver? Can't we try to make more use of generic
code and extend it if necessary?

Both FC drivers qla2xxx and lpfc are doing their own thing for
debugging/logging and I really fail to see why we can't not move towards
a more generic way. Dumping logs to the kernel log was the simplest way
but as this series shows, this is not something you can do in production
systems.

> You can enable an ftrace instance from inside the kernel, and make it a
> compile time option.
>
> 	#include <linux/trace_events.h>
> 	#include <linux/trace.h>
> 
> 	struct trace_array *tr;
> 
> 	tr = trace_array_get_by_name("qla2xxx");
> 	trace_array_set_clr_event(tr, "qla", NULL, true);
> 
> And now you have trace events running:
> 
>  # cat /sys/kernel/tracing/instances/qla/trace

Thanks Steve for the tip!

Daniel

  reply	other threads:[~2022-07-19  8:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-15  6:02 [PATCH 0/6] qla2xxx driver features Nilesh Javali
2022-07-15  6:02 ` [PATCH 1/6] qla2xxx: Add debugfs create/delete helpers Nilesh Javali
2022-07-15  6:02 ` [PATCH 2/6] qla2xxx: Add a generic tracing framework Nilesh Javali
2022-07-18  8:54   ` Daniel Wagner
2022-07-18 19:02     ` Arun Easi
2022-07-18 19:22       ` Steven Rostedt
2022-07-19  8:25         ` Daniel Wagner [this message]
2022-07-19 13:05           ` Steven Rostedt
2022-07-19 22:09           ` [EXT] " Arun Easi
2022-07-23  7:47             ` Steffen Maier
2022-07-25 13:56               ` Steven Rostedt
2022-07-19 21:06         ` Arun Easi
2022-07-19 21:40           ` Steven Rostedt
2022-07-19 22:09             ` Arun Easi
2022-07-19 22:17               ` Steven Rostedt
2022-07-20  4:43   ` kernel test robot
2022-07-15  6:02 ` [PATCH 3/6] qla2xxx: Add driver console messages tracing Nilesh Javali
2022-07-15  6:02 ` [PATCH 4/6] qla2xxx: Add srb tracing Nilesh Javali
2022-07-15  6:02 ` [PATCH 5/6] qla2xxx: Add NVMe parameters support in Auxiliary Image Status Nilesh Javali
2022-07-15  6:02 ` [PATCH 6/6] qla2xxx: Update version to 10.02.07.900-k Nilesh Javali

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=20220719082514.egsqevbaxl7a4prx@carbon.lan \
    --to=dwagner@suse.de \
    --cc=GR-QLogic-Storage-Upstream@marvell.com \
    --cc=aeasi@marvell.com \
    --cc=agurumurthy@marvell.com \
    --cc=bhazarika@marvell.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=njavali@marvell.com \
    --cc=rostedt@goodmis.org \
    /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