All of lore.kernel.org
 help / color / mirror / Atom feed
From: minwoo.im.dev@gmail.com (Minwoo Im)
Subject: [PATCH V5 1/5] nvme: Make trace common for host and target both
Date: Sun, 2 Jun 2019 10:47:38 +0900	[thread overview]
Message-ID: <20190602014737.GA28933@minwooim-desktop> (raw)
In-Reply-To: <20190601085016.GA6375@lst.de>

On 19-06-01 10:50:16, Christoph Hellwig wrote:
> > diff --git a/drivers/nvme/Makefile b/drivers/nvme/Makefile
> > index 0096a7fd1431..12f193502d46 100644
> > --- a/drivers/nvme/Makefile
> > +++ b/drivers/nvme/Makefile
> > @@ -1,3 +1,6 @@
> >  
> > +ccflags-y		+= -I$(src)
> > +obj-$(CONFIG_TRACING)	+= trace.o
> 
> this will always build the file into the kernel if CONFIG_TRACING,
> even if no nvme code is enabled.

Oh, thanks to point it out.

> And looking at the later patches I don't even think this sharing is
> worth it, as the actual trace points are pretty different.

That's why this patch series introduces DECLARE_EVENT_CLASS as a
template, and gives different events for it by DEFINE_EVENT.

> 
> I'd much prefer to have different implementations for host vs target for
> now instead of introducing a common library.  Maybe we could revisit
> that later if we end up having a lot of shared code.

As you know, nvmet handles not only nvme fabrics commands, but normal
commands in nvmet_req_init() and nvmet_req_complete().  Which means that
we already have a lot of shared codes in parsing point of view.

The host/trace.c provides parsing admin commands which can be used by
nvmet also.  I guess it's enough to be shared for host and target both.

I hope you can correct me if I missed someting here.

Thanks, Christoph.

  reply	other threads:[~2019-06-02  1:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-01  7:21 [PATCH V5 0/5] nvme-trace: Add support for fabrics command Minwoo Im
2019-06-01  7:21 ` [PATCH V5 1/5] nvme: Make trace common for host and target both Minwoo Im
2019-06-01  8:50   ` Christoph Hellwig
2019-06-02  1:47     ` Minwoo Im [this message]
2019-06-04  7:28       ` Christoph Hellwig
2019-06-04 10:39         ` Minwoo Im
2019-06-04 16:28           ` Sagi Grimberg
2019-06-01  7:21 ` [PATCH V5 2/5] nvme-trace: Support tracing fabrics commands from host-side Minwoo Im
2019-06-01  7:21 ` [PATCH V5 3/5] nvme: Introduce nvme_is_fabrics to check fabrics cmd Minwoo Im
2019-06-01  7:21 ` [PATCH V5 4/5] nvme-trace: Add tracing for req_init in target Minwoo Im
2019-06-01  7:21 ` [PATCH V5 5/5] nvme-trace: Add tracing for req_comp " Minwoo Im

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=20190602014737.GA28933@minwooim-desktop \
    --to=minwoo.im.dev@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.