From: keith.busch@intel.com (Keith Busch)
Subject: [PATCH v2 1/1] nvmet: debug namespace noiob boundary emulation
Date: Thu, 8 Nov 2018 15:19:28 -0700 [thread overview]
Message-ID: <20181108221928.GC2932@localhost.localdomain> (raw)
In-Reply-To: <79a9960e-9d6d-220b-64b7-91dec2edc85a@grimberg.me>
On Thu, Nov 08, 2018@02:11:00PM -0800, Sagi Grimberg wrote:
> > > Useful to exercise the host driver to noiob support without
> > > having device that actually require it. name it with a debug
> > > prefix such that it is clear that its a debug feature.
> >
> > I'd really prefer to have a new CONFIG_NVME_TARGET_DEBUG
> > or similar config symbol so that we can not build these purely
> > debug knobs if desired.
>
> Really? I don't think this is worth it, we already have a tone of
> build time config options (https://lwn.net/Articles/733418/) and having
> another knob for small debug options for our nvmet is not helping.
> Also it will also introduce some annoying ifdefs and more 0-day
> testing complaints in the future. And, it is also sometimes annoying
> to have to rebuild a kernel (or module) especially when debugging on
> a station without access to modify the running source code.
>
> So I'm not sure I agree with this preference. But I'm not completely
> against it, can we have more people share their thoughts here?
I'd honestly prefer the nvme target simply provide useful functionality
for end users rather than take on the responsibility of a test vehicle
for host drivers.
I don't contribute much to the target, though, so I'd yield to those who
do if they really consider these features to be worth maintaining.
prev parent reply other threads:[~2018-11-08 22:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-30 17:57 [PATCH v2 1/1] nvmet: debug namespace noiob boundary emulation Sagi Grimberg
2018-10-30 17:57 ` [PATCH v2 2/1 nvmetcli] nvmet: add namespace debug attr group Sagi Grimberg
2018-10-30 20:36 ` [PATCH v2 1/1] nvmet: debug namespace noiob boundary emulation Chaitanya Kulkarni
2018-11-08 9:12 ` Christoph Hellwig
2018-11-08 22:11 ` Sagi Grimberg
2018-11-08 22:19 ` Keith Busch [this message]
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=20181108221928.GC2932@localhost.localdomain \
--to=keith.busch@intel.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).