All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 3/3] nvdimm: platform capabilities command line option
Date: Wed, 16 May 2018 09:22:08 +0200	[thread overview]
Message-ID: <20180516092208.4461c748@redhat.com> (raw)
In-Reply-To: <20180515230351.GA741@linux.intel.com>

On Tue, 15 May 2018 17:03:51 -0600
Ross Zwisler <ross.zwisler@linux.intel.com> wrote:

> On Thu, May 10, 2018 at 03:28:48PM +0200, Igor Mammedov wrote:
[...]
> 
> > Also an extra patch to for make check that will test setting 'cap'
> > would be nice (an extra testcase in tests/bios-tables-test.c)  
> 
> Hmm...I've been looking at this, and it doesn't look like there is any
> verification around a lot of the ACPI tables (NFIT, SRAT, etc).
as far as I recall NFIT and SRAT are verified against expected template
(limited but at least something)

Following commits can serve as an example:
 e0e5c85 test/acpi-test-data: add ACPI tables for dimmpxm test
 adae91c tests/bios-tables-test: add test cases for DIMM proximity

> I've verified my patch by interacting with a guest with various settings - is
> this good enough, or do you really want me to test the value (which I think
> would just be "do I get out what I put in at the command line") via the unit
> test infrastructure?
It would be better to add test especially for a new code.
The reason for it is to catch regressions down the road,
it also makes easier for maintainer to review/test series.

> Thank you for the review.

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Igor Mammedov <imammedo@redhat.com>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Haozhong Zhang <haozhong.zhang@intel.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	qemu-devel@nongnu.org, linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: Re: [Qemu-devel] [PATCH 3/3] nvdimm: platform capabilities command line option
Date: Wed, 16 May 2018 09:22:08 +0200	[thread overview]
Message-ID: <20180516092208.4461c748@redhat.com> (raw)
In-Reply-To: <20180515230351.GA741@linux.intel.com>

On Tue, 15 May 2018 17:03:51 -0600
Ross Zwisler <ross.zwisler@linux.intel.com> wrote:

> On Thu, May 10, 2018 at 03:28:48PM +0200, Igor Mammedov wrote:
[...]
> 
> > Also an extra patch to for make check that will test setting 'cap'
> > would be nice (an extra testcase in tests/bios-tables-test.c)  
> 
> Hmm...I've been looking at this, and it doesn't look like there is any
> verification around a lot of the ACPI tables (NFIT, SRAT, etc).
as far as I recall NFIT and SRAT are verified against expected template
(limited but at least something)

Following commits can serve as an example:
 e0e5c85 test/acpi-test-data: add ACPI tables for dimmpxm test
 adae91c tests/bios-tables-test: add test cases for DIMM proximity

> I've verified my patch by interacting with a guest with various settings - is
> this good enough, or do you really want me to test the value (which I think
> would just be "do I get out what I put in at the command line") via the unit
> test infrastructure?
It would be better to add test especially for a new code.
The reason for it is to catch regressions down the road,
it also makes easier for maintainer to review/test series.

> Thank you for the review.

  reply	other threads:[~2018-05-16  7:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-27 21:53 [PATCH 1/3] nvdimm: fix typo in label-size definition Ross Zwisler
2018-04-27 21:53 ` [Qemu-devel] " Ross Zwisler
2018-04-27 21:53 ` [PATCH 2/3] nvdimm, acpi: add NFIT platform capabilities Ross Zwisler
2018-04-27 21:53   ` [Qemu-devel] " Ross Zwisler
2018-04-30 11:39   ` Stefan Hajnoczi
2018-04-30 11:39     ` [Qemu-devel] " Stefan Hajnoczi
2018-05-10 13:39   ` Igor Mammedov
2018-05-10 13:39     ` Igor Mammedov
2018-04-27 21:53 ` [PATCH 3/3] nvdimm: platform capabilities command line option Ross Zwisler
2018-04-27 21:53   ` [Qemu-devel] " Ross Zwisler
2018-04-30 11:39   ` Stefan Hajnoczi
2018-04-30 11:39     ` [Qemu-devel] " Stefan Hajnoczi
2018-05-10 13:28   ` Igor Mammedov
2018-05-10 13:28     ` Igor Mammedov
2018-05-15 23:03     ` Ross Zwisler
2018-05-15 23:03       ` Ross Zwisler
2018-05-16  7:22       ` Igor Mammedov [this message]
2018-05-16  7:22         ` Igor Mammedov
2018-04-30 11:38 ` [PATCH 1/3] nvdimm: fix typo in label-size definition Stefan Hajnoczi
2018-04-30 11:38   ` [Qemu-devel] " Stefan Hajnoczi
2018-05-03 22:20   ` Ross Zwisler
2018-05-03 22:20     ` [Qemu-devel] " Ross Zwisler
2018-05-04  8:44     ` Stefan Hajnoczi
2018-05-04  8:44       ` [Qemu-devel] " Stefan Hajnoczi
2018-05-10 13:06 ` Igor Mammedov
2018-05-10 13:06   ` Igor Mammedov

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=20180516092208.4461c748@redhat.com \
    --to=imammedo@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=linux-nvdimm@lists.01.org \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=ross.zwisler@linux.intel.com \
    --cc=stefanha@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.