From: Luis Chamberlain <mcgrof@kernel.org>
To: Chaitanya Kulkarni <chaitanyak@nvidia.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Bart Van Assche <bvanassche@acm.org>,
"yi.zhang@redhat.com" <yi.zhang@redhat.com>,
"sagi@grimberg.me" <sagi@grimberg.me>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: can't run nvme-mp blktests
Date: Fri, 15 Apr 2022 10:59:37 -0700 [thread overview]
Message-ID: <YlmyiXBHyqtDQ+g9@bombadil.infradead.org> (raw)
In-Reply-To: <587c14e7-2b7e-74ac-377b-6faafcb829e4@nvidia.com>
On Fri, Apr 15, 2022 at 05:58:16AM +0000, Chaitanya Kulkarni wrote:
> On 4/14/22 22:20, Christoph Hellwig wrote:
> > On Wed, Apr 13, 2022 at 03:46:16PM -0700, Bart Van Assche wrote:
> >> I'm not sure whether the nvme-mp tests test any code that is not yet tested by
> >> any nvme or srp test. How about removing these tests since these tests make
> >> it harder than necessary to run blktests?
> >
> > I haven't looked at the details recently, but if these tests still are
> > basically a copy and paste of the srp mpath tests I'm all for removing
> > them!
>
> If it doesn't add a new test coverage in the blktest framework
> then please remove.
That's about 3 block folks not being sure whether or not it helps. And
the complexities of it, to test it, requiring a different kernel seems
just stupid. So I'm going to drop the tests from kdevops and not bother
with them.
With regards to srp tests there seems to be two modules to use. Do we
want to prioritize both just as much? If so then I'll just create two
guests for srp tests.
Luis
next prev parent reply other threads:[~2022-04-15 17:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-13 0:24 can't run nvme-mp blktests Luis Chamberlain
2022-04-13 3:02 ` Yi Zhang
2022-04-13 17:38 ` Luis Chamberlain
2022-04-13 4:53 ` Christoph Hellwig
2022-04-13 17:38 ` Luis Chamberlain
2022-04-13 17:41 ` Christoph Hellwig
2022-04-13 18:12 ` Luis Chamberlain
2022-04-15 5:22 ` Christoph Hellwig
2022-04-13 22:46 ` Bart Van Assche
2022-04-15 5:20 ` Christoph Hellwig
2022-04-15 5:58 ` Chaitanya Kulkarni
2022-04-15 17:59 ` Luis Chamberlain [this message]
2022-04-15 18:09 ` Bart Van Assche
2022-04-20 10:36 ` Hannes Reinecke
2022-04-21 17:56 ` Luis Chamberlain
2022-04-15 18:06 ` Bart Van Assche
2022-04-20 10:29 ` Hannes Reinecke
2022-04-13 5:53 ` Bart Van Assche
2022-04-13 18:08 ` Luis Chamberlain
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=YlmyiXBHyqtDQ+g9@bombadil.infradead.org \
--to=mcgrof@kernel.org \
--cc=bvanassche@acm.org \
--cc=chaitanyak@nvidia.com \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=yi.zhang@redhat.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.